⚡️Друзья, в последние месяцы все чаще слышу о ситуации, описанной ниже.
Дословный копипаст от моего менти.

Предлагаю не жалеть эмоции и мысли,писать то,что вы реально думаете, пока вы читаете, я спущусь за 🍿

"Работаю аналитиком. В команде появился новый разработчик, из категории программистов, с которыми сложно достичь понимания границ в том, кто что должен делать.

Программист постоянно просит уточнить тз вплоть до обращения к именам объектов по типу "Документ.СписаниеСРасчетногоСчета.РасшифровкаПлатежа.Сумма" вместо "ТЧ Расшифровка, колонка Сумма документа списания с расчётного счета".

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

Пишет функционал ровно в том виде, как он понял, не вникая в контекст.

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

Критикует решения по задаче, не вникая в сквозной пример.

Не выносит функции в программный интерфейс, оставляя одинаковый функционал на форме разных объектов. В ТЗ ведь не написано...

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

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

Возникла мысль, что мне проще инвестировать время в изучение продуктовой разработки, написание кода, стандартов, сборку поставки и разрабатывать самому. Сам себе тз написал, пока писал нашёл концептуальные ошибки, поправил, и пошёл программировать. И не возникает соблазна говнокодить т.к. мне же этот функционал и поддерживать.

Не проще ли стать "универсалом" и приносить больше пользы за зп при совмещение двух должностей?

Какие мысли на этот счёт?"