Наверняка многие из вас обращали внимание, что все талантливые и успешные разработчики чем-то похожи друг на друга. Автор этого поста постарался проанализировать и вывести эти общие черты. Что радует — их вполне можно развить в себе.
Я родом из мира корпоративного программирования. Возможно, это и не самая очаровательная софтверная отрасль (куда уж большим корпорациям до «коробочных стартапов» или крошечных вебдванольных компаний, названия которых ворохом сыплются из браузера, стоит вам неверно набрать доменное имя). Но наша отрасль стабильная, здесь хорошо платят, а также имеется свой набор интересных проблем, о которых и не слыхивали в других сферах программирования.
Например, давно ли приходилось какому-нибудь разработчику последней версии Halo потратить целых три недели, чтобы собрать кучу людей из бухгалтерии, отдела маркетинга, продукт-менеджеров и сотрудников колл-центра, чтобы окончательно разобраться с требованиями, которые все равно изменятся уже через пару месяцев после релиза программы?
А когда кому-нибудь с 37Signals доводилось неделями просиживать спина к спине в ходе JAD-сессий?
В моем мире корпоративного программирования я познакомился с некоторыми феноменальными разработчиками. Я говорю о тех ребятах, выкладывающихся на 5 с плюсом, которым хочется посоветовать бросить эту работу и скорее основать свою собственную компанию. И чем больше я задумывался, отчего же они так хороши, тем яснее замечал у них пару общих черт. Ну, честно говоря, не пару, а где-то четыре.
Пессимизм
Адмирал Джим Стокдейл был самым высокопоставленным американским военачальником, попавшим в плен во Вьетнаме. Его держали в тюрьме «Ханой-Хилтон» и многократно пытали на протяжении 8 лет. Однажды Стокдейл сказал Джиму Коллинзу, автору книги «Good to Great», следующие слова: «Никогда не следует путать веру в то, что в конце концов ты победишь (потерять эту веру смерти подобно) с жесткой дисциплиной, которая помогает сносить самые адские проявления бытия, какими бы они ни были». После освобождения Стокдейл стал первым трехзвездным офицером в истории ВМФ США, носившим одновременно и Крылья авиатора, и Медаль Почета.
Стокдейл был пессимистом в краткосрочной перспективе, так как существовал в нечеловеческих условиях, но в долгосрочной перспективе оставался оптимистом, продолжая верить в то, что выдержит все испытания.
Никто не сможет предвидеть катастрофического отказа системы, обращая внимание лишь на положительные ее аспекты. Лучшие разработчики, которых я знаю, отлично умеют находить места потенциальных отказов. Иногда, если им намекнуть о том, что может понадобиться обработать передачу критически важных данных по FTP, и это по диал-апу среди ночи, они не удержатся и спросят: «А что у нас плохого?». Самые лучшие разработчики предвидят такие проблемы, о которых другие даже не задумываются, и делают все возможное, чтобы избежать таких проблем.
С другой стороны, хорошие разработчики оптимистичны, иногда даже донельзя уверены в собственном окончательном успехе. Они знают, что пессимизм сегодня ведет к успеху завтра.
Нетерпимость к неаккуратному коду
Пол Грэм очень точно подметил эту черту, сказав: «Оказывается, люди, хорошо разбирающиеся в чем-то, не столько убеждены в собственном величии, сколько озадачены некомпетентностью окружающих». Для классного разработчика нет хуже кошмара, чем наблюдать, как чья-то программа бьется в конвульсиях, обрушивая при этом всю остальную систему. Это приводит их в бешенство. И такие проблемы не ограничиваются кодом; дело может быть в плохих установочных пакетах, неаккуратном развертывании либо в ошибочно записанном названии столбца.
Например, от качества продукции NASA напрямую зависит чья-то жизнь и смерть. Поэтому в NASA создаются идеальные программные продукты, производственный процесс построен так, что возможность человеческой ошибки практически сведена к нулю. Уровень за уровнем добавляются новые проверки, оптимально распределяется нагрузка, и эти умения являются результатом долгой практики обучения на собственных ошибках и поиска наилучших способов их устранения. NASA — образцовая организация, в которой действительно умеют находить причину ошибки и корректировать всю работу так, чтобы подобная ошибка никогда более не возникла. И это работает. В следующей статье о процессе разработки программ в NASA читаем:
Примечательно, как работают их программы. Они не валятся. Их не требуется перезагружать. Никаких багов. Это настолько совершенные программы, какие только может создать человеческое существо. Просто статистика: в каждой из последних трех версий программы — каждая длиной по 420 000 строк кода — было найдено всего по одной ошибке. В последних 11 версиях этой программы в сумме обнаружено 17 ошибок. В коммерческих программах сопоставимой сложности встречается примерно по 5000 ошибок».
Я не утверждаю, что любая разработка требует такой высокой планки, но в NASA действительно умеют находить и исправлять ошибки, и делается это одним и тем же способом: отыскивается причина каждой проблемы.
Программист, исправляющий проблему, но не удосуживающийся определить, откуда она проистекает, никогда не станет экспертом в этой сфере. Опыт — это не годы работы, а умение распознавать проблему до того, как она возникла. А для этого в первую очередь необходимо понимать причины проблемы.
Разработчики, не находящие на это времени, часто выдают неаккуратные решения. Сотни подобных перлов вы найдете на этом сайте. Вот некоторые из таких примеров, встречавшиеся в моей практике:
- cборка удаляется с сервера после каждой его перезагрузки. Можно написать специальный скрипт, который бы копировал эту сборку на сервер после перезагрузки, либо выяснить, почему именно удаляется сборка;
- скрипт для операций с изображениями выжирает процессорные ресурсы на протяжении целых минут, тогда как его работа должна занимать менее 10 секунд. Можно запустить этот скрипт в два часа ночи, когда никто этого не заметит, либо потратить время, перелопатить код и найти причину проблемы;
- разделяемый XML-файл блокируется процессом, а когда другие процессы пытаются его открыть, они также аварийно завершаются. Можно сделать достаточное количество копий этого XML-файла — по одной для каждого процесса;
- и т.д., и т.д…
Долговременные планы
Эта черта оставалась для меня загадкой дольше всего, но полагаю, я наконец-то могу сформулировать, в чем ее смысл.
Люди, продумывающие свою жизнь на много лет вперед, обладают даром не менее полно планировать процесс разработки программы. Умение видеть последствия решений, принимаемых сегодня, — ключевой фактор при создании программ, которые будут работать завтра. У самых лучших разработчиков, которых я знаю, хорошо сложилась семейная жизнь, есть накопления на старость, свое жилье. Еще они правильно питаются. Те люди, которые никак не могут наладить свой быт, а также живут от получки до получки, тоже могут быть неплохими программистами, но в офисе им не хватает того же, чего и в жизни: дисциплинированности, а также умения строить долгосрочные планы и строго их придерживаться.
Внимание к деталям
Я знаю очень умных разработчиков, которым не хватает внимания к деталям. У них-то и встречаются орфографические ошибки в названиях столбцов баз данных, код без комментариев, проекты, выполненные без контроля версий, программы, не знавшие модульного тестирования, нереализованные фичи. Все это не представляет проблем, если вы пишете гугловский мэшап или пятистраничный сайт. Но в корпоративной разработке любой из этих недостатков смерти подобен.
Поэтому сейчас сделаю громкое заявление, но обещаю не повторяться:
Никогда, никогда в жизни не встречал выдающихся и при этом небрежных разработчиков.
Еще в колледже работал я с одним программистом, у которого было железное правило: и он, и все его коллеги должны были делать отступ при помощи двух нажатий пробела, а не при помощи табуляции. Если ему давали код с табуляцией, он просматривал его строка за строкой и заменял всю табуляцию на пробелы. Хотя этот пунктик действительно яйца выеденного не стоил (я не раз сам подтрунивал над парнем по этому поводу), такое внимание к мелочам весьма пригодилось ему, когда он не один год занимался разработкой микросхем в Intel.
Итак, мысль понятна
В следующий раз, когда будете собеседовать нового соискателя, проверьте, обладает ли он теми четырьмя чертами, которые я перечислил. Вот о чем бы я его спросил:
- Вы оптимист или пессимист?
- Расскажите о случае, когда вам удалось не только решить техническую проблему, но и найти ее источник.
- Делаете ли вы сбережения? (этот вопрос можно задать, рассказывая о пенсионной программе, действующей у вас на предприятии)
- Предложите короткий фрагмент кода с явными орфографическими ошибками и спросите, видит ли кандидат какие-то неточности.
Из книги «Facts and Fallacies of Software Engineering» известно, что наилучшие программисты работают примерно в 28 раз лучше самых посредственных. Поэтому в софтверной индустрии, как нигде, кадры решают всё.
Роб Уоллинг
Источник
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.