Good dev knows

Про типизированные языки

Как-то раз к нам в компанию вышел новый СТО. И через примерно месяц своего присутствия он начал рубить с плеча. Сказал, что теперь новые бэк-энд сервисы мы можем писать только на Java или Go.

К тому времени нас было, наверное, около 15 фулстэк Node.js + JavaScript разработчиков. Наш основной стэк был Hapi (кто-то помнит такой фреймворк?), Angular, новый проект был на React. Сказать что мы “удивились” это ничего не сказать. Мы пытались войти в аргументированную конфронтацию, объяснить что хорошая архитектура на Node.js тоже возможна, предлагали сойтись на том, что добавим в список TypeScript. Но CTO был непреклонен, он аргументировал это тем, что для энтерпрайза важнее не скорость разработки, а возможность поддержки ПО в дальнейшем.

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

Сейчас я понимаю две вещи — 1. у СТО были большие проблемы с коммуникацией, 2. он был прав.

Половина моей карьеры связана с не типизированными языками — PHP, потом JavaScript. И сейчас я понимаю, что все то, что написал в то время, невозможно было бы поддерживать. Потому, что когда ты открываешь код и не имеешь возможность “прокликать” методы и переменные, то когнитивная сложность растет экспоненциально.

В текущей компании одной из первых задач было инкорпорирование кода, который изначально был разработан другими людьми. Я уверен, что успех этого мероприятия напрямую связан с тем, что это была Java.

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

Затраты на хорошую архитектуру JavaScript приложения будут выше, чем скорость, которая “потеряется” из-за использования типизированного языка. Тестами это тоже не исправишь, потому что тестировать приходится значительно больше, по сравнению с типизированными языками. К счастью, сейчас экосистема JavaScript движется в сторону TypeScript.

Не типизированные языки отлично подходят для одноразовых скриптов. А для всего что будет жить больше года и над чем будет работать команда нужно выбирать типизированные языки.

Приходилось поддерживать большие проекты на JavaScript? Пишите в комментариях.

#истории, 🌄Instagram |🤝Patreon

Про проклятье знания

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

Это когнитивное искажение называется — проклятье знания (Сurse of knowledge). Нам сложно представить, что другие люди не знают то, что кажется нам очевидным. Это можно наблюдать везде.

Например, на работе, вы не понимаете, зачем собирать митинг, ведь решение очевидно. А оказывается, что другие участники просто не знают контекст, который знаете вы. И более того — если вы узнаете контекст, который знают они, вы можете понять, что ваше решение уже не такое однозначное 🧐.

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

Однако этот “страх” довольно просто победить. Потому что, даже если люди уже знают информацию, о которой идет речь, то у большинства это повторение вызовет положительные эмоции. Потому, что мы получаем удовольствие, когда получаем подтверждение того, что мы что-то знаем 🏆.

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

⬛️ Еще раз — не факт, что другие люди знают то, что знаете вы. Чтобы добиться того, что у всех одинаковый контекст, нужно оверкоммуницировать. Это безопасно и не повлияет на вашу репутацию. Полезно рефлексировать, не находитесь ли вы сейчас под “проклятьем знания”?

Замечали за собой такое поведение? Пишите в комментариях.

#софтскиллы, 🌄Instagram |🤝Patreon

Новости

Оказывается, что в ноябре 2021 Redis зарелизили клиентскую библиотеку Redis OM, где OM это object mapping. Библиотеки доступны для .NET, Python, Node.js (TypeScript) и Spring.

Узнал я об этом из этого видео, где за 13 минут показывают как сделать CRUD (только create) + поиск на Redis. Использование библиотеки выглядит простым и понятным.

Мы Redis особо не используем, но я делал демо проект на нем. Для работы я использовал Spring Data Redis, нашел баг в документации и теперь даже являюсь контрибьютором в этот проект.

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

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

#новости, 🌄Instagram |🤝Patreon

Defensive programming

Часто, когда мы разрабатываем программное обеспечение, мы фокусируемся на таком сценарии, где все идет как надо — happy path. С опытом, приходит понимание, что даже если обычно все идет как надо, то 100% будут случаи, когда что-то пойдет не так. Хороший разработчик старается учитывать наиболее важные ситуации, когда что-то идет не так.

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

Например, у нас есть uuid пользователя, мы знаем, что пользователь существует и наш сервис делает запрос к другому сервису /users/{uuid}. Но вдруг мы получаем 404, что делать? Мы ведь уверены, что пользователь существует. Возможно пользователь просто не успел создаться, потому что операция создания пользователя асинхронная.

Применив defensive programming, мы можем запрограммировать повтор запроса (лучше с экспоненциальной задержкой и ограничением количества повторов). В таком случае мы еще раз попробуем получить данные про пользователя через 1, 2, 3 секунд ⏳. Если после пятой попытки все еще возвращается 404, то можно и упасть — записать сообщение в лог и ответить 500 клиенту.

Defensive programming хорошо подходит там, где мы не контролируем входные данные. Например, при обработке форм, куда пользователи вводят данные, мы можем санитизировать данные (делать их безопасными) или нормализировать данные (приводить их к тому формату, который нам нужен). И только потом — валидировать. Never trust user input.

⬛️ Еще раз — здорово, когда программы не падают из-за любой ошибки. Чтобы этого достичь, Хороший разработчик, предусматривает обработку нестандартных ситуаций, чтобы программа продолжила свою работу. Это способствует high availability.

Вы используете defensive programming? Пишите в комментариях. В следующую среду поговорим про offensive programming 🤺.

#хардскиллы, 🌄Instagram |🤝Patreon

Перевел для Хабра статью Как разработчику применять принципы лидерства Amazon.

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

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

Поддержите апвоутом ⬆️ плз 🤗

Цена не нашего бага

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

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

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

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

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

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

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

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

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

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

#истории, 🌄Instagram |🤝Patreon

Последний день в году, время подводить итоги и строить планы.

📝 Итоги

Хороший разработчик знает начал свой путь в конце августа. Тогда я планировал стать 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

Топ имен

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

Первой задачей было экспортировать участников группы. Оказалось, что эта задача не тривиальная и в 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. Но я быстро понял, что лучше я перечислю то, что учило меня в 2021.

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

Книги

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

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

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

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

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

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

Курсы

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

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

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

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

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

#истории, 🌄Instagram |🤝Patreon

Про 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

Про 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

👋, еще одно объявление.

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

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

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

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

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

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

Спасибо, за то что здесь 🤗

История о том, как я не получил промоушен

Как-то раз, работал я в компании. Я работал там уже три года и был Хорошим разработчиком (со скидкой). А по должности назывался 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, подписывайтесь 🤝

👋,

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

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

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

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

Техника Pomodoro

Прокрастинация. Мы все страдаем от этого, правда? Я точно да. Думаю каждый Хороший разработчик, иногда, страдает от этого. Нужно сделать столько всего, и это все вроде бы так важно, что не знаешь с чего начать и как к этому подступиться. Поэтому жмешь Cmd + R и проверяешь есть ли что новое на Медузе.

К счастью, наш мозг, можно легко обмануть. И убедить его, что напрягаться придется недолго. С этим помогает техника Pomodoro timer. Название пошло от кухонного таймера

Она простая, уверен, что многие о ней уже слышали:

1. Составьте список задач, над которыми вам надо работать
2. Заведите таймер на 25 минут, в течении этого времени НИ НА ЧТО не отвлекайтесь. Выключите мессенджеры. Работайте над задачей.
3. Поработали? Отдохните пять минут. Можно читать Facebook.
4. Еще раз пункт два. Завели таймер и работаем. Один такой интервал называется — помидорка.
5. После четырех помидорок можно сделать большой перерыв, например 20 минут.

Это точно работает, я проверял. Согласиться поработать 25 минут намного проще, чем согласиться с абстрактным "сделать задачу".

Я применяю технику не канонично. А просто, если надо "заставить" себя над чем-то работать, то включаю помидорку и работаю. Как правило, после двух помидорок у меня уже существенный прогресс и это делает меня довольным.

Я использую программу Be Focused - Focus Timer на Mac, все еще на бесплатной версии. Ссылка в комментариях. Мне очень помогает тиканье часов + я включаю белый шум в Spotify.

⬛️ Еще раз — если сложно начать работать над задачей, то проще согласиться поработать над ней только 25 минут, а потом вознаградить себя заслуженным отдыхом.

Уже использовали эту технику? Если использовали, напишите, пожалуйста, в комментариях свое любимое приложение.
⁠
#софтскиллы

Write-ahead logging

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

А что будет, если RabbitMQ будет недоступен в этот момент и сообщение не отправиться ☠️? Можно добавить какой-то retry, можно вообще откатить транзакцию и ответить 500. Можно "потерять" это сообщение, таких случаев ожидается мало, но лучше не "терять", ведь тогда может нарушиться цельность данных в нашей информационной системе.

Есть другое решение — использовать технику write-ahead log. В таком случае, отправка сообщения будет, грубо говоря, состоять из трех шагов:

1. Записываем что нужно отправить в базу данных, в табличку events, ставим статус PENDING
2. Какой-то worker периодически проверяет эту табличку и отправляет сообщения со статусом PENDING
3. Если сообщение отправилось, ставим ему статус SENT
4. Бонус. Время от времени удаляем строки у которых статус SENT

В таком случае, мы убиваем двух зайцев. Во-первых, наша основная операция — запись в базу данных обновления про пользователя, не падает, если мы не может сделать вторичную (отправить сообщение). Во-вторых, мы уверены, что все сообщения уйдут.

Эта же техника используется движками баз данных для обеспечения atomicity и durability из ACID. Только базы данных записывают информацию в файл, а потом в саму базу данных.

⬛️ Еще раз — если вы хотите быть уверенными, что действие будет выполнено, используйте технику write-ahead log. Это делает программу сложнее, но стабильнее.

Реализовывали такое сами? Пишите в комментариях
⁠
#хардскиллы

Про онлайн тренинги

На прошлой неделе со среды по пятницу я участвовал в онлайн тренинге по Kotlin и хочу поделиться своими впечатлениями.

Это было плохо! Нет, не Kotlin, не материал, даже не лектор, который его проводил. Но все в целом. Уже практически два года я, в основном, работаю удаленно и успел к этому привыкнуть, но длинный онлайн тренинг я посещаю первый раз. Основной вывод — нельзя просто взять обычный оффлайн тренинг и начать проводить его онлайн.

Наш тренинг должен был ознакомить разработчика с Kotlin best practices. Как это выглядело:
* Лектор рассказывает и показывает какой-то рандомный топик про Kotlin
* Основное взаимодействие с аудиторией это вопрос — все понятно? Если не понятно, то спрашивайте
* Теория разбавлена заданиями на самостоятельное выполнение
* Перерыв
* Поехали дальше, новый рандомный топик

Моей основной проблемой было удержание фокуса. Для меня это оказалось невозможным. Я не могу просто сидеть и смотреть интересное видео про Kotlin 8 часов в день, даже с перерывами. Мой attention gap намного меньше.

Что можно было улучшить, на мой взгляд:
1️⃣ У тренинга должна быть история, какая-то общая легенда, которая пронизывает все топики
2️⃣ Взаимодействие с аудиторией должно быть интерактивным. У нас было пару моментов, когда мы голосовали, но мы голосовали по темам "Перерыв должен быть сейчас или позже?" 🙃 Так легче быть вовлеченным
3️⃣ Задания нужно выполнять в парах, тогда будет сложнее поддаться соблазну их просто пропустить
4️⃣ Мы начали сразу со сложной темы — Thread safety. Зачем? Логики в этом не было никакой. Потом были менее сложные темы. Сначала надо дать участникам ощущение прогресса, чтобы они поверили в свои силы.
5️⃣ Никакого преимущества, в том, что мы проводим три дня подряд на этом тренинге, нет. Такие курсы лучше проходить медленнее и за более продолжительный срок.

Были и положительные моменты — я услышал о топиках, про которые хочется узнать больше: Offensive programming, Mutation testing, Sequences.

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

Онлайн это сложно, но точно возможно. Просто надо лучше подготовиться.

Вы проходили какие-то классные тренинги онлайн? Напишите о них в комментариях.

#истории

Что такое RACI матрица

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

Чем больше команд и людей работают над проектом, тем сложнее координация, и тем сложнее о чем-то договориться. Непонятно, кто может принять окончательное решение, если есть альтернативы. Непонятно, к кому обращаться, если есть проблемы.

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

Представим, что мы делаем сложный проект — мигрируем микросервисную архитектуру в AWS. У нас десяток сервисов, пять баз данных, огромный RabbitMQ кластер, его хорошо бы разбить. Этим занимаются три команды и пятнадцать разработчиков.

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

Доступно четыре кода:

R (Responsible) — значит что человек выполняет задачу. Например, перенастраивает микросервисы, чтобы они работали с новым RabbitMQ.

A (Accountable) — человек, который отвечает за результат, у каждого процесса может быть только один такой человек, именно он может принять финальное решение. Например, решить, что теперь мы будем использовать много отдельных брокеров RabbitMQ.

C (Consulted) — люди с которыми нужно проконсультироваться, во время выполнения задачи. Например, разработчики одной из команд, которые используют легаси RabbitMQ кластер.

I (Informed) — сотрудники, которых нужно информировать о выполнении задачи. Например, держать всех разработчиков в курсе прогресса о миграции на новых брокеров.

Теперь мы можем составить не сложную табличку, где мы запишем всех разработчиков и все задачи, которые нужно сделать. Разработчикам, которые участвуют в этих задачах присваиваем коды. Табличку кладем в какой-нибудь Confluence и всем говорим куда смотреть, если есть вопросы.

⬛️ Еще раз — RACI матрица позволяет наглядно записать кто за что ответственен. Когда мы, вместе, формализируем и записываем ожидания мы достигаем нескольких целей — теперь понятно кто чем занимается; люди понимают, что они лично ответственны за определенные задачи. Групповой ответственности не бывает.

Были ситуации, когда не было понятно кто должен принять решение? Как они разрешились? Пишите в комментариях.
⁠
#софтскиллы

Вакансия

Мы в SHARE NOW ищем нового разработчика в команду, где я работаю. SHARE NOW это самый большой каршеринг в Европе, мы присутствуем в восьми странах. Наша команда отвечает за процессы, которые происходят с пользователем до того, как он может начать водить машину. А именно - валидация прав, GDPR, применение промо кодов. Но это не все, еще отвечаем, например, за программу лояльности. Используем Java/Kotlin, немного Node.js. Нас 9 человек (PO, QA, 4xBE, 1xFE, Chapter Lead).

Ищем крепкого Middle разработчика с фокусом на back-end и Java/Kotlin.

Из интересного:
* Перевозим в 🇩🇪 Германию. Можно в Гамбург или Берлин
* Если вы уже в Европе, то можно работать из Германии или Испании
* Пока оформляются бумаги, можно начать работать из вашей текущей страны (легально)
* Даем 100€ в месяц на наш каршеринг
* Development budget, курсы немецкого
* Отпуск 30 рабочих дней
* Офис около Эльбы в Гамбурге, мимо проплывают дорогие 🛥, например эта


Подписка на Хороший разработчик знает это плюс 🙃

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