Хотелось бы добавить комментарий к 5-ому пункту: «Попытка решить задачу в точности, как ее описал заказчик».

Тут еще может быть проблема несколько в другом. Не только в сроках. Есть люди, которые стараются сделать именно так, как написано в ТЗ, даже если в конкретном случае это может противоречить здравому смыслу. Не всегда изменения хорошо ложатся в архитектуру проекта. И в итоге проект обрастает «костылями», «обходными решениями» и т.д. Но разработчик старается выполнить ТЗ от первой буквы до последней.

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

Как подчеркнул автор, эти проблемы привносятся программистом «извне». Однако я чаще был свидетелем проблем, которые живут именно «внутри» задачи:

• несколько равноценных решений (тут программист может крепко подвиснуть, выбирая из «шила» и «мыла», пытаясь спрогнозировать будущее развитие программы, пытаясь найти какое-то решающее преимущество или недостаток одного из решений) — здесь можно лишь посоветовать быть решительнее и ... полагаться на интуицию;
• жгучее желание произвести рефакторинг (решение каждой следующей задачи будет понемногу менять программу в целом, и будет вызывать желание переписать весь предыдущий код, чтобы он соответствовал новому) — тут надо сдерживать свой перфекционизм и не трогать код, который вы сами оцените на 4 и больше условных баллов;
• конфликт между решаемой задачей и уже решенными задачами (вполне в порядке вещей, когда программисту приходится решать взаимоисключающие задачи — сначала клиент попросил так, потом вот этак, а потом еще и вон что) — тут надо просто очень внимательно задокументировать ход решения этих задач — в будущем сильно поможет.

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

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

Отсутствие архитектуры приложения приводит к недопониманию системы у программистов, вследствие чего правки начинают вноситься именно в том месте, где «показал» заказчик, без анализа их возможного влияния на другие подсистемы проекта. Упомянутые автором правки методом тыка тоже позволяют ускорить добавление функционала/исправление видимых ошибок. Негативной особенностью этих способов ускорения процесса разработки является прогрессирующая неспособность разработчиков находить возникающие ошибки во время тестирования, и фактически тестированием начинает заниматься заказчик на реально функционирующей, «живой» системе. Имеет место «исправление ошибок по факту», когда любая ошибка в системе правится лишь по запросу со стороны заказчика. Не потому, что разработчики низкоквалифицированы или хотят сэкономить на тестировании, а потому, что обнаружение ошибок в сложной, запутанной системе, не имеющей архитектуры, практически невозможно.

Вторая причина упомянутых автором проблем — в недостаточном взаимодействии программиста с конечным заказчиком, что может быть обусловлено множеством факторов. Начиная от минимальных сроков на задачу, когда проще сделать «точно как написано в ТЗ», а потом в случае необходимости подправить, чем тратить несколько дней на выяснение от заказчика точных требований, расходуя бюджет проекта фактически впустую (вряд ли заказчик согласится оплатить несколько дней обсуждения функционала, если реализация конечного решения будет занимать от силы несколько часов). И заканчивая иногда довольно большим количеством промежуточных звеньев в цепочке заказчик-программист (особенно характерным для применяемой большими компаниями модели водопада), при котором часть требований заказчика теряется в процессе передачи информации от него к аналитику, проектировщику, менеджеру проекта, дизайнеру интерфейсов и др. и в конечном счёте программисту. В небольших компаниях большинство ролей выполняется одним-двумя сотрудниками, что улучшает обратную связь с клиентом. Однако в этом случае на «программистов» ложится множество обязанностей, не связанных непосредственно с разработкой ПО и лежащих совсем в другой области знаний. Например, программисту бывает проще сократить стоимость проекта под давлением заказчика, чем тратить нервы и время на психологическую борьбу с ним, что в итоге негативно отражается на финансовом состоянии компании и её развитии.

Третья причина — недостаточное взаимодействие программистов внутри команды. Простейший пример здесь — упомянутая автором ситуация «личной драмы». Часто приходится наблюдать ситуации (и не менее часто участвовать в них), когда программист несколько часов или даже дней бьётся над решением какой-то задачи и, когда практически сдаётся, подзывает на помощь кого-то, кто находит решение за полчаса-час, причём большая часть этого времени тратится на объяснение отчаявшимся программистом задачи помощнику. Более того, по личным наблюдениям, данной проблеме больше подвержены более квалифицированные сотрудники, а квалификация помощника роли не играет. Здесь становится важен сам эффект «свежего взгляда». С другой стороны, в век существования ресурсов, подобных habrahabr.ru, stackoverflow.com и других, не стоит из-за каждого пустяка беспокоить коллег, так как лучше запоминается то, что изучено или найдено самостоятельно и на что потрачено некоторое время, чем то, что подсказано другими.

Другим проявлением недостаточного взаимодействия членов команды является отсутствие контроля за новичками со стороны более опытных специалистов. Более опытный коллега, с одной стороны, не позволит новичку выполнить задачу «в режиме ЕГЭ». С другой стороны, глаз работающего в одной области человека замыливается, и возможность видеть, как при решении уже известных ему проблем поступают новички, может позволить взглянуть на эти проблемы с другой стороны и расширить или упростить свой арсенал методов для их решения. Кроме того, делать «по аналогии» всегда проще, чем искать правильное решение самому; одно дело иметь корпоративную wiki с описанием процессов типа особенностей использования IDE в компании, стиля кода, стиля комментариев к коммитам в системе контроля версий и др. и заставлять новичков изучать эту документацию. И совсем другое — позволить новичку в режиме парного программирования увидеть какие навыки применяет и как работает более опытный коллега при решении задач.

И последняя причина, не являющаяся, по большому счёту, виной программиста, — отсутствие его мотивации, вызванное работой в неподходящих условиях. Например, это постоянное переделывание (или незначительные изменения) одного и того же функционала заказчиком или регулярный переброс программистов между проектами. Даже если клиент оплачивает каждое изменение и компания в целом находится в плюсе, у программиста создаётся ощущение, что как хорошо ни делай, а через две недели всё равно придётся всё переделывать.

Последняя ситуация также существенно замедляет развитие сотрудников: вместо того, чтобы совершать ошибки и потом учиться на них, анализируя причины и последствия самостоятельно принятых при реализации той или иной задачи решений, программисты вынуждены постоянно исправлять ошибки других, и не видя последствий собственных решений и продолжают совершать всё те же ошибки.
В целом же, мне кажется, «нам мешает жить и работать» тот факт, что разработка ПО — ещё достаточно молодая область, и все советы на тему того, что и как нужно делать, являются, скорее, рекомендациями, чем общепризнанными формальными стандартами. Невозможно изучить «Правила разработки ПО», сдать на права категории «Веб-разработчик» и после этого делать всё правильно. Большинство программистов развивается в профессиональном плане методом проб и ошибок, вплоть до того, что у разных компаний, занимающихся разработкой ПО в одной области, стандарты процесса разработки и требования к результату могут существенно различаться.

Поэтому одной из основных задач компании является не просто позволить сотрудникам расти в профессиональном плане, реализуя приходящие от заказчиков требования и обмениваясь опытом с коллегами, но и позволить им экспериментировать (в разумных пределах, конечно) при реализации функционала в поисках более эффективных и интересных решений. Это, с одной стороны, позволит программистам почувствовать себя чем-то бОльшим, чем механическим переводчиком с клиентского языка на компьютерный, а с другой стороны, возможно, позволит компании стандартизировать и оптимизировать у себя часть решений и внутренних процессов, дав ей конкурентное преимущество как среди заказчиков, так и среди ищущих работу программистов.

В этой статье замечательно всё, кроме заголовка и вывода. Да, такие проблемы действительно иногда имеют место. Однако, с одной стороны — это не всегда проблемы программиста. По крайней мере, не того программиста, который непосредственно решает задачу. Например, проблемы по пунктам 3, 4 и некоторые другие — это дефекты постановки задачи и контроля выполнения. Программист не виноват, если ведущий программист не в состоянии чётко определить входные/выходные данные для задачи или корректно описать архитектурные и алгоритмические требования.

С другой стороны, все субъективные излишества, которые вносит программист в решение задачи, неизбежны. Как правильно заметил автор, задача не существует сама по себе, всегда есть ещё «что-то». И обязательно в этом «чем-то» есть личность программиста, которая неизбежно привносит какие-то субъективные моменты в решение задачи. Но дело в том, что программист просто не в состоянии обнаружить эти привнесения. Как логическая система сама по себе не в состоянии доказать свою непротиворечивость (вторая теорема Гёделя о неполноте), так и человек никогда не может быть полностью уверенным в том, что он всё делает корректно. И это опять возвращает нас к уже озвученной мысли: необходима чёткая формулировка задачи и контроль выполнения.