Про 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. Но я быстро понял, что лучше я перечислю то, что учило меня в 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

Топ имен

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

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

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

📝 Итоги

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Новости

Оказывается, что в ноябре 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

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

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

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

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

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

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

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

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

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

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

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

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

Обновление в Patreon

Решил писать 5-15 минутки для патронов. Суть этого формата, что я трачу 15 минут на текст, который можно потом прочитать за 5 минут. Обычно это используется для улучшения коммуникации на работе. Я буду писать про свою прошлую неделю и инсайты которые я получил в течение нее. В итоге это полезно и мне — лог своих мыслей в будущем и патронам — узнавать все раньше. Еще там можно общаться.

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

В первом выпуске два топика:
* про обратную совместимость API и вендора с оценкой во много миллионов 💰
* про то, что нужно знать Junior разработчику, по моему мнению

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

Всем кто уже патрон — спасибо 🤗

Offensive programming

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

Продолжим разговор про методики обработки нестандартных ситуаций. В прошлый раз мы рассматривали технику Defensive programming, когда наша программа старается продолжить работать, несмотря на проблемы. А сегодня поговорим про технику offensive programming.

Offensive programming это вариант дизайна ПО, когда мы обрабатываем исключения и ошибки так, что программа прекращает выполнение бизнес логики, при любой неожиданной ситуации. Т.е. fail fast.

Например, у нас есть кусок кода, который работает со state и логикой подразумевается, что когда наш кусок кода будет вызван, то state будет заполнен, и не будет null. Но вдруг! Мы понимаем что в переменной все такие null. Наши действия?

При Defensive programming мы бы могли подстелить соломки, и еще раз попробовать “наполнить” state, может быть узнать его у какого-то сервиса. Но при Offensive programming мы сразу же бросаем исключение. Мы не пишем дополнительный код, который обрабатывает и старается исправить исключительные ситуации.

В некоторых технологиях уже присутствуют методы, которые помогают писать код в таком стиле. Например, assert в Node.js. А в Kotlin их даже больше — require, check, assert, requireNotNull.

Вы можете написать:

val state = checkNotNull(someState) { "State must be set beforehand" }

И быть уверенными, что со state все отлично.

Основное преимущество Offensive programming — вы пишете меньше кода. Меньше кода — в меньшем количестве мест что-то может пойти не так. А значит, это требует меньше поддержки. Из минусов — если вы не обрабатываете эту ситуацию, то она должна быть обработана в другом месте, возможно другой командой или другой компанией. Где-то новый код все равно объявится.

⬛️ Еще раз — когда команды не падают из-за любой ошибки это хорошо, но это требует разработки более сложных программ. А сложные программы это плохо. Поэтому, если ситуация позволяет, можно использовать offensive programming и следить за тем, чтобы работал только happy path.

Используете Offensive programming? Пишите в комментариях.

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

Про Developer Experience

Когда мы разрабатываем программное обеспечение мы думаем о многих его характеристиках — будет ли оно быстрым (efficiency)? будет ли оно надежным (reliability)? будет ли пользователю удобно его использовать (user experience)? Но одна из характеристик практически всегда остается неназванной вслух — будет ли удобно разрабатывать это ПО? Это свойство ПО можно назвать Developer Experience.

Представьте, что вы выходите на работу в новый перспективный стартап. В такой, где есть личный бариста ☕️. Бариста есть, а вот онбординга толком нет. Вам дали доступ в git, вы нашли там пять вроде бы нужных репозиториев. Что-то на Java, где-то React , а этим вы разобрались, а вот как все это запустить вместе — нет. В итоге вы ловите коллег и просите их помочь. Чтобы запустить проект локально вам понадобилась неделя. Это плохой DX.

Чтобы улучшить DX можно сделать следующее:

* README.md с описанием того как запустить проект локально, как настроить среду, как запустить тесты

* документация о технических процессах в команде — какая конвенция работы с git; как работаем с merge request — кто проверяет, какой врем ожидания проверки; как происходит релиз на продакшен

* в самом коде проекта минимальное количество неочевидных вещей. Время разработчика стоит дороже чем облачные вычисления. Оптимизировать DX, а не скорость.

* использование распостраненных стандартов, технологий и зависимостей, а не своих “велосипедов”. Здесь дополнительный плюс — документацию на эти модули за вас пишут люди в интернете.

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

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

Как еще можно улучшить DX? Пишите в комментариях.

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

Перевел для Хабра статью "как НЕ надо учить TypeScript".

ИМХО лучше подойдет тем, кто лишь начинает становиться на TypeScript рельсы. Кстати у автора статьи есть книга TypeScript in 50 lessons, которую я читал, там в конце начинается такая жесть (сложные примеры conditional types), что было страшно читать. Но приятно понимать какой уникальный микс получается если взять JavaScript и добавить гибкую типизацию. Такое невозможно в других языках программирования.

Всем новым (и старым) подписчикам с Хабра привет 👋

Статья

Про fast thinkers

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

В этой иерархии было два трэка — Expert и Management. И, в частности, рассказывали про их особенности. И вот когда речь зашла о менеджерском треке, то девушка, которая рассказывала про характеристики абстрактного, но нужного компании менеджера, обронила, что если вы fast thinker то не факт, что вам это подойдет.

Никто особо не обратил внимание на это, но я обратил и у меня была волна внутреннего возмущения. Я ведь себя отношу к fast thinker-ам и не хочу, чтобы мне что-то не подходило. Но, спустя время и годы, я больше об этом думал и пришел к новым выводам.

Наверное многие разработчики относят себя к fast thinker-ам. Но, чтобы согласовать ожидания, я вижу эту характеристику такой — ты быстро понимаешь о чем говорят другие, быстро проматываешь историю вперед и вот у тебя уже есть решение, ты учел какие-то риски и даже их поборол, теперь тебе скучно слушать и хочется всех перебить и говорить “о сути”. Какие-то ментальные шахматы. Я часто нахожу себя в такой ситуации.

Наверное, может показаться, что это хорошо — такие люди могут сэкономить время решения проблемы. Но у такого подхода есть и минусы. Проблема в том, что fast thinker-ы исключают из решения других людей. Если люди исключены из решения, то они не будут его искренне поддерживать и участвовать в нем. Кроме того, не факт что они полностью понимают предложенное решение, смог ли fast thinker хорошо передать контекст, который он создал у себя в голове? Не факт. Групповые решения приносят разные перспективы в решение проблемы.

Решения, принятые таким образом плохо масштабируются и плохо поддерживаются. Получаются knowledge silos и немотивированная команда. Альтернатива есть — решения принятые группой, консенсус. Такие решения в долгосрочной перспективе работают однозначно лучше.

Быть fast thinker-ом однозначно не плохо, просто нужно осознавать, что есть вещи важнее скорости и работать с этим — следить чтобы все понимали контекст, критически относиться к своим идеям, быть готовым отказаться от нее, если есть лучшая альтернатива.

Что думаете? Пишите в комментариях.

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

Вакансия

Мой друг Дима работает CTO в небольшой (инженеринг <20 человек) и перспективной компании в 🇩🇪Гамбурге - CONDO.

Компания занимается тем, что совмещает машинное обучение и рынок недвижимости, а именно - они вычисляют какие объекты недвижимости покупать, что надо в них изменить (отремонтировать), чтобы их потом выгодно продать. На вечно растущем рынке Германии это заходит очень хорошо 🚀.

Потому, что заходит это хорошо, Дима постоянно ищет новых людей, а еще лучше — Хороших разработчиков.

Сейчас ищет Full-Stack Engineer. Стэк отличный - TypeScript, Kotlin, React и Vue.js. Разрабатывать начали буквально пару лет назад, поэтому все свежее, а не legacy. Деплоят в Google Cloud Platform.

Из интересного:
* 🚜 перевозят людей в Германию, помогают с визой, дают подъемные ~2.500€
* достаточно знать английский ~B1
* 30 дней отпуска
* офис с видом на Эльбу (тоже зднание что и SHARE NOW) до лета 2022, потом с видом на центр Гамбруга
* для Senior ЗП до 90.000€
* бизнес связан с реальностью, квартиры реально покупаются, ремонтируются и продаются дороже

Еще есть вакансии Data Scientist и Data Engineer, если вы больше по data science и ML.

Если есть публичные вопросы, Дима будет отвечать на комментарии к этому посту. Если личные вопросы, пишите сразу Диме, он на них ответит и убедит вас податься.

#вакансия

Вчера опубликовал на Вастрике статью про то как мы все докатились до такого, что нас тут уже 3.000 человек.

Вастрик это клуб по подписке, участие стоит 15$ в год, зато такая небольшая сумма + небольшая проверка при вступлении является фильтром и внутри там все друг другу рады и продуктивно общаются. Так сложилось, что там много разработчиков и экспатов. Но вообще там всем рады.

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

Почитайте, если тоже думаете над созданием Telegram-канала (он вам нужен) или просто так: Как я завел Telegram-канал для разработчиков, набрал 3000 подписчиков и что я получил.

Роль SRE

Современная разработка уже подразумевает интеграцию DevOps в цикл разработки программного обеспечения. Хороший разработчик уже не только разрабатывает программу, а еще и думает как она будет доставляться в продакшен; работать там; что мы будем мониторить, чтобы понимать, что наш сервис в порядке.

Это здорово. Но может быть еще лучше. Как выглядит цикл разработки у большинства команд? Он может выглядеть так:

1. Обдумали новую фичу
2. Запрограммировали ее
3. Обложили метриками
4. Зарелизили
5. Мониторим
6. Потом вернуться к пункту 1

И вот, когда Хороший разработчик возвращается к пункту 1, то у него физически и когнитивно становиться меньше времени на пункт 5, то есть на поддержку программного обеспечения в продакшене. Я тоже сталкиваюсь с этим.

Для решения этой, и не только этой проблемы, сейчас выделяют роль Site Reliability Engineer (SRE).

Основная ответственность человека, который исполняет эту роль, в том, чтобы ваша система оперировала, была resilient и по-умному redundant. Этот инженер, как правило, напрямую не связан с разработкой сервисов, но он(а) знает как ими оперировать, как их мониторить, что делать когда что-то идет нет так. Так же этот человек участвует в on-call и исправляет проблемы.

Важной частью SRE практик является автоматизация (operations as code). Конечно что-то пойдет не так, это точно произойдет. Но важно, чтобы из этого были сделаны выводы и больше это бы не повторилось. SRE, вместе с командой анализирует инциденты, делает выводы и вносит изменения в инфраструктуру, чтобы проблемы не повторились.

⬛️ Еще раз — хорошо когда есть кто-то, кто постоянно следит за тем, что система хорошо работает в продакшене. Лучше, когда это еще и постоянно оптимизируется. Для этого кто-то должен выполнять SRE роль. В небольших и средних компаниях, это общая роль и за нее ответственна вся команда, но лучше, когда это отдельная позиция или даже команда.

У вас в компании есть SRE? Пишите в комментариях

#хардскиллы

Приоритизация технического долга

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

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

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

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

1. Собираем митинг и рисуем матрицу. По горизонтали — какие усилия нужно приложить (effort), по вертикали — какой эффект это даст для проекта (impact).

2. Теперь проходимся по бэклогу и обсуждаем тикеты. Каждый из них располагаем на матрице. Какой из тикетов сделать легко и это окажет большое позитивное влияние? А может есть такие, которые делать месяц, а результат будет минимальным?

3. Когда все обсудили и визуализировали, решаем, что мы готовы взять в ближайшую итерацию. А high impact + high effort проекты лучше разбить на меньшие задачи.

4. Теперь мы готовы обслуживать технический долг. Вы великолепны ⭐️.

Замечательно, когда приоритизация технического долга является одним из ритуалов команды и выполняется регулярно. Например, раз в месяц.

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

Как вы работаете с техническим долгом? Делитесь в комментариях.

#софтскиллы

Поговорим про 1-1 митинги

На всякий случай, вот определение, которое предлагает Google:

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

Перед постом будет два опроса.