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

Ладно, это слишком серьезное обобщение, а из правил существует множество исключений. Многие программисты успешно работают с людьми и им нравится это занятие. Однако в среднем по группам тенденция именно такова, как я изложил. Нас, программистов, радует умеренная сенсорная недостаточность и глубокое погружение в работу – своего рода «кокон».

В 1970-е и 1980-е годы, во время работы в Teradyne, я хорошо освоил процесс отладки. Мне нравилось это занятие, я бросался на сложные задачи с пылом и энтузиазмом. Ни одна ошибка не могла долго прятаться от меня!

Устраняя очередную ошибку, я чувствовал себя победителем! Я отправлялся к своему боссу Кен Файндеру и с энтузиазмом рассказывал, какая интересная мне попалась ошибка. Но однажды Кен в отчаянии воскликнул: «Ошибки не интересны. Их просто нужно исправлять!»

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

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

Худшее, что может сделать профессиональный программист, – в блаженном неведении укрыться в технологическом убежище, когда бизнес горит и рушится вокруг него. Ваша работа – удерживать бизнес на плаву!

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

Короче говоря, профессиональный программист обращает внимание на корабль, на котором он плывет.

За всю мою карьеру меня уволили с должности программиста всего один раз. Это произошло в 1976 году, когда я работал на Outboard Marine Corp. Я помогал писать систему автоматизации производства, которая использовала компьютеры IBM System/7 для контроля за десятками автоматов алюминиевого литья в главном цехе предприятия.

С технической точки зрения это была интересная и сложная работа. Архитектура System/7 приводила меня в восторг, а система автоматизации производства тоже была весьма захватывающей.

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

Все было замечательно. Проблема была во мне. Я с энтузиазмом относился к проекту и технологии, но в возрасте 24 лет я не мог заставить себя думать о бизнесе или внутренней политической структуре.

Первую ошибку я совершил в первый же день. Я пришел на работу без галстука. Я надел галстук на собеседование, и я видел, что все носят галстуки, но не сделал выводов. Итак, в первый день Ральф подошел ко мне и просто сказал: «Мы здесь носим галстуки».

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

Я просто не мог приходить на работу вовремя. И мне казалось, что это не важно. В конце концов, я «хорошо справлялся». И это было правдой: я действительно очень хорошо справлялся с написанием своих программ. Бесспорно, я был лучшим программистом в группе. Я мог писать код быстрее и лучше других. Я быстрее находил и устранял проблемы. Я знал, что я был ценным специалистом, так что время и даты для меня значили мало.

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

Система находилась в стадии активной разработки. До реальной эксплуатации было еще далеко. Не было причин оставлять систему в рабочем состоянии, когда в лаборатории никого не было. Я последним уходил с работы в пятницу, и, видимо, я оставил систему в неработоспособном состоянии. Тот факт, что понедельник был важной датой, просто не отложился у меня в памяти.

В понедельник я пришел на час позже и увидел, как все мрачно собрались вокруг нерабочей системы. Джон спросил: «Почему система не работает сегодня, Боб?» Я ответил: «Не знаю», и сел за отладку. Я даже тогда не вспомнил о демо-версии, запланированной на понедельник, но по поведению моих коллег было совершенно ясно, что произошло что-то нехорошее. Тогда Джон подошел ко мне, прошептал на ухо: «А если бы пришел Стенберг?» и отошел в негодовании.

Стенберг был вице-президентом по автоматизации. Сегодня его должность назвали бы «руководителем технической службы». Вопрос показался мне бессмысленным. «Ну и что? – подумал я. – Система же не в эксплуатации, так в чем проблема?»

В этот день я получил первое предупредительное письмо. В нем мне предлагалось немедленно изменить свое отношение к работе, иначе «последует немедленное увольнение». Я был в ужасе!

Мне пришлось проанализировать свое поведение и понять, что же я делал не так. Я поговорил с Джоном и Ральфом с твердым намерением изменить себя и свой стиль работы.

И я это сделал! Я перестал опаздывать, начал обращать внимание на внутреннюю политику. Я начал понимать, почему Джон беспокоился по поводу Стенберга. Я понял, как подвел его, оставив на понедельник неработоспособную систему.

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

Еще через несколько недель мне сообщили об увольнении.

Мне пришлось идти домой к своей беременной 22-летней жене и рассказывать, что я потерял работу. Мне бы не хотелось, чтобы такое когда-нибудь повторилось в моей жизни.

У программистов часто возникают трудности при работе в тесном контакте с другими программистами. Порой это создает серьезные проблемы.

Один из худших признаков неправильно функционирующей команды – когда каждый программист возводит стену вокруг своего кода и запрещает другим программистам прикасаться к нему. Я был в местах, где программисты даже запрещали другим смотреть на свой код. Это верный путь к катастрофе.

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

Каждый программист работал над своей системой. Один писал код для системы подачи листов, другой – код для системы сшивания и т. д.

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

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

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

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

Многие программисты не любят идею парного программирования. Мне это кажется странным, потому что в напряженных ситуациях большинство программистов объединяется в пары. Почему? Потому что парное программирование очевидным образом является самым эффективным способом решения задачи. Вспомните старую поговорку: «Две головы лучше, чем одна». Но если парное программирование является самым эффективным способом решения задач в напряженных ситуациях, с чего бы ему не быть самым эффективным способом решения задач в нормальное время?

Я не собираюсь цитировать научные исследования, хотя у меня в запасе найдется немало подходящих цитат. Я не буду рассказывать «случаи из жизни», хотя и их у меня тоже предостаточно. Я даже не собираюсь указывать, какую часть времени следует проводить за парным программированием. Скажу одно – профессионалы работают в парах. Почему? Потому что по крайней мере для некоторых задач эта методология наиболее эффективна. Впрочем, это не единственная причина.

Профессионалы также объединяются в пары, потому что это лучший способ обмена знаниями. Профессионалы не создают «банки знаний» – вместо этого они изучают разные аспекты системы и бизнеса, объединяясь в пары. Они понимают, что хотя у каждого участника группы имеется своя должность, все участники должны быть готовы моментально переключаться в случае необходимости.

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

Однажды утром на самом пике бума интернет-коммерции я приехал на поезде в Чикаго. Когда я ступил на платформу, мне в глаза бросился огромный плакат над выходом. Хорошо известная фирма-разработчик приглашала на работу программистов. На плакате было написано: «Поработайте мозжечком рядом с лучшими!»

Столь выдающаяся глупость меня поразила. Жалкие бестолковые рекламщики пытались произвести впечатление на умных, эрудированных, технически грамотных программистов – на людей, которые плохо переносят глупость. Рекламщики пытались создать впечатление, будто на новой работе вы будете обмениваться знаниями с другими умными людьми. К сожалению, упомянутая в рекламе часть мозга – мозжечок – отвечает за координацию движений, а не за интеллект. И те люди, которых пытались привлечь этой рекламой, только ухмылялись над глупой ошибкой.

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

Профессионалы работают вместе. Невозможно работать вместе, рассевшись по углам с наушниками. Участники группы должны сидеть за общим столом, повернувшись друг к другу лицом. Они должны чувствовать опасения своих коллег, слышать их раздраженное бормотание. Между ними должно идти постоянное общение – как вербальное, так и на уровне «языка тела». Они должны взаимодействовать как единое целое.

Возможно, вам кажется, что в одиночку вы будете работать эффективнее. Даже если это и так, отсюда вовсе не следует, что группа будет работать эффективнее. И в действительности крайне маловероятно, что в одиночку вы действительно лучше справляетесь со своей работой.

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