Что отличает хорошего кодера от хорошего software engineer?

Question

Accepted Answer

**Хороший кодер пишет работающий код**. **Хороший software engineer решает правильную задачу комплексно** — владея требованиями, дизайном, компромиссами, поддерживаемостью, тестированием, операциями и бизнес-контекстом кода. Engineering — это код плюс суждение плюс ответственность на всём протяжении жизненного цикла.

## Где проходит линия

Написать код, который проходит тесты — это лёгкая, обучаемая часть. Более сложная и более ценная часть — это всё вокруг: решить, *что* строить, *как* это должно вписаться в систему, и *какую цену* придётся платить позже.

- **Кодер спрашивает** «Как мне это сделать?» и останавливается, когда это работает.
- **Engineer спрашивает** «Какую проблему мы на самом деле решаем, какие ограничения есть, и какой самый дешёвый дизайн выживет при изменениях?»

## За что отвечает engineer помимо кода

- **Требования** — уточняет реальную потребность, подвергает сомнению спецификацию, выявляет граничные случаи до того, как они становятся инцидентами.
- **Компромиссы** — взвешивает скорость против простоты, собственное решение против готового, сейчас против потом, и делает выбор *явным*.
- **Дизайн и поддерживаемость** — пишет для следующего читателя, минимизирует зону поражения, избегает случайной сложности.
- **Тестирование и операции** — думает о сценариях сбоев, наблюдаемости, откате и том, что произойдёт в 3 часа ночи.
- **Коммуникация** — объясняет решения, документирует их и берёт других с собой.
- **Бизнес-контекст** — связывает работу с результатами, а не просто с закрытыми тикетами.

## Полезный нюанс

Это **не** вопрос опыта или должности — много «инженеров» пишут код, и некоторые «кодеры» инженерят. Это **менталитет**: брать на себя ответственность за результат, а не только за выходные данные. Переход от *«мой код работает»* к *«эта система служит своей цели надёжно и не наказывает того, кто дальше её трогать будет»*.

## Почему это важно

Интервьюеры и команды ценят engineer выше кодера, потому что **баги, outage и неподдерживаемые системы редко возникают из кода, который не компилируется — они возникают из недостатка суждения**: неоставленный вопрос, проигнорированный компромисс, непроверенный граничный случай. Демонстрация того, что вы думаете о всём жизненном цикле — и можете объяснить, *почему* вы выбрали один путь вместо другого — это то, что показывает, что вам можно доверить реальные системы и реальные последствия, что именно то, вокруг чего развивается карьера в этой области.