Идеальный программист. Как стать профессионалом разработки ПО

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

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

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

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

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

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

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

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

Программисты и программисты

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

Принадлежность кода

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

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

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

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

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

Коллективная принадлежность кода

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

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

Парное программирование

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