Какой бред...
Ощущение что писал либо начинающий школьник, который совсем не понимает о чем пишет, либо туповатый погромист, который все делает "на отвяжись".
Для тех кто не знает, оно может и сойдет, а для специалиста такое слышать, что кнопка чет там ломает, и непонятно почему и как - это серпом по причиндалам.
По факту:
- Любой код можно и нужно коментить, это раз.
- Два. "верстка" уплывает, действительно, но это только у школоты, которые не знают ни про резиновые окна, ни про блоки, ни про разделение, ага.
- Три. "Дизайнер ещё не нарисовал кнопочку, потому погромист сидит и ничего не делает" - это вобще лютая дичь. За такое надо сразу руки отрывать и в музей бездарности отправлять.

Что вижу я, даже при ооочень малом опыте разработки:
- Криворукий погромист написал сайтик или приложуху, жестко привязав КАЖДЫЙ объект на КАЖДОЙ странице, к самой странице. Вместо того чтоб пользовать единую таблицу стилей, криворук этим самые кнопоцки-окошечки, создавал собственные, на каждую страницу, в итоге у криворука поплыло все и сразу, потому что - а че б нет? )

Нормальный погромист создаст таблицу стилей, в которой пропишет и кнопоцки, и окошечки, и шапочки, и всякие другие прелести, и будет её вызывать, наслаждаясь тишиной и покоем, а тчоб верстка не плыла, сделает окошечки резиновые, и теперь для того чтоб добавить кнопоцку "скачать" у него уйдет всего 10 минут, из которых он 8 будет читать КОММЕНТАРИИ - чё кудой тыкать, и 2 - клацнуть в нужном месте 10 строк.
Ну да, приврал, там надо ещё и добавить всякие всякости, чтоб оно работало, и скачивало,так что нет - не 10, а поболе, но тут не скажу сколько и чего, ибо нет четкого ТЗ).

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

А если это чужой код, то идем в пункт 3, ищем криворука создавшего эту прелесть, отрываем, ну и далее по тексту.
Всем бобра, и не будьте криворуками!

Наверное, каждый разработчик хотя бы раз слышал эту фразу.

— Да там же небольшое изменение.
— Это буквально на пять минут.
— Просто кнопку добавить.

И почти всегда после этих слов начинается история, которая заканчивается совсем не через пять минут.

"Всего лишь кнопку"

Однажды приходит задача.

Нужно добавить кнопку "Скачать".

Звучит действительно просто. Разработчик открывает проект. Оказывается, дизайн для новой кнопки не готов. Пишет дизайнеру.

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

Исправили.

Теперь оказывается, что скачивать нечего — API не отдаёт нужный файл. Добавили новый метод.

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

После этого QA находит проблему. Если пользователь открывает страницу из закладок, кнопка исчезает.

Исправили.

Затем деплой и уже в продакшене оказывается, что в Safari всё работает иначе.

И конечно же кнопка появилась, но прошёл ДЕНЬ, хотя сама кнопка действительно писалась минут пять.

Код редко занимает большую часть времени

Есть интересное наблюдение.

Когда люди говорят:

"Сделать задачу"

Они представляют именно написание кода. Хотя на практике код — это зачастую лишь небольшая часть всей работы.

Остальное время уходит на:

• понимание задачи;

• поиск нужного места в проекте;

• анализ существующей логики;

• обсуждения;

• изменения API;

• тестирование;

• исправление найденных ошибок;

• код-ревью;

• деплой;

• проверку в продакшене.

Иногда написание самого решения занимает всего 10–20% времени.

Чем старше проект, тем меньше в нём "пятиминутных" задач

На новом проекте действительно можно быстро что-то добавить.

Но когда системе несколько лет...

...любое изменение начинает цеплять другие части.

Добавили одно поле и сломались отчёты.

Исправили отчёты и перестали проходить интеграционные тесты.

Исправили тесты.

Поменялась сериализация и упал мобильный клиент.

Каждый опытный разработчик знает эффект:

маленьких изменений почти не бывает.

Почему разработчики так не любят фразу "на пять минут"

Не потому что ленятся.

А потому что знают, что оценивается только видимая часть задачи.

Никто заранее не видит:

• старые зависимости;

• забытый код десятилетней давности;

• неожиданное поведение;

• сторонние сервисы;

• особенности браузеров;

• ограничения архитектуры.

Это как попросить строителя:

"Да просто стену передвинь."

Пока не начнёшь двигать — не узнаешь, что она несущая.

Как лучше ставить задачи

Вместо:

Это на пять минут.

Лучше сказать:

Посмотри, пожалуйста, насколько это действительно сложно.

Кажется мелочью, но психологически это совершенно другой разговор.

Разработчик перестаёт оправдываться и начинает искать решение.

Самое интересное

За годы работы я заметил одну закономерность.

Когда руководитель начинает использовать выражение:

"Ну это же быстро..."

почти всегда именно эта задача неожиданно становится самой дорогой в спринте.

И не потому что кто-то плохо работает. А потому что сложность разработки редко находится в самом коде.

Она скрывается вокруг него.

Код пишется быстро. Долго приходится разбираться со всем, что этот код затрагивает.

Если вам интересны темы управления разработкой, предсказуемости спринтов и инженерных процессов — иногда пишу об этом здесь. Ещё больше материалов собираю на sprint-intelligence.ru