Personality Traits of the Best Software Developers | Rob Walling

Personality Traits of the Best Software Developers

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

I come from the world of corporate software development. It may not be the most glamorous side of software (it's nowhere near as interesting as shrinkwrap startups or those fancy-dancy Web 2.0 companies that show up in your browser every time you mistype a domain name), but it's stable, pays well, and has its own set of challenges that other types of software development know nothing about.

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

For example, when was the last time someone working on the next version of Halo spent three weeks trying to gather people from accounting, marketing, product management, and their call center in order to nail down requirements that would likely change in 2 months once they've delivered the software?

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

Or when was the last time someone at 37Signals sat through back to back weeks of JAD sessions?

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

In this world of corporate development I've known a few phenomenal developers. I'm talking about those A+ people whom you would quit your job for to go start a company. And the more I looked at what makes them so good, the more I realized they all share a handful of personality traits. Well, not exactly a handful, more like four.

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

Pessimistic

Пессимизм

Admiral Jim Stockdale was the highest ranking US military officer imprisoned in Vietnam. He was held in the “Hanoi Hilton” and repeatedly tortured over 8 years. Stockdale told Jim Collins, author of Good to Great, “You must never confuse faith that you will prevail in the end, which you can never afford to lose, with the discipline to confront the most brutal facts of your current reality, whatever they might be.”

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

After his release, Stockdale became the first three-star officer in the history of the navy to wear both aviator wings and the Congressional Medal of Honor.

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

Stockdale was a pessimist in the short-term because he faced the brutal facts of his reality, but was an optimist in the long-term because of his confidence that he would prevail in the end.

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

No one anticipates a catastrophic system failure by looking on the bright side. The best developers I know are experts at finding points of failure. You'll often hear them quipping “What could possibly go wrong?” after someone makes a suggestion to handle a critical data transfer via nightly FTP over a dial-up connection. The best developers anticipate headaches that other developers never think of, and do everything within their power to avoid them.

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

On the flip side, great developers are optimistic, even downright confident, about their overall success. They know that by being a pessimist in the short-term, their long-term success is ensured. Just like Jim Stockdale, they realize that by confronting the brutal facts of their current reality they will prevail in the end.

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

Angered By Sloppy Code

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

Paul Graham nailed it when he said “…people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent.”

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

The worst nightmare for a great developer is to see someone else's software gasping for air while bringing the rest of the system to its knees. It's downright infuriating. And this isn't limited to code; it can be bad installation packages, sloppy deployments, or a misspelled column name.

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

Due to the life and death nature of their products, NASA designs zero-defect software systems using a process that has nearly eliminated the possibility for human error. They've added layer after layer of checks and balances that have resulted from years of finding mistakes and figuring out the best way to eliminate them. NASA is the poster child for discovering the source of a mistake and modifying their process to eliminate the possibility of that mistake ever happening again. And it works. A quote from this Fast Company article on NASA's development process says

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

"What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors."

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

I'm not saying we have to develop to this standard, but NASA knows how to find and fix bugs, and the way they do it is to find the source of every problem.

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

Someone who fixes a problem but doesn't take the time to find out what caused it is doomed to never become an expert in their field. Experience is not years on the job, it's learning to recognize a problem before it occurs, which can only be done by knowing what causes it in the first place.

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

Developers who don't take the time to find the source often create sloppy solutions. For hundreds of examples of sloppy solutions visit The Daily WTF. Here are a few I've seen in my career:

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

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

Long Term Life Planners

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

This one was a little puzzling for the longest time, but I think I've finally put it together.

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

People who think many years down the road in their personal life have the gift to think down the road during development. Being able to see the impacts of present-day decisions is paramount to building great software. The best developers I know have stable family lives, save for retirement, own their own home, and eat an apple a day (ok, maybe not that last one). People who have spastic home-lives and live paycheck to paycheck can certainly be good developers, but what they lack in life they tend to lack in the office: the ability to be disciplined, and to develop and adhere to a long-term plan.

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

Attention to Detail

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

I've known smart developers who don't pay attention to detail. The result is misspelled database columns, uncommented code, projects that aren't checked into source control, software that's not unit tested, unimplemented features, and so on. All of these can be easily dealt with if you're building a Google mash-up or a five page website. But in corporate development each of these screw-ups is a death knell.

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

So I'll say it very loud, but I promise I'll only say it once:

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

I have never, ever, ever seen a great software developer who does not have amazing attention to detail.

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

I worked with a programmer back in school who forced anyone working with him to indent using two spaces instead of tabs. If you gave him code that didn't use two spaces he would go through it line-by-line and replace your tabs with his spaces. While the value of tabs is not even a question, (I've long-chided him for this anal behavior) his attention to such a small detail has served him well in his many years designing chips at Intel.

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

So There You Have It

Итого

The next time you're interviewing a potential developer, determine if she has the four personality traits I've listed above. Here are a few methods I've found useful:

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

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

We know from Facts and Fallacies of Software Engineering that the best programmers are up to 28 times better than the worst programmers, making them the best bargains in software. Take these four traits and go find a bargain (or better yet, make yourself into one).

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

If you liked this article you'll also like my article Timeline and Risk: How to Piss off Your Software Developers.

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

Special thanks to Mike Taber for reading drafts of this article.

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