Программы обычно создаются группами разработчиков. Одним из условий эффективной работы группы является профессиональное взаимодействие участников. Быть одиночкой или отшельником в группе непрофессионально.
В 1974 году мне было 22 года. Прошло полгода с момента брака с моей замечательной женой Энн-Мэри. До рождения нашего первого ребенка, Анджелы, оставался еще год. Тогда я работал в одном из подразделений Teradyne, называвшемся Chicago Laser Systems.
Рядом со мной трудился мой приятель по средней школе Тим Конрад. В свое время мы с ним занимались всякими интересными вещами: собирали компьютеры в его подвале, мастерили «лестницы Якова» в моем, учили друг друга программировать для PDP-8 и собирать настоящие калькуляторы из микросхем и транзисторов.
На работе мы программировали систему, которая использовала лазеры для высокоточной обрезки электронных компонентов (резисторов, конденсаторов и т. д.) В частности, мы нарезали кристаллы для первых цифровых часов, Motorola Pulsar.
Программирование велось на компьютере M365, клоне Teradyne PDP-8. Система писалась на ассемблере, а исходные файлы хранились на магнитных лентах. Хотя мы могли править код в экранном редакторе, процесс был достаточно сложным, поэтому для чтения кода и предварительной правки использовались в основном печатные листинги.
У нас не было никаких средств поиска по кодовой базе. Не было возможности найти все места вызова заданной функции или использования заданной константы. Как нетрудно представить, это основательно тормозило нашу работу.
И вот однажды мы с Тимом решили написать генератор перекрестных ссылок. Программа должна была читать ленты с исходным кодом и выводить на печать списки всех символических имен с указанием файла и номера строки, в которой это имя использовалось.
Исходная программа была достаточно простой. Она читала ленту, разбирала ассемблерный код, строила таблицу символических имен и добавляла в нее ссылки. Программа прекрасно работала, но была жутко медленной. Обработка главной операционной программы (MOP) занимала около часа.
Такая скорость объяснялась тем, что растущая таблица символических имен хранилась в одном буфере. Каждый раз, когда программа находила новую ссылку, она вставлялась в буфер, а остаток буфера сдвигался на несколько байт, чтобы освободить место.
Мы с Тимом не были экспертами по структурам данных и алгоритмам. Мы никогда не слыхали о хеш-таблицах и бинарном поиске. Мы понятия не имели, как ускорить алгоритм. Мы просто знали, что наша программа работает слишком медленно.
Тогда мы стали пробовать одно решение за другим. Мы объединяли ссылки в связанный список. Мы оставляли пропуски в массиве и увеличивали буфер только после их заполнения. Мы пытались создавать связанные списки пропусков. Мы опробовали множество безумных идей. Мы стояли у доски в офисе, рисовали диаграммы структур данных и занимались вычислениями для прогнозирования быстродействия. Мы ежедневно приходили на работу с новыми идеями. Постоянно шел интенсивный творческий обмен.
В конечном итоге мы сократили время работы программы до 15 минут, что было довольно близко к времени простого чтения ленты. Тогда мы успокоились.
Программисты и люди
Как правило, программисты не любят работать с людьми. Они находят, что межличностные отношения слишком хлопотны и непредсказуемы. Программисты предпочитают четкое, предсказуемое поведение компьютеров. Они счастливы, часами просиживая в комнате, глубоко сосредоточившись на какой-нибудь интересной задаче.
Ладно, это слишком серьезное обобщение, а из правил существует множество исключений. Многие программисты успешно работают с людьми и им нравится это занятие. Однако в среднем по группам тенденция именно такова, как я изложил. Нас, программистов, радует умеренная сенсорная недостаточность и глубокое погружение в работу – своего рода «кокон».
Программисты и работодатели
В 1970-е и 1980-е годы, во время работы в Teradyne, я хорошо освоил процесс отладки. Мне нравилось это занятие, я бросался на сложные задачи с пылом и энтузиазмом. Ни одна ошибка не могла долго прятаться от меня!
Устраняя очередную ошибку, я чувствовал себя победителем! Я отправлялся к своему боссу Кен Файндеру и с энтузиазмом рассказывал, какая интересная мне попалась ошибка. Но однажды Кен в отчаянии воскликнул: «Ошибки не интересны. Их просто нужно исправлять!»
В этот день я усвоил важный урок. Хорошо с энтузиазмом относиться к тому, чем вы занимаетесь. Но при этом также стоит помнить о целях людей, которые вам платят.
Первая обязанность профессионального программиста – заботиться об интересах своих работодателей. Это означает, что вы должны общаться со своими начальниками, бизнес-аналитиками, тестерами и другими участниками группы, чтобы глубоко понимать коммерческие цели проекта. Никто не заставляет вас становиться экспертом в области бизнеса. Просто нужно понимать, зачем вы пишете свой код и какую пользу он приносит вашей фирме.
Худшее, что может сделать профессиональный программист, – в блаженном неведении укрыться в технологическом убежище, когда бизнес горит и рушится вокруг него. Ваша работа – удерживать бизнес на плаву!
Итак, профессиональный программист должен выделить время на изучение коммерческой стороны дела. Он говорит с пользователями о программном продукте, с которым они работают. Он общается с людьми из отдела продаж и маркетинга по поводу возникающих проблем. Он говорит с начальством, чтобы понять как краткосрочные, так и долгосрочные цели группы.
Короче говоря, профессиональный программист обращает внимание на корабль, на котором он плывет.
За всю мою карьеру меня уволили с должности программиста всего один раз. Это произошло в 1976 году, когда я работал на Outboard Marine Corp. Я помогал писать систему автоматизации производства, которая использовала компьютеры IBM System/7 для контроля за десятками автоматов алюминиевого литья в главном цехе предприятия.
С технической точки зрения это была интересная и сложная работа. Архитектура System/7 приводила меня в восторг, а система автоматизации производства тоже была весьма захватывающей.
У нас была хорошая группа. Руководитель группы Джон был компетентным и целеустремленным специалистом. Два моих коллеги-программиста были приятными людьми, готовыми прийти на помощь. Под наш проект была выделена специальная лаборатория, в которой мы работали. Наш бизнес-партнер участвовал в работе и находился с нами в лаборатории. Наш начальник Ральф был компетентным и ответственным.
Все было замечательно. Проблема была во мне. Я с энтузиазмом относился к проекту и технологии, но в возрасте 24 лет я не мог заставить себя думать о бизнесе или внутренней политической структуре.
Первую ошибку я совершил в первый же день. Я пришел на работу без галстука. Я надел галстук на собеседование, и я видел, что все носят галстуки, но не сделал выводов. Итак, в первый день Ральф подошел ко мне и просто сказал: «Мы здесь носим галстуки».
Не могу описать, насколько меня это бесило. Я ощущал глубочайшее раздражение. Я носил галстук каждый день и ненавидел его. Но почему? Ведь я знал, куда я поступаю на работу. Я знал принятые правила. Почему меня это раздражало? Потому что я был эгоистичным, самовлюбленным типом.
Я просто не мог приходить на работу вовремя. И мне казалось, что это не важно. В конце концов, я «хорошо справлялся». И это было правдой: я действительно очень хорошо справлялся с написанием своих программ. Бесспорно, я был лучшим программистом в группе. Я мог писать код быстрее и лучше других. Я быстрее находил и устранял проблемы. Я знал, что я был ценным специалистом, так что время и даты для меня значили мало.
Решение о моем увольнении было принято тогда, когда я опоздал на одну из контрольных точек проекта. По всей видимости, Джон сказал нам, что в следующий понедельник ему нужна демо-версия рабочих функций системы. Наверняка я знал об этом, но просто не обратил внимания.
Система находилась в стадии активной разработки. До реальной эксплуатации было еще далеко. Не было причин оставлять систему в рабочем состоянии, когда в лаборатории никого не было. Я последним уходил с работы в пятницу, и, видимо, я оставил систему в неработоспособном состоянии. Тот факт, что понедельник был важной датой, просто не отложился у меня в памяти.
В понедельник я пришел на час позже и увидел, как все мрачно собрались вокруг нерабочей системы. Джон спросил: «Почему система не работает сегодня, Боб?» Я ответил: «Не знаю», и сел за отладку. Я даже тогда не вспомнил о демо-версии, запланированной на понедельник, но по поведению моих коллег было совершенно ясно, что произошло что-то нехорошее. Тогда Джон подошел ко мне, прошептал на ухо: «А если бы пришел Стенберг?» и отошел в негодовании.
Стенберг был вице-президентом по автоматизации. Сегодня его должность назвали бы «руководителем технической службы». Вопрос показался мне бессмысленным. «Ну и что? – подумал я. – Система же не в эксплуатации, так в чем проблема?»
В этот день я получил первое предупредительное письмо. В нем мне предлагалось немедленно изменить свое отношение к работе, иначе «последует немедленное увольнение». Я был в ужасе!
Мне пришлось проанализировать свое поведение и понять, что же я делал не так. Я поговорил с Джоном и Ральфом с твердым намерением изменить себя и свой стиль работы.
И я это сделал! Я перестал опаздывать, начал обращать внимание на внутреннюю политику. Я начал понимать, почему Джон беспокоился по поводу Стенберга. Я понял, как подвел его, оставив на понедельник неработоспособную систему.
Но было слишком поздно. Через месяц я получил второе предупреждение по поводу какой-то тривиальной ошибки. В этот момент мне следовало понять, что письма были простой формальностью, а решение об увольнении уже было принято. Но я твердо решил все исправить и работал еще прилежнее.
Еще через несколько недель мне сообщили об увольнении.
Мне пришлось идти домой к своей беременной 22-летней жене и рассказывать, что я потерял работу. Мне бы не хотелось, чтобы такое когда-нибудь повторилось в моей жизни.
Программисты и программисты
У программистов часто возникают трудности при работе в тесном контакте с другими программистами. Порой это создает серьезные проблемы.
Принадлежность кода
Один из худших признаков неправильно функционирующей команды – когда каждый программист возводит стену вокруг своего кода и запрещает другим программистам прикасаться к нему. Я был в местах, где программисты даже запрещали другим смотреть на свой код. Это верный путь к катастрофе.
Однажды я консультировал компанию, производившую высококлассные принтеры. Машины состояли из множества разных компонентов: систем подачи бумаги, печати, укладки бумаги, сшивания листов, резаков и т. д. С точки зрения бизнеса эти системы обладали разной ценностью. Система подачи листов была важнее системы укладки, но ни одно устройство не могло сравниться по важности с системой печати.
Каждый программист работал над своей системой. Один писал код для системы подачи листов, другой – код для системы сшивания и т. д.
Все они бдительно охраняли свою технологию и не позволяли никому притрагиваться к своему коду. Политический вес программистов был напрямую связан с коммерческой ценностью устройства. Программист, работавший над устройством печати, обладал непререкаемым авторитетом.
Для технологии такое положение дел имело катастрофические последствия. Мне, консультанту, было хорошо видно массовое дублирование кода и разнобой в интерфейсах между модулями. Но никакие аргументы с моей стороны не могли убедить программистов (или представителей бизнеса) изменить подход к работе. Ведь их зарплата была связана с важностью устройств, которыми они занимались.
Коллективная принадлежность кода
Разрушьте стены принадлежности кода – код должен принадлежать всей группе. Я предпочитаю работать с группами, в которых любой участник может проверить любой модуль и внести те изменения, которые сочтет нужным. Я предпочитаю, чтобы код принадлежал группе, а не конкретным людям.
Профессиональные разработчики не запрещают коллегам работать со своим кодом. Они не возводят вокруг своего кода стены принадлежности. Напротив, они стараются работать друг с другом над как можно большей частью кода. И работая над другими частями системы, они учатся друг у друга.
Парное программирование
Многие программисты не любят идею парного программирования. Мне это кажется странным, потому что в напряженных ситуациях большинство программистов объединяется в пары. Почему? Потому что парное программирование очевидным образом является самым эффективным способом решения задачи. Вспомните старую поговорку: «Две головы лучше, чем одна». Но если парное программирование является самым эффективным способом решения задач в напряженных ситуациях, с чего бы ему не быть самым эффективным способом решения задач в нормальное время?
Я не собираюсь цитировать научные исследования, хотя у меня в запасе найдется немало подходящих цитат. Я не буду рассказывать «случаи из жизни», хотя и их у меня тоже предостаточно. Я даже не собираюсь указывать, какую часть времени следует проводить за парным программированием. Скажу одно – профессионалы работают в парах. Почему? Потому что по крайней мере для некоторых задач эта методология наиболее эффективна. Впрочем, это не единственная причина.
Профессионалы также объединяются в пары, потому что это лучший способ обмена знаниями. Профессионалы не создают «банки знаний» – вместо этого они изучают разные аспекты системы и бизнеса, объединяясь в пары. Они понимают, что хотя у каждого участника группы имеется своя должность, все участники должны быть готовы моментально переключаться в случае необходимости.
Профессионалы объединяются в пары, потому что это лучший способ рецензирования кода. Ни в одной системе не должно быть кода, который не был прорецензирован другими программистами. Существует много механизмов рецензирования кода; в большинстве своем они ужасающе неэффективны. Самый эффективный и действенный способ рецензирования кода – участие в его написании.
Как работать мозжечком
Однажды утром на самом пике бума интернет-коммерции я приехал на поезде в Чикаго. Когда я ступил на платформу, мне в глаза бросился огромный плакат над выходом. Хорошо известная фирма-разработчик приглашала на работу программистов. На плакате было написано: «Поработайте мозжечком рядом с лучшими!»
Столь выдающаяся глупость меня поразила. Жалкие бестолковые рекламщики пытались произвести впечатление на умных, эрудированных, технически грамотных программистов – на людей, которые плохо переносят глупость. Рекламщики пытались создать впечатление, будто на новой работе вы будете обмениваться знаниями с другими умными людьми. К сожалению, упомянутая в рекламе часть мозга – мозжечок – отвечает за координацию движений, а не за интеллект. И те люди, которых пытались привлечь этой рекламой, только ухмылялись над глупой ошибкой.
Но в этой рекламе меня заинтриговало другое. Я представил себе группу людей, пытающихся «поработать мозжечком». Поскольку мозжечок находится в задней части мозга, я представил себе группу программистов, рассевшихся по кабинкам затылками друг к другу, уставившихся на мониторы и оградившихся от внешних раздражителей наушниками. Это нельзя назвать группой.
Профессионалы работают вместе. Невозможно работать вместе, рассевшись по углам с наушниками. Участники группы должны сидеть за общим столом, повернувшись друг к другу лицом. Они должны чувствовать опасения своих коллег, слышать их раздраженное бормотание. Между ними должно идти постоянное общение – как вербальное, так и на уровне «языка тела». Они должны взаимодействовать как единое целое.
Возможно, вам кажется, что в одиночку вы будете работать эффективнее. Даже если это и так, отсюда вовсе не следует, что группа будет работать эффективнее. И в действительности крайне маловероятно, что в одиночку вы действительно лучше справляетесь со своей работой.
В одних ситуациях работа в одиночку – именно то, что нужно. Иногда вам просто нужно долго и напряженно думать над задачей. В других случаях задача настолько тривиальна, что привлекать к работе другого человека было бы попросту расточительно. Но в общем случае лучше выделять значительную часть времени на работу в тесном контакте с другими и парное программирование.
Заключение
Возможно, кто-то из нас пришел в программирование не для того, чтобы работать с людьми. Ему не повезло: все программирование неразрывно связано с работой с людьми. Мы должны общаться со стороной бизнеса, и мы должны общаться друг с другом.
Знаю, знаю: мы бы предпочли работать в закрытой комнате с шестью большими экранами, каналом T3, параллельным массивом сверхбыстрых процессоров, неограниченным объемом памяти и дискового пространства, а также бесконечным запасом диетической колы и острых кукурузных чипсов. Увы, так не будет. Если вы хотите заниматься программированием, придется научиться общаться.