В IT чудес не бывает

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

#tech_read #security

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

The cost of producing code is approaching zero

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

...

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

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

...

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

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

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

Итак, немного про мои результаты 🔎 поиска работы (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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#байки

Теперь я знаю, как это называется по-умному, феномен Баадера‑Майнхофа.

Ну и один из любимых (не устану этого повторять) авторов из подписок.

Quality is a System
quality isn't something you make - it's something that comes from the system

Там можно каждую строчку в цитаты, и про ответственность с виной, и про героев и тдтп.

PS главное, чтобы хватало сил, желания и времени строить системы до того, как все вокруг снова меняется 🙂
А то на собесах рассказываешь про вот это все: прозрачность, ожидания, доверие, все кивают, а что на самом деле думают неизвестно.
Хотя, нет, было уже "а вы сами верите, что это все работает?".😃

#quality #процессы

Летом коллега подарил мне книгу с напутствием "читается тяжело, но дочитай до 200 страницы".
Читалось действительно тяжело.

Но дойдя до этого слова и посмотрев на номер страницы, я понял, почему он мне ее вручил :)

Это было слово "Качество".

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

ЗЫ Паша, прости, я помню, что мы договаривались это все помусолить вместе, но пока не срослось :)

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

Как-то неожиданно долго от меня "прятался" очередной "закон", который на самом деле часто подтверждается в жизни.

Закон Галла

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

Теперь осталось понять, что такое в этом месте, "простая" система и "сложная" 🙂

#it_философия

Технические приемы для переписывания бека, чтобы не отломать фичу на проде:
- для API на чтение просто сравниваем то, что отдает старое и новое (Tap compare testing)
- для API на запись дублируем БД и дальше сравниваем состояние БД через API на чтение

Modernizing Reddit's Comment Backend Infrastructure

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

#tech_read #testing

И снова про структуры, но совсем организационные, а параллельные 🙂
Shadow Structures: The Unofficial Systems

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

И наступает "мы порешали в личке".

#процессы #management

PS надеюсь, те из подписчиков, кто еще не менеджер, хотя бы краем глаза смотрят эти все "менеджерские" заметки/статьи для подпитывания мыслей "а оно мне точно надо?" 🙂

State of testing 2015 vs 2025 (простите, меня уже чуток тошнит от подготовки к собесам по сисдизу, решил занять голову чем-то другим, просто стало интересно)

Короче: ничего в глобальном смысле не поменялось, какие-то болтания туда-сюда (особенно если сравнивать 2013, 2015, 2023-2025) 😃.
А с учетом того, что это еще и разные люди отвечали, я бы даже сказал разные поколения, то выглядит как "С - стабильность" в отрасли.

Сами вопросы я не стал искать, но похоже они и методика обработки видоизменялись за эти 10лет (что логично).

Да в 2015 были модные фишки в виде Big Data Testing, Testing in Cloud и чуть больше Agile.
Сейчас больше про ИИ (рекомендую глянуть в доку, там интересно посмотреть по ИИ), а Agile поменьше (он скорее всего "трансформировался" и стал просто частью процессов "как все привыкли").

Состав участников опроса по job titles практически без изменений (из самых интересных позиций):
• лиды/менеджеры ~38%
• тестировщики ~35% (если объединить test engineer/tester в итогах 2025)
• автоматизаторы ~7%

Если принять голосовавших за срез отрасли тестирования в 2015 и 2025, то выглядит так, что лидов в отрасли что-то многовато, а количество автоматизаторов не растет (и слава Байту).
Но, в небольших компаниях автоматизаторов больше (2015) - до 12%. Отсюда можно предположить, что если хочешь двигаться в автоматизацию - лучше небольшие (типа 50-100 человек) компании, что в целом схоже с моими мыслями по этому вопросу.

Что касается покрытия автоматизацией, то как будто то на то и выходит: у 55% опрошенных, автоматизацией закрыто < 50% сценариев. И у 20% покрытие в районе 75%+
Кто-то даже декларирует полный отказ ручных проверок: 💪, ну или 🤡, тут уж кому как.

Важность программерских скилов неожиданно снизилась (снова ИИ-шка?), Ops тоже не в фаворе (видимо из-за того, что выросла отдельная ветка DevOps - Test/простите/Ops)

Зато в 2025 резко выросла важность коммуникационных скилов 🤔

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

Кстати, недавно обсуждали про TMS и то, что без них "нельзя": в 2015 65% пользовались Excel-ками (+вордом и почтой), как рабочим инструментом. Правда и TMS тоже было достаточно много.

PS но первые отчеты (2013, 2015 мне больше нравились, они больше именно про тестирование что ли).
Сами отчеты будут в комментах. Вдруг кому-то захочется глянуть 🙂

#testing #байки

The Hidden Architecture of Engineering

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

You don’t redesign an organization because it’s old. You redesign it because something isn’t working.

The real question isn’t “what structure should we have?” It’s “what problem are we solving, and what design will align our teams to solve it?”

Structure is strategy made visible. A good design aligns incentives, communication patterns, and ownership boundaries with your goals. It creates high-bandwidth communication where you need it and separation where you don’t.

#процессы #management

Когда я уходил из МойОфис, естественно была куча вопросов о причинах, в том числе “сам” или…

Сам 🙂 и да, я по-прежнему готов рекомендовать компанию.
Понятно, что публичной конкретики причин вы тут не дождетесь, но можно пообщаться на собесе 😃

Недавно, разбирая долги по “вычитке интернетов”, добрался до статьи The Hidden Reason Great Engineers Quit
И хотя я не “great engineers” (но определенно неплохой менеджер), моя история очень легла в “Because the moment they stop learning… they start leaving.”
Учиться можно всегда и везде. Просто если приходится учиться тому, чему не хочется, то ты тоже “stop learning”.

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

#management

🫣 "Простите, часовню тоже я развалил?" (с)

#it_memes вокруг нас

Очень давно тут была ссылка на серию статей про подходы к тестированию микросервисов.

Думаю, что этот интересный доклад от автора WireMock, хорошо их дополнит.

● Modern mocking tools used wisely can simulate sufficiently realistic behaviour for most development and testing tasks
● API observability + mock generation + contract testing reduces effort and increases confidence
● Use GenAI with contract testing guardrails for further, safe productivity gains

Слайды будут в комментах.
Видео можно посмотреть только с регистрацией на infoq.com.
Ссылки на демо-проект и страницу-лендинг по докладу

#test_automation #tech_read

Реорганизация
Думаю, что один из самых сложных моментов в работе менеджера.
Много предваряющих вопросов и сомнений, если задумал сам.
Не меньше вопросов, еще более "интересных", если это происходит неожиданно для тебя.
Какие-то реорганизации радуют, продукт развивается, команда растет и это требует изменений в оргструктуре. Например, разделение команды.
Какие-то реорганизации вызваны не логикой, но обстоятельствами.
Недавно на одном из собесов меня спрашивали про мои самые большие ошибки, так вот, сходу, только затягивание реорганизации пришло на ум - опасения последствий побеждают чаще и, соответственно, принятие решения откладывается.
С другой стороны, перед глазами было много примеров, когда проведенная реорганизация не достигает своих целей, кстати, не всегда озвучиваемых публично, а просто сводится к изменению структуры.
Осторожные же движения в эту сторону могут вызывать ощущение тягомотности, когда возможные переживания у людей растягиваются по времени. Иногда может казаться, что один раз “рубанул” и погнали тюнить. Но всегда есть нюансы, в том числе такие:

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

Чем все это было навеяно - как обычно, лентой подписок:
5 Strategic Things Every Manager Should Do After a Reorganization
5 Essential Things Every Leader Should Evaluate After a Reorganization

и еще немного про реорганизацию

#процессы #management