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