Никого не повышают за простоту

Инженер A делает фичу за два дня: пишет 50 строк понятного кода, тестирует, выкатывает.

Инженер B берёт ту же задачу, но строит «масштабируемую архитектуру»: добавляет pub/sub, новые абстракции и фреймворк для конфигурации. Тратит три недели.

На performance review работа B звучит как готовый кейс: «спроектировал масштабируемую событийно-ориентированную архитектуру, внедрил переиспользуемый слой абстракций». Работа A звучит как «сделал фичу X». Никто не получает повышение за ту сложность, которой он избежал.

Индустрия системно поощряет оверинжиниринг:

— На собеседованиях кандидаты рисуют сложные схемы с микросервисами и шардированием, потому что простое решение с одной БД кажется интервьюерам недостаточно «умным»

— На код-ревью простые решения обрастают абстракциями из-за вопросов коллег «а не стоит ли заложиться на будущее?»

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

Автор даёт совет: решение не строить сложную систему — это важное инженерное решение. Его нужно документировать. Вместо «сделал фичу X» пишите: «Оценил три подхода, включая event-driven архитектуру. Определил, что простое решение покрывает все текущие требования. Выкатил за 2 дня, 0 инцидентов за полгода».

Статья целиком: https://terriblesoftware.org/2026/03/03/nobody-gets-promoted-for-simplicity/

@prog_stuff