Породы программистов(часть 1).

Недавно была опубликована интересная заметка, которая заставила меня вспомнить о книге "Herding Cats. A primer of programmers who lead programmers" by J. Hank Rainwater. В ней, по-моему мнению, очень точно описаны типичные породы программистов :

Основные:

• архитектор;
• конструктивист;
• художник;
• инженер;
• ученый;
• лихач.

Редкие:

• волшебник;
• минималист;
• аналогист;
• трюкач;
• разгильдяй;
• тормоз;
• любитель;
• профан;
• эклектик.

Архитектор*

Большинство руководителей обожают этот тип программистов - и, действительно, любой такой деятель окажется ценным приобретением для вашей команды. В основном архитекторы концентрируются на общей структуре кода. Они мыслят объектами, а их лучший друг - лист белой бумаги. Посвящая себя без остатка решению бизнес-задач, они строят абстракции, проводят анализ систем, после чего переходят к кодированию конкретных решений. Слов нет - все это очень важные элементы программирования, но для комплексного выполнения задач их еще не достаточно. Зачастую в высшей степени разумные замыслы архитектора воплощаются в настолько общем и непонятном коде, что людей, могущих разобраться в нем и продолжить начинание, просто не находится. Особи, способные генерировать удачную идею в глове (а лучше в Visio), а затем выполнить ее полноценную конкретизацию в коде, становясь, таким образом, единственными участниками процесса, встречаются очень редко. Недостаток архитекторов в том, что их код часто служит только одному хозяину, а исполнять чужие команды категорическо отказывается. Некторые архитекторы очень любят набросать структуру кода, с тем чтобы впоследствии передать его на растерзание программистам более "низкой" квалификации. Иногда в коде, написанном архитекторами, встречаются весьма странные конструкции - например, окна с сообщениями о системных прерываниях из-за ошибок, появляющихся по той лишь причине, что код предполагалось исполнять в виде библиотеки DLL на сервере.

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

Конструктивист

Конструктивисты получают удовольствие от процесса написания кода и его результата. Стратегическим планированием они себя утруждают не всегда, но факт в том, что с написанием кода они справляются быстро, причем в большинстве случаев ошибок в нем не обнаруживается даже на этапе альфа-тестирования. Код конструктивисты пишут по наитию, а потому их логика не всегда понятна. У некторых конструктивистом все в порядке и с интуицией, и со стратегическим планированием, поэтому код выступает естественным продолжением хода их мыслей. Но стоит попросить конструктивиста составить документацию, он обязательно ответит, что код самодокументируемый. В прочем, если на него немного надавить и дать понять, что без документации никуда не деться, он, вероятно, согласится ее составить - и сделает это качественно. Кто спорит - код должен быть самодокументриуемым, но следует иметь в виду, что основное внимание программисты этого типа уделяют процессу создания кода, поэтому остальное для них не так уж важно. Количеству сборок, которое конструктивист выдает за день, позавидует даже Microsoft. Соответственно, их код обычно отличается надежностью. Однако же по мере разбухания (а этот процесс неизбежен) надежность улетучивается, а конструктивист начинает судорожно искать новые, "заплаточные" решения - ведь для него важно видеть результат и пребывать в уверенности в том, что он справился с поставленной задачей. Констуркивист в сочетании с архитектором имеет все шансы стать прекрасной командой. Если же вы умудритесь отыскать конструктивиста и архитектора в одном лице, считайте, что львиная доля кадровых проблем решена.

Художник

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

Инженер

Инженеры вам понравятся. Эти ребята имеют обыкновение скупать все возможные средства сторонних производителей, писать десятки COM-объектов и сводить их воедино, так что они прекрасно работают в версии 1. Присущая им тяга к усложнению провляется лишь тогда, когда речь заходит о версии 1.1. Программирование часто приравнивают к инжененрии программных средств - и, действительно, многие стороны нашей профессии подчиняются этой методологии. Но давать инженерам карт-бланш нельзя. В программных продуктах, выстроенных инженерными методами, нет ничего предрассудительного - в конце концов, согласно классическому определению, инженерия есть научные принципы, задействованные при решении программных задач. Нам нужны программисты, которые не боятся сложностей, но те из них, которые любят усложнять все и вся, представляют серьезную опасность. Поймите меня правильно: я совершенно не собираюся бросать камень в огород инженеров. В конце концов, я сам многие годы трудился над аппаратным обеспечением компьютеров. Но аппаратная направленность иногда входит в противоречие с теми аспектами программного обеспечения, благодаря которым оно становится программируемым (то есть гибким и многократным используемым). Любое аппаратное устройство обычно служит одной, четко определенной цели, а для программного обеспечения такой подход неприемлим.

Ученый

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

Лихач

Лихачи - это те товарищи, которые делают все быстро. Забывая о комментариях, отступах и соглашениях об именовании, они, тем не менее, умудряются достигать результата очень оперативно - и, что самое замечательное, вплоть до первой неперехваченной ошибки их продукты вполне успешно работают. Иногда такое поведение характерно для молодых программистов, горящих желанием впечатлить вас, - они опрометчиво считают, что оперативность в достижении результата в полной мере соответствует вашим ожиданиям Признайтесь: мы часто сами выстраиваем у них столь ложное представление, а значит, веди мы себя по-другому, никаких лихачей бы не было. Наши собственные начальники устраивают совещания, на которых устанавливают контрольные сроки, а потом сообщают их нам. Как мы добьемся выполнения поставленных задач  - это уже наша проблема. Вспомните, как часто идут разговоры о бессмысленности установления крайних сроков кодирования до окончательного выяснения всех требований! Так вот, вам придется к этому привыкнуть.

Описание редких пород читайте в последующих записях блога.