Культурные коды: какие типы программистов бывают и как ими управлять

© Weston Doty

Американский программист Хэнк Рейнуотер работает в профессии более тридцати лет. Когда его повысили до менеджера, ему пришлось искать подход к коллегам и выяснять, как повысить их эффективность. В итоге он так углубился в тему, что написал книгу «Как пасти котов. Наставление для программистов, руководящих другими программистами».Отрывок о самых распространенных типах кодеров и о том, чего от них стоит ждать.

Архитектор

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

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

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

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

Художник

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

Инженер

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

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

Ученый

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

Лихач

Лихачи — это те товарищи, которые делают все быстро. Забывая о комментариях, отступах и соглашениях об именовании переменных, они, тем не менее, умудряются достигать результата очень оперативно — и, что самое замечательное, вплоть до первой неперехваченной ошибки их продукты вполне успешно работают.

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

Как обращаться с представителями разных пород

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

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

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

Есть еще один тип личности, на который следует обращать особое внимание. Я имею в виду программистов-ковбоев. Этот тип плохо согласуется с перечисленными породами, а описывать его лучше в соответствии с тем мнением, которое ковбой о себе формирует. Итак, программист-ковбой обычно в совершенстве владеет своим ремеслом, но при этом управлять им практически невозможно. Ковбои глубоко убеждены, что могут работать только над теми проектами, над которыми хотят, делать это на собственных условиях, согласуясь исключительно с собственными планами и обращаясь только к подходящим по их мнению средствам. Такой программист — своеобразный волк-одиночка (или, если придерживаться терминологии этой книги, — кот, который гуляет сам по себе). В зависимости от того, что вам нужно, и вашей готовности терпеть своеобразие их личности, ковбои могут творить либо чудеса, либо хлам. С ковбоями надо держать ухо востро: они ни при каких обстоятельствах не станут частью вашей команды. Прибегать к их услугам стоит либо в безвыходных ситуациях, либо если разрабатываемый проект должен радикально отличаться от всех других, а сопровождать его будут сторонние специалисты.

Почему в программистах сочетаются все эти чрезвычайно занимательные личностные характеристики? Мне кажется, связано это с тем, что сам характер деятельности разработчика программного обеспечения привлекает людей совершенно определенного рода. В своем классическом труде «The Mythical Man-Mouth» Фредерик Брукс (Frederick Brooks) утверждает, что наше ремесло приносит людям удовольствие пяти видов:

— Радость созидания.

— Радость созидания полезных для других людей продуктов.

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

— Радость от постоянного обретения новых знаний и решения нестандартных задач.

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

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

Источник: theoryandpractice.ru