Скоро на новую работу, а мозг, немного расслабившись от собесов, продолжает цепляться за новости связанные с прошлой.
То объявят о завершении поддержки одного из важных 3pl, а значит "ребята там с горящей ж..й сейчас ищут способы решения", то уязвимость прилетит в другом, не менее важном компоненте, а значит "а у ребят релиз сейчас... очередная пересборочка...".

Скучаю видимо? 🙂

#байки

Достаточно пессимистичная (ну или реалистичная) статья про то, сможет ли использование AI привести к снижению количества проблем при разработке софта и выполнению IT проектов в срок. Сравнивается то, что было 20 лет назад и сейчас.
Особенно забавно, что слово "quality" автор в принципе не использует. Оперирует просто "снижением количества failures" и рисками.

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

Со словом "риски" у меня с недавних пор сложные отношения, но в целом действительно, если отталкиваться от них, действительно можно получать более предсказуемые результаты проекта. Но работать с ними никто не умеет (я таких не встречал)...

#процессы #оценка

Кстати, про укладывание в сроки и оценку, в том числе проектов 🙂
Почти 10 лет назад я тут собирал в кучку полезняхи про "noestimates" (тут была ссылка ).
Там есть веселые картинки про то, насколько точными являются оценки сроков/бюджетов (по исследованиям 1994-2004).
Судя по вчерашней статье, за эти 20 лет мало что поменялось.

И вот в этом месте интересно, в чем секрет точности угадывания?
#процессы #оценка

Немного цинизма в пятничных #it_memes

Скоро во всех компаниях при подведении итогов года на корпоративах...
Инновации, меняя рынок, ценности, лучшая команда специалистов, профессионалы, достигли больших результатов, мы верим в вас, дальше будет лучше 🤝

Внеурочный нерекламы пост :)
Скоро Новый год. Если хочется подарить красивый подарок, сделанный от души, то заходите на странички моей жены. Если что-то понравится, то с промокодом "от Макса" 15% скидка 🙂.
В комментах есть немного фото и ссылок.

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

Team Autonomy Is a Beautiful Lie — Here’s What’s Really Holding Teams Back

Everyone claims to “trust the teams.” Yet the moment something goes wrong, leaders rush in to approve, correct, or steer. It’s as if the organization is saying: We empower you — but only when it’s safe for us.

И да, снова строится на доверии и прозрачности.

Real autonomy means letting teams make decisions you might not have made yourself — and standing by them as they learn.

If leaders keep rescuing teams from discomfort, autonomy becomes theater. The system feels safe, but no one grows.

There’s a quiet courage in stepping back. In trusting people with real responsibility. In accepting that mistakes are part of progress.

#management

Итак, немного про мои результаты 🔎 поиска работы (7 недель) для интересующихся.
По рекомендациям:
• Известных мне рекомендаций в конкретные компании - 10 (всем огромное спасибо ❤️)
• Созвонов с рекрутером - 5
• Собесов - 4
• Офферов - 3

Мои отклики - 5
• Созвонов с рекрутером - 1
• Собес - 1 (отказ после 1 этапа в пользу другого кандидата)

Интерес рекрутеров - 2 (все мимо моих ожиданий)

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

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

Для контекста:
- весной 2022 у меня было всего 3-5 полноценных общения с собесами за 3 месяца. Поэтому, для меня поиск в этот раз прошел проще.
- февраль 2025, поиск только откликами - 3 отклика, 3 собеса, 3 отказа.

Что спрашивают на собесах (спойлер, ничего экзотического и необычного, но всем интересно и куча вопросов в личке):

Общие, традиционно-классические вопросы:
- почему уходите (классно было отвечать на этот вопрос после Semrush, сейчас было сложнее)
- что ищете
- как будете выбирать между предложениями (вначале вопрос казался издевательским, тут бы хоть что-то)

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

Техничка:
- собес по системному дизайну: попалось проектирование месенджера, я его предварительно не смотрел 🫣, нахеровертил я там знатно, но имхо даже завелось бы, если б делать. Я оценил как "не прошел", но проскочило. Помог опыт по техничке Документов Онлайн (особенно CO часть, для тех кто в теме)
- просто вопросы "по верхам", которые все равно надо повторять при подготовке к системному дизайну (тут только то, что спрашивали, вспоминать нужно больше): типы и применимость баз, индексирование, шарды/партиции, база по REST, "вы вбили https://domain.ru в браузере, что дальше", балансировка, кеширование, +/- монолит/микросервисы, мониторинг, основные типы уязвимостей веб-приложений,

Как готовился к техничке 📝
1. "System Design. Подготовка к сложному интервью", Алекс Сюй. Еще рекомендуют "System Design: пережить интервью" (сам не смотрел). Новый ресурс для подготовки
2. "пролистал" кабанчика. Книга действительно не для подготовки к собесам, но пара вещей по БД оттуда пригодились :)
3. Общение с ИИ ботом в Chrome: "способы балансировки трафика", кеширования, "как сделать CDN", "как...то/се". Если в ответах, что-то из мне неизвестного - расширяю поиски в ширину. Получается, что типа ответа на пару страниц
4. Ну и далее список вида:
- балансировка + мониторинг
- кеширование + мониторинг
- БД (выбор, типы, реплика, шарды, патиции) + мониторинг
- мониторинг вообще +observability +SL[IOA]
- ИБ (OWASP + самые популярные проблемы) + для каждого из пунктов списка выше тоже смотрю ИБ-проблемы
- деплойка (канарейка, блю/грин и тп)
- кубер по верхам посмотрел, просто базовую концепцию
- микросервисы (база, +/- подхода, стейт-фул/лесс)
- C4

#вопросы_с_собесов

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

The cost of producing code is approaching zero

До изобретения печатного станка Гутенберга книги были дорогими. Переписчики копировали рукописи от руки. Предложение было ограничено, строго контролировалось и оптимизировалось для сохранения, а не для масштабирования.
...
Сегодня код находится там же, где были рукописи в 1450-х годах: дефицитный, медленный и зависящий от экспертов. LLM начинают играть ту же роль, что и печатный станок для текста: снижая издержки на производство артефактов.

...

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

Наиболее затратные компоненты ПО смещаются вверх по цепочке: выбор задачи, интеграция, эксплуатация, управление рисками и изменения с течением времени.

...

Если вы сегодня занимаетесь разработкой ПО, ваше преимущество смещается от знания фреймворков к знанию предметных областей и пользователей; от реализации функций к выбору тех функций, которые действительно важны; от принципа «действуй быстро и ломай все» к обдуманным действиям и ответственности.

В комментах немного веселых картинок из The State of AI coding

не мои #мысли_вслух #it_философия

Специализированный OWASP Top 10 for Agentic Applications 2026
Немного для тех, кто судорожно пытается хоть как-то придумать, как оценить все новые "AI фичи" на безопасность.

#tech_read #security

Ох уж эти декабрьские мошенники в пятничных #it_memes

Стремление к предсказуемости

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

Наиболее распространенное решение — больше внимания уделять планированию.

Более подробные дорожные карты. Больше отслеживаемых зависимостей. Часто больше встреч, просто чтобы «подстраховаться».

И почему-то предсказуемость все равно не улучшается.

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

В результате они получают лишь показную игру.

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

Это не так.

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

В течение многих лет я просил команды оценивать объем работы с заданным уровнем точности: не с указанием конкретной даты, а с указанием вероятности.

Не «когда это будет сделано», а «на какую дату вы уверены на 50 процентов».

Это число имеет значение.

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

При 90-процентной уверенности команды перепланируют. Они затягивают. Они откладывают обучение во имя безопасности.

При нулевой уверенности команды бросаются в бой вслепую и потом расплачиваются за это.

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

Когда релизы непредсказуемы, руководители часто сосредотачиваются на симптомах. Они просят более четкие даты. Они требуют более ясных обязательств. Они подталкивают команды к тому, чтобы те «взяли на себя» ответственность за выполнение. Они увеличивают количество отчетов.

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

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

#процессы #management

Иногда (редко, но бывает) я чуток переживаю за небольшой объем именно "авторского", самописного контента в канале.
А потом вспоминаю, что канал ведь не только (и не столько) для вас, мои дорогие читатели, а больше для себя.
Поэтому тут часто и появляются заметки-микро-конспекты "тырнетов". Мне потом удобно к ним возвращаться при необходимости.
Регулярное чтение и "конспектирование" "внешки" помогает мне утрясать свои собственные мысли в голове, находить им поддержку или, наоборот, добавлять аргументов сомнениям.

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

#мысли_вслух #байки

Подводя итоги года.
5-ка лучших самописов по комбинации просмотров/реакций/пересылок.
Всеми любимые #it_memes и посты про поиск работы вне конкурса 🙂.
• Про автоматизацию тестирования (хотя согласен, картинка там мемная, чит)
• Кейс “команда предложила решение, но оно кажется вам неправильным - что будете делать?”
• Про серебрянные пули
• Про документирование принятых технических решений
• Про переработки
Если аннулировать результаты для первого поста за чит-картинку, то в топ попала, чему я рад, история болотной сосны.

Вот прям весь я в 6 постах, прикольно получилось. Не добавить/не отнять.

2025 заканчивается.
Год, а особенно его финиш, был очень насыщенным на эмоции, и на работе, и дома.
Пусть в следующем году у вас все получается, а ваше сердце и разум придадут вам смелости в своих решениях.
Ваш Айтиболит 🎄🎅🏻

А давненько ничего не было про тестирование.
И сегодня хочется запустить тред про то, как вы оцениваете баги на критичность.
Я не тестировщик, istqb-ов не сдавал, поэтому мне можно рассуждать не как на собесе, а тестировщики приходите в комменты и говорите, где я ошибаюсь.
Все давно знают, что у бага есть его приоритет и суровость (нравится мне такое определение severity от Алексея Лупана).
И если с каждой из этих характеристик по отдельности +/- все понятно, то как они между собой связаны (или не связаны) - вопросов может быть немало.
Означает ли приоритет "критичный", что надо брать в работу "бегом" и если означает, то зачем тогда нам еще и "суровость" в принципе? А может баг быть мегасуровым, но с минорным приоритетом? Надо ли его тогда чинить в принципе (все же помнят про ZBP)?
Можно ли багу ставить приоритет повыше, чтобы команда взяла его в работу быстрее, ну или хотя бы просто когда-то взяла?
И в какой момент, и кто решает, что это крит или мажор? И, главное, почему тот баг крит, а этот мажор?

Как много вопросов по такой простой(?) теме.

Продолжение

#testing

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

Давайте уйдем немного в сторону. Не очень люблю аналогии, но в медицине тоже есть свой механизм сортировки (пациентов): Manchester Triage System. Возможно там есть на что посмотреть и довернуть для сортировки багов.
Ключевая идея этой системы заключается в том, что вместо «насколько важен этот пациент?», определяется «как долго этот пациент может безопасно ждать?». Клиническая потребность определяется по степени срочности, а не по важности (суровости?).
У себя мы тоже обычно пытаемся понять: «насколько это важно?». А что если думать над вопросом «как долго мы можем не чинить этот баг?», ну или хотя включить его в список вопросов, на которые пытаемся ответить при сортировке багов.

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

Почему нельзя сделать так же и для себя?

Определяем типы проблем (вертикаль) и формируем диапазоны пользователей (горизонталь) с точки зрения вероятности наступания в эту проблему (вероятность — самый скользкий момент, иногда ее сложно определить объективно). Получаем матрицу heatmap, где в местах пересечения фиксируем приоритет, с которым проблема должна решаться. То есть суровость, как и предлагали в комментах, становится понятным источником определения приоритета, а не просто одним из свойств бага.
Прозрачно, понятно, единообразно.

ЗЫ пример возможной хитмапы в комментах. Просто для примера, не надо спорить по тому, как там цвета нарисованы 🙂 Хотя, думаю, многие ее узнают, авторский апрув получен.

Осталось только понять, а можно/нужно ли вносить какие-то коррективы в приоритет полученный по хитмапе (спойлер, конечно да, но есть нюансы) и как этот процесс триажа может выглядеть.

#testing

Ну че, мой онбординг в пятничных #it_memes

В ленте пролетела рекомендация этого бесплатного курса по фаззинг-тестированию на базе книги "The Fuzzing Book. Tools and Techniques for Generating Software Tests".

Как говорится "не смотрел, но одобряю" (но книга действительно рекомендательная).

#test_automation #testing #tech_read

Architecture Intent Checks try to do this same thing, and they work on the principle that most decisions make perfect sense to anyone with the same context. They’re non-blocking because the default assumption is that it’ll be the right decision (or at least right enough!). When we get it wrong, we learn fast, course-correct, and move on. The cost of occasional mistakes is far lower than the cost of making everyone wait for permission.

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

Много вопросов, мало ответов. Но сам подход нравится.

Letting Teams Make Occasional Mistakes Costs Less Than Waiting for Permission

ЗЫ Architecture Intent Checks - это что-то типа RFC/ADR, для фиксации принимаемых решений, но их обсуждение не блокирует дальнейшие работы.

#management

The Goal of Compensation is to Create the Most Talented, Enthusiastic Team That Your Budget Allows

Цель системы компенсаций — создать самую талантливую и энергичную команду, которую позволяет ваш бюджет.
Это может показаться очевидным… но ваша главная цель при управлении циклом компенсаций — максимизировать талант и энтузиазм вашей команды. Точка.

Ваша цель — не сделать людей счастливыми.

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

Ваша цель — не получить «выгодную» цену за оплату труда сотрудников.

Ваша цель — не соответствовать рыночным условиям.

Ваша цель — не соответствовать тому, что платит <другая компания>.

Ваша цель — не соответствовать ожиданиям сотрудников.

Ваша цель — не платить одинаково (хотя часть вашей цели — обеспечить справедливость).

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

Звучит все красиво. Недалеко от правды. Но есть нюансы. Самое сложное конечно это баланс "бюджет - талант команды - цели бизнеса".

Там в статье еще есть про то, что ЗП не делает счастливым, но легко делает несчастными, ну и про то, разговоры про ЗП все равно ведутся между людьми и вам нужно уметь объяснять про "справедливость". Ну и про то, что компенсация - это не только ЗП.

Кстати, около года назад уже была заметка про "алгоритмы промоута".

А 10 лет назад был доступен хороший доклад про премирование в IT. Сейчас только слайды остались :(
В премии для инженеров, на самом деле, мало кто умеет, ровно потому что не соблюдаются условия прозрачности и своевременности. Ну и премии за KPI/MBO для менеджеров приводят к тому, что все вместо работы начинают всё тащить к этим буквам. Но это уже совсем другая история... :)

#management

А все уже закончили со своим performace review? А то тут лайфхаки подвезли. И хочу отметить, что они вполне себе годятся, если менеджер не парится с тем, как это все устроено. Можно использовать в этом году, чтобы в следующем быть готовым и во всеоружии.

Про сами ревью писал тутъ и тутъ. И про сопутствующие калибровки тоже.

#management #процессы #развитие