Про позитивные кейсы

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

Нет, оно понятно, что компании нужно качать ичар бренд, да и о своих факапах рассказывать не очень принято (рушит пёрсонал бренд и магию!). Но я бы с удовольствием сходил на что-то типа:

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

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

Потому что разработка сама по себе это череда личных минифакапов и их исправлений, названных красивыми словами дебаг и рефакторинг.

Работа на медленном интернете как критерий качества продукта

Опять абстрактная трепология про продукты, но мое горение от качества некоторых продуктов сильно повышает температуру окружающей среды. В следующем посте точно про технику будет.
 
Я сейчас в отпуске и при заезде получил бесплатную опцию "Интернет-целибат". У него сломался роутер в районе моего дома и за слабеньким публичным интернетом нужно идти 500 метров на  рецепцию. И вот я уже почти месяц использую свои мобильные и десктопные приложения в условиях плохого качества связи.
 
Почему-то с точки зрения технарей и продактов, это считается редким кейсом. И я говорю не про абстрактную заграницу, когда душит жаба купить симку. Почему-то они считают, что у нас везде есть шустрый wifi, 5G и нет ни одного магазина/пункта выдачи в подвале, где ловит только 0.5 палки.
 
У абстрактного меня повысится NPS, если:
• Я нахожу фото своего заграна в фоточках, отправленных жене за 2021 год
• Точно знаю, что эта заметка синхронизируются на ближайшем интернетопое и я ее допишу с компьютера
• Я открою приложение магазина для загрузки штрих-кода где-нибудь на -1 этаже и оно мне не выдаст идиотского онбординга, а быстро покажет номер заказа.
 
Да, это требует дополнительных когнитивных и разработческих затрат и вообще проще прикрутить какой-нибудь радужный онбординг, который якобы нальет пользователей в воронку. Только пользователям часто нужна база, а не RGB подсветка текста.
 
Это, кстати, касается любого микросервиса, сервиса или софтины. На меня коллеги смотрели как на колдуна, когда я предусмотрел сценарии таймаута для HTTP запросов(!) и возможности неприхода ответа в очередь.

Про технические нефункциональные требования

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

Как оказалось, в той системе были большие проблемы с Testability и Configurability. Проще говоря - писать автотесты дольше, чем кодировать, а локально развернуть и протестировать невозможно - только на окружениях. Тестировщики-ручники тестировали по наитию, без внятных тест-планов или всяких трасибилити матриц. Вопрос: что будет с проектом?

На другой проекте пришел эйджайл-коуч-трансформер. Знания его в технике сводились к словам "Девопс", "Юнит-тесты" и "Континиус интегрейшн/деплоймент", но с руководством он общаться умел. Ему дали натягивать скрам и двухнедельные релизы на группу внутренней автоматизации (это те ребята, которые пишут сугубо бек-офис). К самим разработчикам претензий не было, но у ребят был нулевой показатель Deployability. Простым языком - "для раскатки нужны особые Литании Раскатки и пара техножрецов для вознесения молитв Духу Сервера". В обшем, через n месяцев мучений, скрам не взлетел. Нервов разрабам потрепали изрядно, денег потратили порядочно. Самое интересное, что эти двухнедельные релизы бизнесу были не нужны и ему дали эту группу как пилот.

А как нужно-то делать?
Если вы стартуете или начинаете трансформировать проект или команду, нужно подключать грамотных технарей и выписывать все NFR, включая технические. Грубо говоря, делаем аудит и уже потом решаем, нужно ли что-то делать. Объясню на примере:

Дано:
- Бизнес с очень глубокими знаниями в доменной области
- Домен с очень специфическими бизнес-процессами
- Группа матёрых разработчиков-сениоров и сениорит
- В целом, ошибки допускаются - есть возможность откатить косяки в проде

Ход размышлений:
- Аналитик не особо поможет, потому что домен начисто отбитый. Это наоборот замедлит разработку и внесёт помехи. Т.к. разрабы опытные, то даём общаться им напрямую с бизнесом.
- Бизнес не будет писать портянки требований, а постоянно давать обратную связь. Значит, нам нужно делать малые каденции и часть деплоить (даже раз в день). Значит, выкручиваем на максимум Deployability.
- Нам нужен постоянный регресс из-за частых поставок и сложных требований. Значит, затачиваем Testability на интеграционные автотесты. Нужен ли тестировщик? Если есть очень грамотный, то можно для UAT. Если обычный - то будет мешать.
- Чтобы все было +/- стабильно, мы разрабатываем тактику Integrability (чтобы не толкаться локтями и обеспечить обратную совместимость).
- У нас нет серьезных требований по Reliability, значит все, что написано выше, может работать.

Выводы:
То, как у вас работало на прошлом проекте, может не взлететь в этом. Даже в той же компании, даже у того же бизнеса. Используйте цифры и здравый смысл при трансформациях и других вмешательствах в команду.

Про оценку задач

Делаю доклад на СайнтТимлидКонф 2025 и у меня скапливается как-то много материала. Поэтому буду выливать излишки в уютную группу.

Первая и самая большая проблема оценки задач в айти - это непонимание, кто есть ее потребитель и зачем она делается.

Допустим, к работяге пришел менеджер и спрашивает "оценки". Так вот, когда работяга даёт свои "эээээ нууу пусть 5 сторипоинтов" или "нуууу до конца недели сделаю, если ничего не прилетит", то что он имеет ввиду?
Варианты:
1. 40 его полноценно рабочих часов чистейшей разработки
2. Срок разработки до теста + багфикс + доталкивание до приемочного стенда с учетом рисков и интеграции
3. Срок доталкивания этой задачи до теста с учётом влётов и текущих задач, что он пообещал до конца недели еще трём людям.
4. Сложность выполнения задачи в соответствии с DoD

Сообразительный читатель ответить мне - а х&* его знает зависит от контекста и будет прав.
Работяга ориентируется на комбинацию своего опыты текущего/предыдущего проекта, возможных рисков, знания расписания отпусков девопсов и тестировщиков, объем входящих за сорванные сроки.

И менеджер, который собирает эти оценки и составляет план, либо не спрашивает, либо не говорит, что ему нужно. А потом в соответствии со своими детскими травмами делает расписание проекта деля 40 на 8. А потом это уходит к руководству как жесткий коммит и начинаются переработки, подвиги и выгорания.

Я наблюдал лично случай в одной крупной компании. Менеджеры собрали вот точно таким же образом оценки с работяг, составили план, расписались под ним кровью и продолбали все сроки. Когда собрали ретроспективу, то прозвучало самое топовое предложение "Ребят, а давайте договоримся, что значит - "сделано". Это докатка до теста, до прода или раскатка на всех пользователей всех платформ?"

Вот для этого и нужно создание системы оценки, про которую я и расскажу.

Не экономь на архитекторах

Есть API, который создаёт заказ. В случае успеха - возвращает его ID и эхо-ответ. Вопрос: что должен вернуть сервис в случае ошибки?

Варианты ответа:
1. Нормальный ответ со специфицированной ошибкой и нормальным HTTP кодом
2. Пустое тело с id = 0
3. Эхо-ответ без id
4. Ошибку текстом (типа стектрейса или General Error без описания)
5. Отвалиться с таймаутом

Правильные ответы - 2-5. Причем, конкретный вариант зависит от данных. Писала её скрум команда мотивированных профессионалов, все на собеседовании решали задачки по кодированию. Поэтому и техлиды/архитекторы не нужны, всё просто же, зачем нам проектирование.

В итоге, вместо пары дней разработки с тестами, я страстно занимался интеграцией где-то недели три. Если не учитывать мои нервы, это стоило много денег заказчику за работу + стори, которые я не делал (упущенная выгода). А всего-то надо было взять архитектора для написания спеки ДО или сделать архитектурный надзор в процессе/после. Да, жаба давит отдавать даже кусочек ставки на дорогого специалиста, но это окупится потом многократно.

На волне оптимизации расходов ФОТ (увольнения айтишников на мороз), коллеги вокруг стали спрашивать про то, как сохранить тёплое место и большую премию.

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

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

Что является хорошим фактажом?
1. Факты с Performance Review
2. JIRA - количество тикетов, стори поинтов, часов
3. Выполненные цели (квартала/года/окры или еще что)
4. Обычный 360 (отзывы коллег)
5. NPS (отзывы от заказчика)
6. Участие в активностях (хакатоны, выступления)

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

Я тут всё за правильное observability выступаю, вот и решил сделать цикл статей про то, как я делаю у себя. Сложность пойдёт по нарастающей. Любые неточности я себе заранее прощаю 😌

https://bulov.org/tpost/6nbpv5ty41-pro-pravilnoe-observability-chast-1-corr

Про нейросети и увольнения

Тут последнее время хайпят, что нас AI скоро заменит и мы пойдём на стройку работать. Ну, всё так 😊

Нейронки - это отличный инструмент избавления от рутины и увеличения производительности. Условный Copilot умеет и тесты написать и в коде подсказать что и посочувствовать. Экономит это от 20-40% времени (зависит от контекста), которое можно потратить на фичи.

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

А если ты боишься, что тебя может заменить "умный code completion", то пора идти учиться...

Сейчас 10 минут спорил с тестировщиком про правила сортировки в базах. Она утверждала, что символ '(' должен идти после букв - т.е. '(ABC)' должно быть после 'ABC'. Отсылки к таблице UTF-8 и кодовым точкам не помогли, она твёрдо стояла на том, что так неправильно. Пришлось отравить её разбираться к бизнесу.

Упорство и уверенность в себе - это хорошие качества для тестировщика, они помогают делать отличные продукты! Главное при найме не перепутать их со слабоумием и отвагой...

В начале недели подсмотрел баг на проде у коллег. Я был в рассылке и повёлся на кликбейтный заголовок письма. Пошел искать в графану медь, а нашел золото... На микросервисном ландшафте без оркестрации (там подобие хореографии) есть бизнес-транзакция. Если что-то падает во время выполнения, то шлётся сообщение в error handler microservice и он уже делает рассылку каждому микросервису для отката транзакции.

Оказалось, что:
- не обрабатывается состояние, когда сам error handler упал с ошибкой
- нет самодиагностики по проверке состояния текущих процессов (что кому и когда мы послали и на каком этапе находимся). И если моргнёт условный rabbit или k8s, то rollback не произойдёт
- запрос на откат шлётся в одну сторону и нет гарантии отката в принципе
В результате, через годик мы получим n неконсистентных баз или постоянные ручные откаты. Смотря на это системно, делаю вывод, что коллеги не понимают базовые принципы конечных автоматов.

Когда я в 12 лет учился писать на турбо паскале и сях, нас перед кодированием заставляли рисовать блок-схему и таблицу переходов на бумаге. Потом её надо было защитить. Бомбило у меня жутко, ибо иногда я до кода не доходил вообще(!), а занимался два часа черчением. По прошествии лет 10 я понял, что именно это рисование из меня архитектора и сделало. Ибо алгоритм/транзакция/взаимодействие внутри микросервисов должно иметь состояние на входе и выходе. Никаких подвисших веток быть не должно!

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

Ворвался на мой любимый STL Conf, выступил с презентацией. Скоро довыложу доп. материалы

Вайбкодинг - строго для сениоров

Я тут втянулся в прошлом году в фуллстек и вернулся к UI на React. Примерно в это же время любимый работодатель подогнал платные модели в Copilot, и тут я решил, что это судьба.
Напишу впечатления рандомным набором пунктов:

1. Grok, младшие GPT, Gemini пишут лютейшую пятикратно переваренный индусский код в самом худшем понимании. Для бытовых вещей, виртуальных коучеров и раскладов натальных карт ChatGPT великолепен, для кодинга - категорически нет.

2. Claude Sonnet - единственная адекватная модель, которая может в UI и бэк (хотя, в Котлине, всё же, слабовата). Да, она стоит дорого, но я даже был готов из своих заплатить, когда она кончилась.

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

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

5. Модель базы/доменную модель делают все ИИшечки крайне плохо. Получается какая-то мешанина из enum'ов, странных малых объектов и строк.

6. UI генерить нейронкой сплошное удовольствие. Если дать копилоту скриншот из Figma + описание модели (с бека или просто JSON), то он напишет почти pixel perfect интерфейс.

7. ИИшечка расхолаживает и немного отупляет. Я всё чаще выделяю код и пишу fix this, что мозги не тренирует.

Резюме: нейронка - это как гениальный джуниор кодер с которым ты сидишь и делаешь pair programming. Если ты молодец, то и код будет хороший и приложение классное. А если ты сам джун, то получится "два дебила - это сила". Поэтому никогда, никогда не отдавай писать ИИшке то, что не можешь написать сам.

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

Но есть нюансы:
1. За такую экономию хорошо бы платить разработчику хотя бы x2, но ведь никто это делать не будет (Иди, иди. Шуруй, шуруй. Начальнику - премия, рабочему ...).
2. Менеджмент по старой привычке любит хедкаунт (количество голов). Де как больше народа - выше производительность (это не так). Да и ранг выше, если у тебя людей больше.
3. Менеджеры боятся бас-фактора - уйдёт звезда и всё, встала разработка.
4. А давайте нашей команде дадим подписку на хорошую нейронку и они каааак заперформят (нет, будет куча нейрослопа).

Так что пока у начальства не поменяется майндсет, будет работа у джунов и сениоров.

Про личный брэнд

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

1. Нормальный доклад - 40-60 часов времени.
Под нормальным я понимаю: личный опыт, отрепетированное выступление, высокий уровень знаний и контента в докладе, отсутствие чата гпт. Я не говорю сейчас про коучеров/тренеров, для кого это один из каналов для привлечения лидов, там другая история.

2. Годная статья - часов 8 минимум. Ибо нужны примеры, базовая вычитка, переделки. У меня лежит куча болванок, но где примеров нет хороших, где шлифануть надо. Но времени тупо не хватает.

3. Если ты профессионал (работаешь с отдачей свои 5-8 часов), то мыслетоплива остаётся к концу дня только на каточку в Доте или час-другой поучиться. Когда статьи строчить?

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

Подгорел вчера, зайдя в бложик одного технаря. Начал потреблять контент и почувствовал какой-то мерзкий вкус нейрослопа во рту. Вчитался - да, всё так. Зачем? Чтобы что?

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

PS: подумалось, что если прогнать такую статью через чатгпт и сделать краткую выжимку, то получится еще одно звено человеческой многоножки.

PSS: закину на днях крафтовую статью про проведение 1:1

Я сразу вспомнил как мы в 2012 году писали De-Mail - точно такую же платную Национальную Электрическую Пошту для Германии.
Немцы, с которыми мы ее писали, сами ржали над мертворожденной концепцией. Естественно, никто в здравом уме не стал ей пользоваться и Телеком ее закрыл в 2022 году.

Но какие были классные командировки в Дрезден! До сих пор вспоминаю мою любимую команду Гуёвых, пляски вокруг Гейтвея, Weiße Gasse, Вацке Баллхаус, поездки в Прагу...

Преза с доклада на SaintTeamLeadConf 2026 про Алгоритм создания и приоритезации тех беклога