Good dev knows

2022-01-11 16:41:19 Перевел для Хабра статью Как разработчику применять принципы лидерства Amazon.

Один мой друг, который сначала переехал из в , а потом из в Amazon, рассказывал, что у них там все действительно сводится к исповедованию этих принципов. И твой промоушен напрямую зависит от того, что ты сможешь доказать, как хорошо ты ими руководствуешься.

Но, даже если вы не планируете промоутиться в Amazon, то список принципов интересный, во много совпадает с тем, чем занимается Хороший разработчик. Изначально в статье было побольше воды, поэтому я ее немного адаптировал.

Поддержите апвоутом плз Открыть/Комментировать

2022-01-10 11:53:38 Цена не нашего бага

Начинаем год с истории.

Как-то раз один из наших сервисов начал падать. У нас вроде бы ничего не менялось, а сервис падал, об этом сигнализировали health чеки.

Начали разбираться, увидели что проблемы с базой данных, поизучали еще, увидели что закончились коннекшены в пуле коннекшенов к базе данных. Окей, быстрый фикс — увеличили количество копий сервиса в k8s кластере на 3, он опять начал работать нормально.

Быстрый фикс это хорошо, но нужно нормально разобраться и починить. Сначала выяснили, что к сервису вырос трафик. Мы ничего не делали, маркетинг ничего не делал, мы не знали кто делал, но кто-то ведь сделал . Трафик вырос к эндпоинту, который делал 1 или 2 запроса к базе данных и больше ничего особенного. Но из-за роста количества запросов и текущей конфигурации этого было достаточно, чтобы все коннекшены кончились.

Окей, разбираемся дальше, почему вырос трафик? Оказалось, что в недавнем релизе приложения завелся баг . Приложение делало запрос к эндпоинту. Если эндпоинт отвечал 404 (что согласно нашей бизнес логике было возможным), то приложение думало, что это ошибка, и начинало повторять запрос. Распостранение приложения по телефонам занимает время, поэтому трафик рос постепенно, пока не вырос значительно.

Договорились с командой, что приложение починят. Это займет примерно месяц (включая новый цикл распостранения приложения). А мы решили, что должны оптимизировать наш сервис сейчас, чтобы было по уму, чтобы он справлялся с новым трафиком. В итоге мы добавили кэш, и теперь, если сервис возвращал 404, то он и следующие 5 минут возвращал 404. Зарелизили, посмотрели на метрики — все улеглось.

На следующий день — сообщения от саппорта, у некоторых пользователей проблемы. Стали разбираться — действительно, у нас может быть такое, что сначала возвращается 404, потом пользователь делает действие и должна возвращаться уже 200, но благодаря нашему “фиксу” мы возвращаем 404 еще 5 минут и пользователь видит странности в UI. Мы откатили “фикс”, все стало опять хорошо.

А теперь плот твист. Почему мы хотели внедрить кэш? Чтобы все было “правильно”, чтобы не платить за лишние инстансы сервиса. Потом я посчитал, что за лишние “инстансы” сервиса за месяц мы заплатим всего 60$. Т.е. 0, в масштабах компании. Сколько мы “потратили” на наш “фикс”, проблемы пользователей и т.п.? Однозначно больше. Мы оставили все как есть, подождали полтора месяца и уменьшили количество инстансов.

Вывод простой, но важный — когда мы что-то делаем, нужно себя спрашивать — а может быть лучше этого не делать и залить проблему деньгами? Иногда залить деньгами действительно дешевле .

Есть примеры, когда вы заливали пожар деньгами? Пишите в комментарии.

#истории, Instagram | Patreon Открыть/Комментировать

2021-12-31 10:57:23 Последний день в году, время подводить итоги и строить планы.

Итоги

Хороший разработчик знает начал свой путь в конце августа. Тогда я планировал стать software engineering TikTok звездой , а канал завел в нагрузку, потому что тексты сценариев выглядели как готовый пост в Telegram. С TikTok не сложилось и я сфокусировался на Telegram-канале.

Итоги канала на картинке, которую любезно сгенерировал TGStat. Самая удивительная цифра на этой картинке для меня это 107.924 просмотра. Это очень круто осознавать, что сто тысяч человек, минимум зацепились взглядом, за то, что я написал, а может быть и прочли текст.

В декабре я начал вести Instagram Хороший разработчик знает, где помимо того, что должен знать Хороший разработчик, я публикую и личный контент. Признаюсь, конверсия с Telegram-канала в Instagram подписчики оказалась меньше, чем я ожидал. У вас все еще есть шанс подписаться

Планы

Планы, а скорее цели, на 2022 год такие:
* набрать >10.000 подписчиков в Telegram-канале
* набрать >2.000 подписчиков в Instagram
* запустить минимум один продукт для аудитории “Хороший разработчик знает”
* сделать “Хороший разработчик знает” sustainable, т.е. чтобы инвестиции моего времени в проект компенсировались

Почему это цели, а не планы — потому что я, пока, не прописал то, как буду этого добиваться. Но займусь этим в начале 2022.

К подписчикам

Спасибо за то что подписались и читаете. Спасибо за комментарии и за любой фидбек. Еще большее спасибо патронам, которые поддержали ХРЗ монетой. Желаю, чтобы в 2022 мы все продолжили идти по пути Хорошего разработчика и делали это с удовольствием.

Тем, кто хочет поддержать проект — приглашаю оформить подписку на Patreon до конца года и получить от меня открытку . Это поможет мне писать полезные посты регулярно.

Вы все клевые, спасибо, что вы здесь

OneTwo more things

В первую неделю 2022 канал будет в отпуске, до встречи 10го января.

А еще я включил реакции, можно, например . Отмечаем НГ в комментариях.

Instagram | Patreon Открыть/Комментировать

2021-12-29 11:51:34 Топ имен

Последняя неделя года продолжается, писать о чем-то серьезном желания нет. Поэтому я решил подсчитать имена. Кто подписан на Хороший разработчик знает?

Первой задачей было экспортировать участников группы. Оказалось, что эта задача не тривиальная и в Telegram клиенте это так просто не наклацаешь. Нужно использовать API и не какое-нибудь простое REST API, а самое настоящее хардкорное, которое работает напрямую с кастомным Telegram протоколом. Это API, которое используется для написания Telegram-клиентов.

Благо есть Python библиотека Telethon, которая абстрагирует использование протокола. Я нашел готовый скрипт для экспорта участников группы, немного изменил его, чтобы он поддерживал двухфакторную аутентификацию и применил. В результате я получил 2005 записей. Потому что экспортировать всех все еще нельзя . Но я думаю выборка репрезентативная.

Я выбрал поле с именем, и положил данные в отдельный файл. Потом я написал Node.js скрипт который, в принципе, подсчитывает количество имен. Запустил его раз, вручную намапил имена, которые пользователи пишут по-разному на нормализированные и запустил еще раз.

И вот результаты.

Мужские имена:
1. Александр - 111
2. Дмитрий - 87
3. Сергей - 80
4. Евгений - 52
5. Андрей - 50

Женские имена:
1. Ольга - 16
2. Анна - 14
3. Наталья, Анастасия, Елена - по 11

Конечно, уверен что погрешность присутствует, но, думаю что Александры точно победили в общем зачете. Дмитриям стоит постараться и пригласить в канал своих тезок, если они планируют бороться за топ 1. Среди девушек явного фаворита нет, все может измениться в любой момент, мои поздравления Ольгам .

В целом, подумайте над заполнением своего Telegram профиля корректно, каждое имя важно .

Вас зовут Александр? Пишите в комментариях, что чувствуете.

#хардскиллы, Instagram | Patreon Открыть/Комментировать

2021-12-27 13:05:21 Пришла последняя неделя года, время подводить итоги и строить планы. Я придумал, что хорошо было бы написать пост о том, чему я научился в 2021. Но я быстро понял, что лучше я перечислю то, что учило меня в 2021.

В этом году я проходил курсы и читал книги. Вот что это было.

Книги

Искусство объяснять. Мне кажется я и раньше неплохо объяснял и делал презентации. Но эта книга не была лишней. Она дает определению слову “объяснение”, основной цели этого процесса (сделать информацию “дешевле” для слушателя). Дальше рассматривается универсальная структура хорошего объяснения. Уверен, что этого навыка не хватает многим разработчикам.

Solution’s Architect’s Handbook.... В этой книге нет ничего уникального, более того, есть логические ошибки в тексте, которые искажают смысл сказанного. Но это хорошая компиляция прямо всего, что относится к теме Solution Architect. Рад, что прочитал.

Пиши, сокращай. Книга в которой методично объясняется, что основная цель текста это — быть полезным читателю. Конечно, рассматриваются и инструменты, с помощью которых этого можно достичь. Помогает мне писать посты в канал. Рекомендую.

Developing Coaching Skills: A Concise Introduction. Я ничего не знал о коучинге, кроме того что есть коучи и это “модно”. Эта небольшая книжка рассказывает что такое коучинг, почему он работает, освещает базовые коучинг фреймворки. Полезно, все это можно применять и с собой, без всяких коучей. А можно так общаться с людьми и помогать им решать проблемы, при этом не будучи экспертом в их предметной области. Мне понравилось.

Leading Great Meetings.... До этого года мне было не комфортно вести митинги. Я это делал и не избегал, но это вызывало у меня стресс. Благодаря этой книге я структурировал свои представления о митингах, узнал о конкретных инструментах, которые помогают достигать результатов.

Переговоры без поражения. Гарвардский метод. Рассказывают, что любые переговоры вести несложно. Метод состоит всего из четырех пунктов. Никакого секретного соуса, все основано на “справедливости”. Было полезно + подтвердило собственные убеждения.

Курсы

AWS Cloud Services and Infrastructure - Cost Optimization Deep Dive. Компиляция информации о том, как заниматься Cost Optimization с AWS. Много информации уже встречалось при подготовке к AWS Solution Architect сертификации. Но есть и новое. Полезно.

Kubernetes Deep Dive. Стал больше понимать k8s, то как он работает и как развивается. Стало проще общаться с platform командой и следить за нашим “доменным” кластером.

The Diamond of Participatory Decision-Making. Короткий “курс” который открыл мне глаза. Это нормально, когда на митинге происходит “не конструктивная” фаза, а тебе кажется что это ничем хорошим не кончится. Для “сложных” митингов это нормально, это просто часть процесса.

Еще я слушал книги и подкасты, смотрел youtube и читал Telegram-каналы, но про это в другой раз.

А что классного прошли или прочли вы в 2021? Поделитесь, нам всем надо составлять список на 2022.

#истории, Instagram | Patreon Открыть/Комментировать

2021-12-24 13:16:46 Про unknown unknown

Мы постоянно потребляем информацию, постоянно что-то читаем, что-то слушаем, что-то смотрим, вот на Telegram-канал подписались. В идеале, мы перерабатываем эту информацию, делаем какие-то собственные выводы. А потом, когда мы принимаем какие-то решения, мы основываем их на этой информации. Но есть еще кое-что...

Всю информацию, с которой мы сталкиваемся, можно разделить на четыре категории.

Known known. Мы это твердо знаем и мы знаем, что мы это знаем. Например, мы проектируем REST сервис, который реализует HTTP методы. Мы их все знаем. Существование метода THANOS, о котором мы не догадываемся, стремится к нулю.

Known unknown. Мы знаем что информация существует, если нужно, то мы ее найдем и изучим. Например, как развернуть Rust приложение на Microsoft Azure? Сейчас мы не знаем, но если надо, то узнаем и сделаем.

Unknown known. Мы не знаем эту информацию, но, возможно, ее знают люди которые нас окружают. А мы понимаем, что такое может иметь место. Например, мы хотим развернуть Rust на Microsoft Azure, собираем митинг чтобы провалидировать нашу стратегию. А там опытный Rust разработчик говорит — меньше 64Gb памяти сервер не берите, иначе сборщик мусора взорвет сервер. (это я придумал, если что)

Unknown unknown. Моя любимая область. Мы не знаем об этой информации и никто вокруг не знает о ней. Даже если мы сильно захотим, но ничего не поменяем вокруг, мы о ней не узнаем. Например, с большой долей вероятности можно сказать, что не знают о существовании .

Ну а если на примере для разработчиков, то мы все еще разворачиваем Rust на Microsoft Azure, но бухгалтерия не может оплатить счет, потому что ваш главный инвестор оказался замешан в коррупционном скандале и теперь все активы заморожены .

В целом, подобную классификацию можно применить везде. Например, при планировании проектов, можно быть уверенными, что до того как мы реально начнем работать, мы не сможем предсказать все unknown unknown. Нужно закладывать на это дополнительное время.

Еще раз — как бы мы хорошо не готовились, всегда останется unknown unknown, это нужно принять. А если unknown unknown настал, не стоит расстраиваться и корить себя, нужно просто сделать выводы, а в следующий раз сократить количество возможных unknown unknown.

Сталкивались с unknown unknown? Пишите примеры в комментариях.

#софтскиллы, Instagram | Patreon Открыть/Комментировать

2021-12-22 11:20:14 Про RPO и RTO

Поговорим еще раз про даунтаймы, а именно, про восстановление работы после них. Записывайте себе в конспект, это будет на экзамене (ну если будете сдавать AWS Solution Architect).

Никто не хочет, чтобы их инфраструктура или приложения падали, но это все равно происходит. Поэтому главное, что должен сделать Хороший разработчик, это быть готовым к этому событию.

Когда мы планируем reliability и availability нашего решения, мы хотим, чтобы наш сервис восстанавливался быстро и без потери информации. Чтобы формализовать эти требования, мы можем определить два параметра — RTO (Recovery Time Objective) и RPO (Recovery Point Objective).

RTO. Сколько времени максимально, наше решение должно восстанавливаться после инцидента. Например, ударила прямо в наш сервер, через сколько времени наш сервис должен опять работать и работать нормально? Этот параметр поможет нам определиться с *availability* стратегией.
Если для восстановления работы нам нужно заказать и настроить новый сервер, то на это может уйти день. А если у нас всегда параллельно работает такой же сервер, и нам нужно только переключить трафик — то минуты.

RPO. Потерю какого количества актуальной информации может “стерпеть” компания? Измеряется во времени. Например, перегрыз провода, произошло замыкание и сгорел HD. Данные за последние два часа нельзя восстановить. Это приемлимо? Зная RPO можно определиться со стратегией резервного копирования.

Определение RTO и RPO это бизнес задача, в которой учитывается пользовательский опыт, возможные финансовые потери от даунтайма, репутационные потери. А вот реализация этих требований, это уже задача Хорошего разработчика. Очевидно, что чем строже требования, тем дороже будут ежедневные траты на поддержку этих требований .

Еще раз — Хороший разработчик готов к тому, что все сломается. На этот случай у него есть стратегия. Хорошо, когда эта стратегия подготовлена на основе бизнес требований, которые формализованы в RTO и RPO.

У вас в команде определены эти параметры? Пишите в комментариях.

#хардскиллы, Instagram | Patreon Открыть/Комментировать

2021-12-21 13:01:58 , еще одно объявление.

Если вы с каналом давно, то может быть помните, что я ставил цель собрать здесь 2000 подписчиков до Нового Года. Тогда нас было где-то 500. И я только примерно представлял, как я этого буду добиваться. Но вот еще 21-е декабря, а нас уже ~2350.

Это очень здорово, и я доволен аудиторией которая тут собралась. Практически под каждым постом у нас очень продуктивные комментарии. Спасибо за подписку .

Теперь нужно ставить новые цели. Теперь моя цель сделать "Хороший разработчик знает" sustainable. Я хочу продолжать писать по 3 поста в неделю и еще вести Instagram (там, кстати, вышел новый пост). Что нужно Хорошему разработчику, чтобы продолжать делать то, что он делает? Знать, что то, что он делает, кому-то нужно.

Я запускаю программу поддержки, т.е. Patreon. По ссылке, вы можете стать моим патроном и получить что-то взамен.

Это подойдет вам если:
1. Вам нравится то, что я делаю и вы хотите участвовать
2. Вы хотите следить за тем, как можно зарабатывать на своей экспертизе
3. Вам нужна моя помощь
4. Вы хотите открытку

По ссылке https://www.patreon.com/PavloPoliakov, вы можете почитать больше про бонусы. Плюс вас уже ждут два публичных текста. Почитайте.

Спасибо, за то что здесь Открыть/Комментировать

2021-12-20 11:10:23 История о том, как я не получил промоушен

Как-то раз, работал я в компании. Я работал там уже три года и был Хорошим разработчиком (со скидкой). А по должности назывался Expert Software Engineer, потому, что в этой компании так называли Senior.

Выше Expert в иерархии стоял Head. По факту, люди с тайтлом Head лидили команду. Занимались менеджментом и техническим лидерством. Я тоже хотел быть Head. Чтобы расти и денег больше.

Компания планировала выход на новый рынок ( ) и нужно было адаптировать продукт под этот рынок. То есть подкрутить фронт-энд, подкрутить бэк-энд, поинтегрироваться с другими командами и связать все это вместе. Закрутилось все это без меня. Но пошло не так активно как планировалось, поэтому, в рамках оптимизации курса, возникла идея привлечь меня, чтобы я этот процесс лидировал.

Я согласился. В моей голове, эта работа была такая же, как и работа других Head. Я думал так — у меня нет опыта в менеджменте команды в Европе, сейчас я научусь, у меня получится и мне тоже дадут Head. В итоге я взялся за дело и мы, вместе с командой, сделали этот проект в срок. Это заняло примерно 6 месяцев. Моя роль в успехе мероприятия была велика, говорю это только потому, что на ретроспективе каждый из членов команды это отметил отдельно, так что это измеримый факт.

По результатам перформанс ревью, меня похлопали по плечу, сказали что я ух как хорошо работаю и это ух как помогает компании. Компенсация немного повысилась. А Head дадут? Спросил я. Мне ответили, что, согласно бюрократическим особенностям нашей компании, “ух как работать” нужно 12 месяцев подряд, чтобы рассчитывать на промоушен.

Окей, я прикусил губу и решил работать еще и подождать, что будет через 6 месяцев. В следующие полгода мне выпала другая команда, которую я тоже лидировал. И другая задача. Перспективная, но менее приоритетная, а к концу полугода уже и неактуальная. Хотя я и команда работали хорошо, но мои заслуги оценили как “хорошо”, а не “ух как хорошо”. Перспективы Head особо не обсуждались. На мой вопрос “почему я делаю тоже что и другие Head, но еще не Head?” мне ответили что-то вроде “сейчас нет необходимости в новом Head".

В итоге я отказался делать дополнительную работу, уведомил о ситуации команду и снова стал простым разработчиком. А через пару месяцев ушел.

Давайте рассмотрим мои ошибки:
1. Изначально, у себя в голове, я нарисовал какой-то “справедливый” план — работай хорошо, это увидят, тебя по заслугам повысят
2. Я не обсудил этот план с моим менеджером. Я подумал, что он тоже придерживается такого плана
3. Похоже, что моему менеджеру просто было удобно закрыть мной проблему. А о моей “проблеме” ему первые 6 месяцев вообще не было известно.

А вот и вывод — Хороший разработчик не надеется на “справедливость”. Справедливость для него, для его менеджера, для его коллег может быть очень разной, это субъективная оценка. Хороший разработчик проговаривает ожидания, а лучше их прописывает. Необязательно прописывать как контракт, можно просто как e-mail с саммари встречи. Тогда результат можно будет оценить объективно.

Попадали в похожие ситуации? Рассказывайте в комментариях.

#истории

А еще я завел Instagram, подписывайтесь Открыть/Комментировать

2021-12-18 12:30:26 ,

Я решил расширить "Хороший разработчик знает" еще одним каналом и завел Instagram-аккаунт.

Планы такие:
1. В Telegram я продолжу писать контент посложнее и подлиннее
2. В Instagram можно больше и чаще показывать, меньше писать
3. Некоторые темы, которые уже встречались здесь, буду пересказывать там, используя другие средства
4. Еще там я буду рассказывать и показывать личное, то что мне интересно — работа, жизнь в Германии, архитектура Гамбурга, моя жизнь
5. В будущем, я планирую там продавать, но это в будущем. И это будет win-win.

Сейчас там уже теплится первый пост и игра "две правды одна ложь". А вечером расскажу рецепт традиционного немецкого Рождественского напитка . Кулинарный разработчик, получается.

Подписывайтесь: https://www.instagram.com/gooddevknows/ , будет интересно и про IT. Открыть/Комментировать