Personality Traits of the Best Software Developers | Rob Walling

Черты характера лучших разработчиков

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

Например, когда в последний раз кто-то из разработчиков очередной версии Halo тратил три недели на то, чтобы собрать людей из бухгалтерии, маркетинга, продуктового отдела и колл-центра ради согласования требований, которые, скорее всего, изменятся через два месяца после сдачи софта?

Или когда кто-то в 37Signals в последний раз высиживал неделю за неделей на JAD-сессиях?

В этом мире корпоративной разработки я знал несколько феноменальных разработчиков. Я говорю о тех людях уровня A+, ради которых вы бы уволились с работы, чтобы вместе основать компанию. И чем больше я анализировал, что делает их такими хорошими, тем отчётливее видел, что все они разделяют несколько общих черт характера. Ну, не совсем несколько — скорее четыре.

Пессимизм

Адмирал Джим Стокдейл был самым высокопоставленным офицером вооружённых сил США, попавшим в плен во Вьетнаме. Его содержали в «Ханойском Хилтоне» и неоднократно подвергали пыткам на протяжении 8 лет. Стокдейл сказал Джиму Коллинзу, автору книги «От хорошего к великому»: «Нельзя путать веру в то, что ты в конечном счёте победишь — а терять её нельзя ни в коем случае, — с дисциплиной, заставляющей смотреть в лицо самым жестоким фактам текущей реальности, какими бы они ни были».

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

Стокдейл был пессимистом в краткосрочной перспективе, потому что смотрел в лицо суровым фактам реальности, но оптимистом в долгосрочной — потому что был уверен, что в итоге победит.

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

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

Раздражение от небрежного кода

Paul Graham попал в точку, когда сказал: «…люди, которые отлично делают своё дело, не столько убеждены в собственном величии, сколько озадачены тем, почему все остальные кажутся такими некомпетентными».

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

Из-за критической важности своих продуктов NASA проектирует системы с нулевым допуском дефектов, используя процесс, который практически исключил возможность человеческой ошибки. Они добавляли слой за слоем проверок и балансов, выработанных годами поиска ошибок и нахождения лучших способов их устранения. NASA — образцовый пример того, как находить источник ошибки и модифицировать процесс так, чтобы исключить возможность её повторения. И это работает. Цитата из статьи Fast Company о процессе разработки в NASA гласит:

«Поразительно то, как хорошо работает это ПО. Оно никогда не падает. Его никогда не нужно перезагружать. Это ПО без багов. Оно совершенно — настолько совершенно, насколько могут достичь люди. Вот статистика: в последних трёх версиях программы — каждая длиной 420 000 строк — была обнаружена всего одна ошибка на версию. В последних 11 версиях этого ПО было в сумме 17 ошибок. Коммерческие программы аналогичной сложности содержали бы 5 000 ошибок».

Я не говорю, что мы обязаны разрабатывать по таким стандартам, но NASA знает, как находить и исправлять баги, и делает это, докапываясь до первопричины каждой проблемы.

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

Разработчики, которые не утруждаются поиском первопричины, часто создают небрежные решения. Сотни примеров таких решений можно найти на The Daily WTF. Вот несколько случаев из моей практики:

Сборка удаляется с сервера при каждой перезагрузке. Можно написать скрипт, который повторно копирует сборку на сервер после каждого ребута, а можно выяснить, почему она вообще удаляется.Скрипт обработки изображений пожирает процессорное время минутами, хотя должен выполняться менее чем за 10 секунд. Можно запускать его в 2 часа ночи, когда никто не заметит, а можно потратить время, пройти код пошагово и найти реальную проблему.Общий XML-файл блокируется процессом, из-за чего другие процессы падают при попытке его открыть. Можно сделать несколько копий XML-файла для каждого процесса, а можно разобраться в коде доступа к файлу и выяснить, почему он блокируется.И так далее…

Долгосрочное планирование жизни

Эта черта долгое время вызывала у меня недоумение, но, кажется, я наконец разобрался.

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

Внимание к деталям

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

Поэтому скажу очень громко, но обещаю — только один раз:

Я никогда, ни разу не встречал отличного разработчика, у которого не было бы потрясающего внимания к деталям.

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

Итого

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

Спросите, оптимист он или пессимистПопросите рассказать о случае, когда он нашёл первопричину проблемыУзнайте, откладывает ли он на пенсию (это можно ненавязчиво выяснить при обсуждении пенсионной программы вашей компании)Допустите очевидную опечатку в коротком примере кода и спросите, видит ли он что-то не так

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

Если вам понравилась эта статья, вам также понравится моя статья «Сроки и риски: как довести разработчиков до белого каления».

Отдельная благодарность Mike Taber за вычитку черновиков этой статьи.