Вакансия

Мой друг Дима работает 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) — неформальное, регулярное тет-а-тет общение менеджера с сотрудником, во время которого обсуждаются проблемы, потенциал, приоритеты и обмениваются обратной связью.

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

Про 1-1

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

Когда я переехал в Германию, то регулярные митинги появились, а особой пользы от них — нет. У меня были разные форматы — когда я разработчик, а мой менеджер - тимлид; когда я тимлид, а мой менеджер что-то типа CTO. Оба формата сводились к обсуждению прогресса в крупных задачах, обсуждении возможных будущих задач, обсуждении компании и решении каких-то организационных вопросов.

Иногда такие митинги проходили совсем скупо:
— У меня все хорошо
— Ну и у меня вопросов нет
— Тогда до следующего раза?
— Хорошо

Часто такие митинги хотелось пропускать. И я знаю других людей, которые не любят свои 1-1 митинги.

И только потом, с другим менеджером, я понял что у меня до этого не было “настоящих” 1-1 митингов. А “настоящий” 1-1 может быть полезным.

📝 Вот список характеристик “настоящего” 1-1 для меня:

* У митинга есть агенда, вы и менеджер вносите что бы вы хотите обсудить.
* На митинге не обсуждается обычная работа, для этого есть все остальные дни в неделю. Чтобы обсудить работу не нужен специальный митинг.
* Фокус митинга в том, чтобы помочь сотрудники расти и убрать препятствия, которые мешают ему расти. Т.е. необходимость совершенствовать свой скилл, один из факторов влияющих на мотивацию.
* У митинга есть какие-то результаты. Например, сейчас, на каждом митинге, я отвечаю на вопрос “Что ты вынесешь из этого митинга?”. И каждый раз мне есть что ответить, даже если это мелочь.

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

Какой у вас опыт с 1-1? Пишите в комментариях.

#истории

Новости

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

На прошлой неделе, они выпустили фильм про Kubernetes, две части: раз, два. Фильм состоит из интервью людей, которые были связаны с созданием Kubernetes, выводом его в open source, построением сообщества вокруг продукта.

Рассказывают истории о том:
* почему контейнеры были и до Docker, но Docker сделал их доступными
* что спровоцировало появление Kubernetes как платформы
* как в Google спорили стоит ли ее делать открытым продуктом
* как Kelsey Hightower стал голосом Kubernetes
* и про многое другое

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

Самое интересное, что я узнал, что kubernetes это не просто красивое слово, а слово обозначающее что-то типа "рулевой" на греческом. Поэтому у них на иконке штурвал.

Всего у них семь документальных видео — Ember.js, elexir, GraphQL, про инвесторов, Vue.js и про Kubernetes.

#новости

Обновление зависимостей

Зависимости, один из краеугольных камней современной разработки. Чтобы сконцентрировать наши усилия на написании уникальной бизнес логики, которая и является конкурентным преимуществом нашей компании, мы втягиваем в проект десятки зависимостей.

С одной стороны это хорошо — мы можем делать что-то, что относится к нашей экспертизе, например, как в случае с SHARE NOW, сдавать машинки в аренду, а не тратить время на низкоуровневое программирование про то, как положить данные в PostgreSQL. С другой стороны — зависимости постоянно обновляются, в них находят критические (log4j) уязвимости, зависимости не всегда следуют правилам semantic versioning. И следить за ними большая боль.

Если что-то боль, то лучше это что-то автоматизировать. И в случае с зависимостями, решение тоже есть. Это проект Renovate.

Эту штуку можно сконфигурировать с платформой где лежит ваш код (gitlab, github и другие) и с вашим CI. В итоге будет следующее:

1. Renovate видит, что доступна новая версия какой-то зависимости
2. Он создает merge request, где обновлена только эта зависимость
3. Ваш CI прогоняет pipeline, где запускаются unit и integration тесты (у вас ведь есть?)
4. Если все зеленое, то можно смело мерджить в основную ветку. Еще лучше, если вы настолько доверяете сетапу своего проекта, что MR будет мерджиться автоматически.

Проект поддерживает множество языков и платформ — Java, Node.js, JavaScript и даже Docker и terraform.
Интеграция таких решений как Renovate косвенно заставляет вас писать лучшие тесты, вы ведь хотите, чтобы CI сам проверял все сценарии и мерджил обновления?

⬛️ Еще раз — использовать зависимости это хорошо, другие люди делают за нас работу. Еще лучше, когда вы тоже вносите свой вклад в open source. Но даже если нет, то зависимости надо регулярно обновлять, иначе точно будет беда. Обновление зависимостей можно автоматизировать с помощью Renovate.

У вас настроено автоматическое обновление зависимостей?

#хардскиллы

👋,

Расскажу про сгенерированный мною контент, про который я еще не писал в канале.

Для всех
1. Перевод "Как писать условия в JSX". Не сложные рецепты про то как не стрелять себе в ногу, когда пишешь шаблоны.
2. Перевод "Возможности TypeScript, которых нужно избегать". TLDR, не нужно использовать ничего, чего нет в JavaScript. Статья стремительно улетает в минуса, но ее читают и комментируют. Если вы поставите ⬆️, то будет вообще супер.

Для патронов
В своем 🤝Patreon я каждую неделю пишу эксклюзивные заметки для патронов. В январе писал про:
* что такое обратная совместимость и что я ожидаю от Junior разработчика.
* внедрение инноваций в компаниях и проблемы с этим. backstage.
* про работу офтальмолога в Германии; внедрение backstage, стратегия; про то, что важно ясно выражать свои потребности, на примере.

#дайджест

Мозг уже все решил

Мы, как Хорошие разработчики и как люди, просто постоянно принимаем решения. Какие-то решения не слишком важны (посмотреть это видео на youtube или поработать?), какие-то более важные (принять оффер от этой компании?). Порой мы долго думаем, взвешиваем все за и против, и это делает нашу жизнь менее приятной.

А что если все это бессмысленно, что если мы уже приняли решение? Этот пост вдохновлен воспоминаниями о прочтении книги "Иллюзия Я, или игры, в которые играет с нами мозг".

В книге описан такой эксперимент. В 1980-х годах психолог Бенджамин Либет посадил людей перед кнопкой и просил их нажимать на нее тогда, когда им самим взбредет в голову. Параллельно, он наблюдал за активностью их мозга. Он заметил, что перед тем, как люди нажмут на кнопку происходит всплеск активности нейронов. Но, что было интересно, всплеск активности происходит раньше, чем человек ощущал сознательное намерение нажать на кнопку. Разница колебалась от 1/5 секунды до 7 секунд.

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

Я часто использую этот “хак” при решении проблем, которые затягивают и затягивают меня. Как поступить лучше? Продолжать хайринг процесс с этой компанией? Какой вариант рефакторинга выбрать? Когда я замечаю, что воронка принятия решения меня затягивает, то я спрашиваю себя — какое решение УЖЕ выбрано? И часто я знаю, какое это решение. Окружать себя вопросами становиться бессмысленно.

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

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

⬛️ Еще раз — если вы долго не можете принять решение, то спросите себя — какое решение я УЖЕ принял? Как правило, оно уже есть. Теперь у нас есть свободное время, чтобы тревожиться о чем-то другом.

Напишите, пожалуйста, интересны ли такие, более далекие от IT, темы.

#софтскиллы

Не переживайте, сообщение выше это не прогрев на покупку NFT или какого-то 🐶-коина.

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

Перевел статью для Хабра, где, с картинками и постепенно, объясняется как работает биткоин.

https://habr.com/ru/post/649597/

Про разные форматы данных

Как-то раз, недавно, к нам в команду поступил баг 🐞. Наш BI сказал, что от нас приходят таймстампы в разных временных поясах, то как в Берлине, а то как в Гринвиче. Я стал разбираться.

Чуть-чуть разобрался, и оказалось, что наша логика простая — взять то, что возвращает вендор (многомиллионная компания 💸) и отправить дальше. Стал проверять, а что же возвращает вендор? Сделал разные запросы и — ухты, иногда, он возвращает 2022-04-30T00:00:00+01:00 а иногда 2022-04-29T23:00:00Z. В одном формате есть часовой пояс, а в другом просто UTC.

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

Я написал вендору с примерами и попросил разобраться. Их ответ меня удивил. Они написали, что действительно, буквально месяц назад они выпустили обновление. И теперь, когда ты сохраняешь время через UI, то возвращаться оно будет в UTC. А вот те значения, что были созданы раньше, будут, как и раньше, возвращаться с часовым поясом. Если вы хотите, чтобы формат был одинаковый, стоит лишь сохранить все еще раз через UI (для нас это более 100 раз). А в конце дружелюбно добавили — а почему вы вообще спрашиваете? Ведь мы возвращаем одно и то же время.

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

В итоге прошла еще пара дней. Они исследовали как бы это обновить, а я исследовал, что мы будем делать, если они не обновят. Я реализовал свое решение, а они сообщили, что теперь все данные консистентны. Happy end!

🎁 Бонус знание, если вы видите время и в конце стоит Z, то это всегда UTC. When “Z” (Zulu) is tacked on the end of a time, it indicates that that time is UTC, so really the literal Z is part of the time.

Какие выводы мы можем сделать?

1. На самом деле не важно сколько стоит вендор, это я забавы ради написал. IT процессы не зависят напрямую от стоимости компании.
2. При обновлениях нужно следить за обратной совместимостью
3. Ошибаться не страшно, но нужно признавать свои ошибки

Что думаете?

#истории

Про меня

С начала года в канал добавилось около 2.000 новых подписчиков, это здорово 🚀. Чувствую, что нужно еще раз представиться и коротко рассказать что тут по чем.

Меня зовут Павел, в профессиональной (той, что приносит мне 💰) разработке я уже около 18 лет. Сначала я работал фрилансером на PHP. Потом на 🇳🇱 компанию в Харькове, делал магазины на Magento. Потом на 🇩🇪 компанию в Харькове, делал финпродукт на PHP. А потом я и вовсе переехал в Германию, продолжал работать на ту же 🇩🇪 компанию, но уже на Node.js. 4 года назад я присоединился к SHARE NOW, сначала с Node.js, а потом конвертировался в Java/Kotlin. Но разве языки программирования что-то обо мне говорят? Я думаю мало.

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

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

📚Истории
* Как я не получил промоушен
* Как я получил промоушен: часть 1, часть 2
* Как хакер украл 10.000€

⚙️ Хард скиллы
* Что такое ADR
* Что такое Technology Radar от ThoughtWorks
* Что такое Levels of maturity

🍦Софт скиллы
* 💎 of participatory decision making
* Техника Fist to Five
* Матрица Эйзенхауэра

📰 Есть еще пара лонгридов
* Как я завел экспертный TikTok и потерпел неудачу
* Как практики из IT помогают растить детей

В этом канале я стараюсь постить минимум три раза в неделю. Пока получалось. Кстати еще есть 🌄Instagram, где я выкладываю истории про свою работу, жизнь и Гамбург.

Спасибо, что присоединились 🤗 И спасибо старожилам, что еще здесь 🤝.

Application Performance Monitoring

Мы написали новый классный сервис. Что обязательно нужно сделать, перед тем как выкладывать его на продакшен? Много чего. У сервиса должны быть тесты, у сервиса должны быть логи, у сервиса должны измеряться бизнес метрики, + что-то еще, что нужно именно этому сервису. Но есть вещь, которую нужно интегрировать прямо везде. Это Application performance monitoring или APM.

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

Самое классное с APM — для того чтобы внедрить их сбор, как правило, нужно подключить лишь одну библиотеку. Например, можно сделать это с помощью NewRelic (платно 💸), их клиент поддерживает большинство языков (Go, Java, .NET, Node.js, PHP, Python, Ruby, C SDK). В Node.js буквально:

if (process.env.NEWRELIC_LC) {
  // eslint-disable-next-line global-require
  require('newrelic');
}

Такие библиотеки часто могут определить какой фреймворк вы используете (Spring) и дополнительно измерять что-то, что свойственно этому фреймворку. А еще, например, могут строить карту ваших сервисов, как они друг с другом взаимодействуют.

Есть и бесплатные решения, например, OpenTelemetry. Это решение с открытым исходным кодом, за него не надо платить кому-то, но нужно устанавливать его на свою инфраструктуру и потом рисовать дэшборды, в какой-нибудь Grafana. Зато тоже есть библиотеки для разных языков программирования.

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

Какие вы используете библиотеки для APM?

#хардскиллы

Кто такой фасилитатор

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

Но есть проблема, если группа большая или у участников еще не установилось доверие, то договориться сложно. А еще к группе приставили какого-то странного магического персонажа 🧙‍♂️ — фасилитатора. Он(а) вообще норовит превратить весь митинг в детскую игру с какими-то упражнениями. Нет бы просто хорошо поговорить и принять уже решение?

Давайте разберемся, зачем нужен фасилитатор. Начнем сразу с определения — задача фасилитатора, позаботится о том, чтобы каждый член в группе мог участвовать в решении вопроса лучшим образом ⭐️. Ни у кого не возникает сомнения, что лучшее решение группа может принять, тогда когда каждый из ее членов может себя проявить, верно?

Теперь по другому — у фасилитатора нет задачи помочь принять какое-то конкретное решение, фасилитатор не находится на чьей-то стороне. Он(а) просто помогают группе проходить процесс принятия хорошего решения. Сам, обычно, процесс состоит из нескольких частей — divergent zone, groan zone, convergent zone, closure zone. Сначала группа придумывает разные варианты решения проблемы; потом плотно их обсуждает, чтобы убедиться, что все понимают о чем идет речь; потом появляются лидирующие варианты, группа дорабатывает их и принимает решение.

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

⬛️ Еще раз — простые решения (business as usual) хорошо принимаются и без фасилитатора. Сложные решения тоже можно принять самостоятельно. А можно использовать роль фасилитатора, если кто-то выполняет эту роль, то он(а) помогает члену группы эффективно участвовать в решении проблемы. Фасилитатор, это не обязательно отдельный человек, член команды тоже может фасилитировать принятие решения.

Вы любите митинги с фасилитаторами?

#софтскиллы

👋,

Вчера мы начали (продолжили) говорить про то как здорово принимать решения группой людей и как с этим может помочь фасилитатор.

Сегодня хочу порекомендовать еще один канал, на который подписан сам — Нестыдная фасилитация. Канал ведут три Agile-эксперта — Саша, Женя и Оксана, они же — партнеры в проекте co-actors.

Я узнал об этом канале после подкаста 🎧 Podlodka #217 — Фасилитация, который, в принципе, обязателен к прослушиванию.

В канале девушки регулярно пишут обо всем, что связано с принятием решений и эффективной работе в команде. Эти темы актуальны не только для Agile-коучей, но и если вы разработчик или тимлид. Например:
* Как создать базовые договоренности в команде
* Когда у команды нет идей, что это может значить?

Хороший разработчик не индивидуалист, он работает в команде, и нам важно знать, как работать в команде эффективно.

Подписывайтесь: https://news.1rj.ru/str/no_shame_facilitation

Все стремится к энтропии

В каком-то источнике, я однажды прочитал, что в должностной инструкции Senior+ инженеров в Google указано, что часть их работы это “уменьшать хаос”. Сейчас, когда мне пришла идея этого поста, то я уже не смог найти источник, но это во мне срезонировало и я часто об этом думаю.

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

Существует даже физический закон “Закон неубывания энтропии” (беспорядка) — в изолированной системе энтропия не уменьшается. Информационную систему с внешними зависимостями сложно назвать стабильной. Поэтому, если перенести этот физический закон в наш абстрактный IT мир, то можно сделать вывод — если жизнь в нашей системе не поддерживать, то она точно сломается.

Проблема в том, что нельзя точно расписать все процессы, которые поддерживают в системе жизнь. Можно постараться, но все расписать точно нельзя. Если представить, что на каждое действие должен быть таск, то можно умереть ☠️ в бюрократии.

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

Примеры:
1. Заметил(а), что в README.md что-то уже не актуально? — удали
2. Заметил(а), что не хватает какой-то документации — добавь
3. Какой-то процесс не задокументирован? — напиши документацию
4. В Slack вашу команду о чем-то спросили? — ответь
5. Кто-то болел и потерял контекст? — созвонитесь и расскажите ему что произошло

Есть идиома "это последняя соломинка, которая сломает спину верблюду”. Одна из задач Хорошего разработчика это убирать эти соломинки, тогда спина нашего верблюда никогда не сломается.

Какие еще примеры приходят вам в голову?

#истории