Предполагаю, что причина объяснять не через систему с подробной записью и временными метками кроется в том, чтоб потом концов не найти о том, как кто-то плохо поставил задачу. И всё это подаётся под соусом экономии времени, прокрастинации и т.д. и т.п.
Даже если задача понята верно и нет вопросов, то я уж лучше подойду и скажу где говнокодец, чтобы не переделывать это после мр, а в процессе, опять же для экономии времени. Но гниение дома и боязнь общества тоже имеет место быть, каждому своё :))
Неумеющий ставить задачи лид везде неэффективен. Сам лид может и не теряет 5 секунд своей жизни. А вот то, что он теряет кучу времени от спецов, тоже факт.
Но это мое мнение, возможно у тебя какой-то супер лид который ставить тебе задачи на фрилансе так что ты без вопросов все делаешь сразу в идеальной реализации 🤷🏻♂️😂
Преформулирую: поставьте эксперимент. Делайте постановку задач исключительно в начале рабочего дня и дублируйте письменно. И разбор результатов выполнения задач и прочего в конце рабочего дня. А в течении рабочего дня вообще не трогайте и не подходите к разработчику. Если подойдёте к специалисту более двух раз и более пяти минут в общем для внесения правок в течении дня сами, или при разборе внесёте более двух правок, которых не было в изначальной задаче - увольняйте постановщика задач (менеджера, лида, СТО или кто там) к чертям.
Вопрос в том что задача может быть ясна, но реализация может отличаться от ожиданий. В команде сидящей вместе есть возможность спросить у опытных коллег как сделать лучше. Чтобы не гуглить или потом не переписывать после ревью. Постановка и метод реализации особо не связаны между собой, если оно не прописано в задаче.
Все одним сообщим компонентом в реакте, проп серединниг вместо контекста или наоборот не уместное использование контекста. Это на примере фронта. Изобретение велосипедов вместо известных паттернов в очевидных местах.