Решать проблемы пользователей или задачки

Какое-то время мне казалось, что хороший разработчик - это тот, кто хорошо пишет код. Знает технологии. Понимает паттерны. Выбирает правильные фреймворки. Делает “красивые” решения.

И в целом это правда. Но только частично.

Со временем стало заметно, что код - это далеко не вся работа. И иногда даже не самая важная её часть.

Очень легко влюбиться в технологию. Новый стейт-менеджер. Модный подход. Свежий инструмент.

И дальше мысль идёт не от проблемы, а наоборот: “Так, а где бы это применить?”

Решение уже есть. А проблема ещё толком не понята.

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

Они начинают не с кода. А с вопроса: “Какую проблему мы вообще решаем для пользователя?”

И выглядит это не вдохновляюще. А довольно скучно.

чтение тикетов

уточнение требований

разговоры с поддержкой

вопросы “а зачем это вообще нужно?”

попытки докопаться до первопричины

Без архитектурных схем. Без красивых абстракций. Без ощущения, что ты сейчас делаешь что-то большое.

Но почти каждый раз, когда удаётся действительно понять проблему, происходит странная вещь.

Решение оказывается проще, чем ожидалось.

А вот когда мы слишком рано бросаемся писать код, появляется другой соблазн.

Оправдать своё решение. Добавить ещё слой. Ещё абстракцию. Ещё фичу “на будущее”.

Так и рождается сложность без необходимости.

Со временем до меня дошла простая мысль: код - это всего лишь инструмент.

Ценность появляется не тогда, когда решение элегантное. А тогда, когда оно реально помогает пользователю.

И чем раньше в задаче появляется живой пользователь, а не абстрактное ТЗ, тем меньше лишнего кода мы в итоге пишем.

А вы ловили себя на том, что сначала выбираете решение, а уже потом начинаете искать под него проблему?

Решать проблемы пользователей или задачки | Сетка — социальная сеть от hh.ru