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

Сейбел: Как вы полагаете, программирование — удел молодых?

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

Сейбел: Одна из особенностей нового стиля программирования, как вы подметили, в том, что программист должен впитывать все новое быстро. Что вы делаете, когда нужно прочесть и понять большой фрагмент совершенно незнакомого кода?

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

Сейбел: Вы занимались литературным программированием в духе Кнута?

Норвиг: Как таковым — нет. Конечно, я писал макросы и тому подобное, использовал документы Java. Программирование на Лиспе побуждает к созданию собственной системы по мере написания кода, в конце концов это выливается в литературное программирование. Вырабатываешь собственные макросы для программирования в контексте своего приложения — тут и документация, и данные, и код. Так что в принципе я занимался этим. Уже позднее, работая с Java, или Python, или другим языком, я внимательно относился к созданию тестов и документации для них.

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

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

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

Сейбел: Вы говорили о том, как читали в «Scientific American» код программы для шашек. В книге «Как самому научиться программировать за десять лет» вы подчеркиваете важность чтения кода. Какой код вы еще читали, кроме кода Стрейчи?

Норвиг: Много кода Symbolics — он был под рукой, когда я работал в Беркли.

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

Норвиг: И то и другое. Иногда я просто пытался понять, как все устроено, а иногда решал конкретную задачу.

Сейбел: Если вы читаете просто для самообразования, то что именно?

Норвиг: То, что мне интересно. «Смотри-ка, эта файловая система позволяет читать файлы по сети при помощи того же протокола, что я локально использую на своей машине. Как это? Может быть, это в функции open?» Смотришь на то, что эта функция вызывает, смотришь еще куда-нибудь и понимаешь, как это работает.

Сейбел: Вы читали книги с литературными программами Кнута?

Норвиг: Листал. Не скажу, что читал.

Сейбел: А как насчет «Искусства программирования»? Одни мои собеседники прочли ее от корки до корки, другие поставили на полку и используют для справок, третьи просто поставили на полку.

Норвиг: Как-то я сделал из нее подставку для монитора — это ведь громадный многотомник, как раз подошел по высоте. Думал, если он будет прямо передо мной, то я, наконец-то, начну его использовать.

Сейбел: Но ведь надо было всякий раз поднимать монитор?

Норвиг: Нет, тома были в коробке. Если сильно потянуть, можно достать. Сейчас я редко пользуюсь книгами для справки — все больше интернет-поиском.

Сейбел: Потому что так удобнее?

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

Сейбел: Кем вы себя считаете — ученым, инженером, художником, ремесленником?

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

Но это, мне кажется, не искусство. «Ремесло» — вот самый подходящий термин. Вы можете сделать стул, на который приятно смотреть, но это все равно предмет функционального назначения.

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

Норвиг: До сих пор не знаем.

Сейбел: Google известен тем, что на собеседованиях претендентам задают логические загадки. Как полагаете, это удачный подход?

Норвиг: Не думаю, что это важно — умеет человек решать такие задачи или нет. Я не люблю задавать головоломные вопросы. Важно дать претенденту техническую задачу, а не поболтать с ним и убедиться, что он — отличный парень. Правда, человек должен еще уметь работать в коллективе. Но прежде всего нужна техническая проверка: умеет ли он делать то, о чем заявляет. Для этого есть много методик. Часто все ясно из резюме. Лучшая рекомендация — если человек работал с кем-то из наших сотрудников и тот может за него поручиться. Но мы стремимся также полноценно использовать собеседование. По большей части для того, чтобы почувствовать, как этот человек думает, как он работает вместе с кем-то. Владеет ли он базовыми понятиями? Может ли он сказать: «Для решения мне нужно знать А, Б и В», — и начать связывать их вместе? Думаю, это можно показать, даже не решив логическую задачу. Соискатель говорит, к примеру: «Я буду решать так: сначала подумаю об этом, потом сделаю это, потом это, а эту часть я, эээ, не совсем понимаю». Кто-то справляется с этой частью, кто-то нет. Но даже если человек не справился, он может произвести хорошее впечатление тем, насколько компетентно и уверенно подошел к делу. И, конечно, если берешь человека для написания кода, то просишь его написать код на доске. Кто-то подзабыл это дело или не очень хорошо знает — и это видно сразу.

Сейбел: Так это только негативный индикатор? Если человек не может написать вменяемый кусок кода, это плохой признак. Но если может, это вовсе не значит, что он сумеет решать более крупные задачи.