Кодеры за работой. Размышления о ремесле программиста

Сейбел: То есть можно нанять человека, рекомендованного вам профессором, которого знаешь и которому доверяешь. А если проводишь собеседование с тем, у кого нет солидной рекомендации, - как за несколько часов понять, станет человек хорошим программистом или нет?

Аллен: Я всегда начинала собеседование с претендентом на место в исследовательском центре IBM, пытаясь понять, что этого человека интересует в жизни. Для меня это был своего рода пороговый уровень. Было абсолютно не важно, имело ли это увлечение какое-то отношение к программированию или компьютерам. Если человек не может ни чем увлечься, то не будет выкладываться по полной, работая в группе.

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

Сейбел: В дальнейшем вы стали заниматься наставничеством - IBM даже присуждает премию лучшему наставнику, названную в вашу честь. Как сделать, чтобы неопытные программисты становились более квалифицированными программистами?

Аллен: Я и сейчас не очень-то понимаю, что такое наставничество. Главное - нужно посоветовать начинающему специалисту не занимать слишком рано руководящую должность, что весьма соблазнительно для тех, у кого есть соответствующие таланты. Для начала нужно заработать репутацию своей технической работой. Какая-то интересная научная работа, алгоритм, отлично написанный код - что угодно; сначала нужно заработать себе репутацию чем-то подобным. Это сослужит вам хорошую службу, если вы действительно хотите руководить проектами, понимая в деталях, что требуется для выполнения той или иной работы.

Сейбел: Возможно ли вообще быть хорошим руководителем, не имея выдающихся технических способностей, а просто умея хорошо координировать работу других?

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

Сейбел: Это, наверное, самое сложное. Как по-вашему, чем отличается по-настоящему хороший программист?

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

Кроме того, я опираюсь на мнение других. Я часто ошибаюсь, и бывает очень познавательным обнаружить, что думаешь о специалисте намного лучше, чем остальные участники коллектива. Если у вас хорошая группа, то прислушиваться к мнению ее участников - очень эффективный способ узнать, кто хорошо справляется со своей работой.

Сейбел: Можете ли вы сказать, когда последний раз программировали?

Аллен: О, довольно давно. Наверное, я прекратила писать код, когда появился язык Си. Это был серьезный удар. Мы так успешно работали над оптимизациями и трансформациями. Мы решали одну непростую задачу за другой. После появления Си на одной из конференций, посвященных компиляторам SIGPLAN, случился спор между Стивом Джонсоном из Bell Labs, который поддерживал Си, и моим сотрудником Биллом Харрисоном, участником одного из моих тогдашних проектов, который поддерживал автоматическую оптимизацию.

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

Сейбел: Как вы считаете, с существованием языка Си можно было бы смириться, ограничив его применение ядром операционной системы?

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

К 1960 году у нас было множество прекрасных языков: Лисп, APL, Фортран, Кобол, Алгол 60. Это языки более высокого уровня, чем Си. С момента появления Си мы серьезно деградировали. Си уничтожил нашу способность прогрессировать в автоматической оптимизации, автоматической параллелизации, автоматическом отображении языков высокого уровня в машинную архитектуру. Это одна из причин, по которым компиляторы, по сути, больше не изучаются в колледжах и университетах.

Сейбел: При том что курсы по созданию компиляторов определенно читаются?

Аллен: Не во многих университетах. Это ужасно. До сих пор проводятся конференции, создаются хорошие алгоритмы, проводятся хорошие исследования, но отдача, по моему мнению, абсолютно минимальна. Все из-за того, что языки вроде Си слишком уж локализуют решение проблем. Подобные языки - вот что уничтожает компьютерные науки как предмет.

Сейбел: Но большинство современных новейших языков - более высокого уровня, чем Си. Например, Java, C#, Python и Ruby.

Аллен: Да, но они все равно излишне локализуют решение. Суть в том, что они точно указывают местонахождение данных. Если вы посмотрите на упомянутые мною языки (Лисп, APL, Фортран, Кобол, Алгол 60), то они не указывали местонахождение данных и как их перемещать, где их размещать в компьютере. В конечном итоге ключевым является значение данных в любой момент.

Сейбел: Но лишь немногие языки, вроде Си или C++, по-прежнему используют указатели в чистом виде. В Java есть сборка мусора, и данные перемещаются. По-вашему, это тоже излишняя локализация?

Аллен: Да. Я убеждена, что есть возможность сделать с данными то же самое, что мы сделали с вычислениями в мире оптимизации. Мы не очень хорошо умеем управлять данными. У нас нет хороших методов автоматического управления данными - установления местонахождения данных, которые будут использоваться совместно.

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