День 142. Размышления о работе программиста (IV)

6. Саймон Пейтон-Джонс, один из создателей языка Haskell, ведущий исследователь лаборатории Microsoft Research


Я решил, что столько напряженной работы не для меня, стал искать работу и пошел преподавателем в Лондонский университетский колледж. У меня не было ни степени, ни опыта исследовательской работы. И декан факультета облегчил мне нагрузку, чтобы я мог заниматься исследовательской работой. Но у меня не было ни малейшего понятия насчет того, что делать. Я сидел в своем кабинете перед чистым листом бумаги и ждал Великих Идей. В полной тишине я обводил комнату взглядом в поисках Великих Идей. И все.

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

Я повторял его потом каждому аспиранту. Так и нужно начинать.

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

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

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

У меня есть статья о том, как написать хорошую статью или сделать хороший доклад об исследовании, и одно из главных правил в ней — «не описывайте артефакт». Артефакт есть продукт реализации некой идеи. А что такое идея, этот предмет многократного использования, который вы пытаетесь вручить своим читателям или слушателям? Нечто такое, что может быть для них полезно. Задача ученого как раз в том, чтобы извлекать идеи, пригодные для многократного использования, из конкретных артефактов. Это не наука в смысле открытия законов. Но это перевод ежедневной жизненной суеты в абстракции многократного использования. И я считаю это важным.

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

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

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

Сейчас программирование больше похоже на сборку из готовых модулей, чем на создание чего-то с нуля. Сейчас, делая домашнее задание — скажем, сайт, — школьник возьмет для одной части Ruby on Rails, для другой — Drupal, для третьей — скрипт на Python, а потом скачает статистическую программу. И все это связывается между собой с помощью скриптов, а не пишется с нуля. Сегодня важнее понимать интерфейсы и уметь их соединять, чем знать в деталях, что делается внутри ПО.

7. Питер Дойч, один из разработчиков языка программирования Smalltalk, бывший сотрудник Sun Microsystems, почетный член АСМ

С человеком что-то должно быть слегка не так, чтобы он стал хорошим программистом.

Тогда меня осенило: причина, по которой я не мог найти другой проект, связанный с ПО, который меня бы заинтересовал, была не в том, что я не мог найти проект. Дело было в том, что ПО меня больше не интересовало. Каким бы безумием это ни казалось сейчас, но главная причина, по которой я в первую очередь когда-то стал заниматься разработкой ПО, заключалась в том, что я думал: это поможет мне сделать мир лучше. Сейчас я в это больше не верю. Не очень-то верю. Уже не так сильно верю.

Обсудить у себя 0
Комментарии (0)
Чтобы комментировать надо зарегистрироваться или если вы уже регистрировались войти в свой аккаунт.

Войти через социальные сети:

Сахаров Денис
Сахаров Денис
Был на сайте вчера в 17:59
Читателей: 17 Опыт: 784.319 Карма: 5.92687
все 18 Мои друзья