Фича против функционала. Кто кого?

Предпочтения у каждого свои.

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

Задача была простая — расширение одного из сервисов. Рядом лежала другая, побольше — её отменили. Тикета не стало, а требований вместе с ним. Но функционал вписывался в проект и давал экономию ресурсов. Озвучил куратору общее видение решения — какой функционал добавлю и зачем — и получил одобрение.

Рамки остались только там, где касалось остальной системы — общий контракт, направление. Как это будет устроено внутри, какие компромиссы принять и какие ошибки допустить — уже было пространством для решений.

Один из компромиссов увидел уже на самопроверке кода — часть решения оставляла технический долг. По-хорошему, стоило переделать сразу. Но на ревью решили иначе: функционал вводим сейчас, долг чиним отдельной задачей позже.

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

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

Были ошибки? Да. Проблема ли это? Нет.

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

#go #backend #разработка #автономия #softskills