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

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

Значимая часть SD начинается с выявления требований, процесса исследования и выявления требований, на основе которых строится часть программного обеспечения. Результаты процесса программирования так же хороши, как и предоставленные входные данные — уровень детализации, точности и полноты, с которыми были определены требования. Это известный принцип GIGO (мусор на входе, мусор на выходе). Даже если он подвергает сомнению некоторые требования, например, когда они противоречивы или неполны, каждый вопрос увеличивает задержки в процессе, потому что прояснение открытых вопросов часто требует нескольких итераций. Таким образом, нужно выбирать между своевременностью и обеспечением ожидаемого качества. Еще одна проблема заключается в том, что отдача и восприятие этих двух вещей различны с точки зрения менеджеров и клиентов.

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

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

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

В конце концов, различные неправильные представления о программистах имеют влияние только в той степени, в какой они могут проникнуть в сообщество или культуру организации. Суть в том, как сформулировал это Бьерн Страуструп, что «организация, которая относится к своим программистам как к дебилам, вскоре будет иметь программистов, которые хотят и могут вести себя только как дебилы» [1].

См. также:
Заблуждения о программировании — Часть «I» и «II»

Ссылки:
[1] Язык программирования C++, 2-е изд., Бьярн Страуструп, 1991 г.

® Первоначально опубликовано на «sql-troules»

600 слов: темная сторона программирования