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