Чудес не бывает или я ошибаюсь?

В блог стал меньше писать, потому что он в моей голове предполагает сейчас какую-то долгую предварительную работу со статьей. Черновики у меня годами лежат. Поэтому, встречайте телеграмм-канал, лайт-версию блога: появилась мысль - отправляется в канал. Тематика та же самая, Подключайтесь . Из мариновавшегося годами тут, но уже появившееся в телеге: Team- vs TechLead Ошибки приводящие к проблемам в IT Про календари менеджера и инженера

Побеседовали с Мишей про эту "магическую" сущность, а он смог классно переработать содержимое нашей беседы и кучи других материалов. Я теперь даже не уверен, какие именно мысли мои :) Но там все по делу. Ну и самое главное про легаси: 1. это про то, что нужно (иначе бы выкинули) 2. это то, что с вами всегда* ** *если вы не меняете работу каждые полгода после написания нового кода **но уровень боли от легаси можно уменьшить - статья как раз про это

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Митоз клетки команды Если продукт или набор сервисов, которым занимается команда, успешно развивается, задач становится все больше, размер команды растет, рано или поздно вы приходите к мысли о трансформировании команды в несколько команд.  Иногда это происходит "органически" - в продукте есть свободно отделяемая часть, которую можно передать новой команде. Иногда все сложнее - продукт разделить тяжело и само разделение драйвится тем, что просто людей становится много (или нужно больше) и текущие процессы становятся неэффективными, а результат работы сложно прогнозируемым.  Я наблюдал 3 варианта "рождения" новой дополнительной команды для существующих задач (речь здесь и дальше не про запуск нового продукта, а про дополнительный импульс в развитии существующего): - команда формируется с нуля. Самый сложный вариант, который скорее всего подойдет, когда процесс работы уже заточен под "многокомандность" и новая команда - это лишь еще одна шестеренка в настро

Возрастной философии твиттер-тред , который я решил переложить в статью, заодно попытавшись поправить правописание. Ну и ссылку на заметку сейчас удобнее отправлять, чем ссылку на твиттер. А желание ее кому-нибудь отправить по-прежнему иногда возникает.   Уже даже не помню, чем было навеяно. В лучших традициях твиттерского жанра "дед ноет". Все как положено: нытье, без конкретных примеров действий и противодействий.  Где-то плюс/минус несколько дней в это время 20 лет назад (тред писался в феврале 2021) заканчивалась моя военная служба и я уже официально (а не в самоволку, как было несколько месяцев до этого) ходил писать новые компоненты для Delphi-библиотек. С тех пор много чего (все?) поменялось в IT-отрасли, но речь сегодня пойдет не про технику.  А будет про людей. Даже скорее про конкретного человека в моем лице, как и что менялось во мне за эти 20 лет, отношение к возрасту, возрастные фобии если хотите :) После увольнения, наверное около 10 лет кряду, возраст коллег не

На базе треда в тви. Признаться, я давно не провожу "каноничные" 1:1.  В 1-ю очередь из-за того, что "каноничность" предполагает регулярность. Практика скорее полезная, но эффективность зависит от многих факторов. Например, количества тех, с кем надо проводить, процессов в командах и твоем в них участии. А я не люблю делать то, что просто "общепринято", но пользы не несет или ее меньше, чем затрат хотя бы времени.  Ну или просто терпения не хватает дождаться реальной пользы. Чаще получаются не классические 1:1, а встречи по онбордингу новичков, обсуждению планов развития, беседы с ребятами, которые сами приходят с запросом. Моя "дверь" для такого всегда открыта и я всем постоянно и везде про это напоминаю. Тем не менее, всегда полезно иметь списочек вопросов, которые можно обсудить: 1.  Вопросы для первой встречи  2. Хорошая замена традиционного вопроса " How's everything going?" -> "What's one thing that could be bett

 Про то, что менеджмент  - это не единственный путь развития :)