Заметки и ссылки на будущее, чтобы изучить когда будет время.
Разместить рекламу: @tproger_sales_bot
Правила общения: https://tprg.ru/rules
Другие каналы: @tproger_channels
Другие наши проекты: https://tprg.ru/med
Post #2775
839
Никого не повышают за простоту
Инженер 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
Инженер 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
- 💯 11
- ❤ 2
