Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Аллен: Мы работали командой, но это касалось состояния системы, реализации. Некоторые специалисты очень хорошо справлялись непосредственно с реализацией, поэтому владели определенным фрагментом - фрагмент оптимизатора или внутрипроцедурный анализ определенно делался кем-то одним или двумя. Но были и специалисты, которые делали огромную теоретическую, научную работу - писали доклады, документы и алгоритмы. Единство этих двух противоположностей и сделало нашу группу такой мощной и сплоченной.
В то время велась большая работа по анализу и трансформациям для
Сейбел: Многие программисты сделают все, что угодно, лишь бы избежать руководящей работы. Нравилось ли вам быть руководителем?
Аллен: В первые годы существования исследовательского центра не было разделения - руководящая должность вовсе не означала продвижения по карьерной лестнице, повышения оклада. Просто кому-то нужно было руководить разработкой вот этого отрезка работы, поэтому говорилось что-то вроде: “Не хочешь ли взяться за это?” или “Очевидно, этим должен руководить ты”. Это было техническое руководство - таких руководителей было немного. Но в исследовательском центре человек становится членом исследовательского центра (Research Staff Member, RSM) с момента прихода туда и практически до конца карьеры. Вот кем являемся мы с коллегами. Поэтому можно постоянно выдвигаться и уходить с руководящей должности - без какого-либо клейма.
Сейбел: Скорее всего, руководить доверят тому, кто хорошо с этим справляется. Как вы приобрели подобные навыки?
Аллен: Ну, меня отправили на курсы менеджмента. В то время, когда меня впервые назначали руководителем, обычно делалось так. Но, думаю, все началось еще когда я росла на ферме. Я была старшей из шести детей - пятеро младших были погодки, и мне, конечно, приходилось помогать родителям. Возможно, это естественная для меня роль, в каком-то смысле.
Сейбел: Одна из трудностей в техническом менеджменте, которым вы занимались, - уравновесить стремление самому направлять работу сотрудников и их желание думать самостоятельно.
Аллен: Как мне представляется, в рамках работы над проектом Stretch я получила ряд суровых уроков. Помню, однажды ко мне подошли несколько сотрудников проекта и сказали, что мы должны использовать списки и хеш-функции. Мы знали о списках, но хеширование было в новинку. И двое колллег говорят мне, что хотят использовать хеширование для таблицы символов. Я ответила: “Нет, мы не можем. Мы не знаем, как с этим работать”. Бла-бла-бла. В следующий понедельник я прихожу и вижу - они сделали это. Они снесли систему целиком и сделали ее заново, добавив туда хеширование. Это сработало, система начала работать намного быстрее. Это был важный урок для меня. Я должна быть более открытой для совершенно новых идей.
Сейбел: То есть иногда - может быть, даже часто - подчиненные знают, о чем говорят,
Аллен: Да, бывало и так. Нередко приходил сотрудник, обладавший знаниями в определенной сфере, с желанием применить эти знания в работе над текущей частью проекта. Но поскольку он работал в проекте недавно, то не знал его специфику. И обычно это происходило незадолго до дедлайна.
С серьезной проблемой такого рода я столкнулась, выполняя какой-то проект по договору субподряда. У меня была группа специалистов, прекрасно справлявшихся с созданием оптимизатора на основе нашей же работы, которую мы проделали для ПЛ/1 - громоздкого, очень прихотливого языка. Но кто-то из работников субподрядчика, недавно открыв для себя объектно-ориентированное программирование, решил применить его здесь по полной. Я не смогла ему помешать, даже несмотря на то, что отвечала за контракт, и проект был загублен. Грубо говоря, проблема была в том, что в ПЛ/1 множество указателей, и каждый указатель постоянно отслеживался; а чтобы отслеживать значение, то есть находить значение по указателю, требовалось 11 инструкций.
Сейбел: То есть в уже сгенерированном коде.
Аллен: В сгенерированном коде и в самом компиляторе, поскольку все это запускало и сам компилятор. Каждый раз, сделав шаг, нужно было убедиться, что все в порядке. Проверить, перепроверить и снова перепроверить. Так делается и сегодня. Некоторые уроки мы так и не выучили. И мне кажется, что я не очень правильно поступила в той ситуации: нужно было указать на издержки, связанные с применением там объектно-ориентированной технологии. Все работало ужасно медленно, поэтому проект был закрыт.
Сейбел: Какие продукты для IBM, в разработке которых вы принимали участие, имели сроки сдачи, в которые надо было уложиться?
Аллен: Безусловно, здесь нужно упомянуть проект Stretch. Кроме того, я участвовала в разработке продукта еще 2-3 раза, с еженедельными ревизиями кода незадолго до сдачи проекта. Я с большим уважением отношусь к этим процессам, считаю их очень важными для конечного результата и для команды, работающей над проектом. Хотя это может быть очень утомительным - каждую пятницу садиться читать код, слушая объяснения, почему сделано так-то и так-то, и находить ошибки других.
Сейбел: Это утомительно, но стоит того?
Аллен: Безусловно, стоит. Во время работы над проектом PTRAN, ближе к завершению, мы включали фрагменты кода в другие продукты, полдня уходило на объяснение ошибок в нашем коде, их коде, неважно, - и так каждую неделю, около 10 месяцев. Полпятницы уходило на это.
Сейбел: Работая в подобных условиях, вы ощущали, что у вас есть процесс, позволяющий достаточно точно рассчитать время, необходимое для создания определенного объема ПО?