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

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

Сейбел: Программирование стало более социальным?

Норвиг: Думаю, да. Компьютерщики были больше обособлены от всех остальных. Раньше в основном шла пакетная обработка, интерфейсы были куда проще. Можно было работать по модели «водопада»: ввод — колода карт, вывод — отчет с таким-то номером в такой-то колонке.

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

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

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

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

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

Сейбел: Значит ли это, что успешный программист сегодня — человек другого склада?

Норвиг: Успешные люди, по-моему, не изменились, насколько я вижу. Но в целом — да, в наши дни лучше уметь быстро понять, что тебе нужно, чем досконально знать все процессы. Тут, конечно, есть этакая бравада: «Я просто беру и делаю это». Человек смело признается: «Я не понимаю, что тут внутри, но я залез в документацию и нашел там эти три штуки. Попробовал — работает. Значит, вперед».

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

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

Норвиг: Скорее первое. Стив Йегг написал статью «Good Agile, Bad Agile» (Agile-проектирование: хорошее и плохое), и думаю, в ней он прав. Десять процентов времени имеет смысл уделять коллективной работе, поскольку программисту необходимы понимающие слушатели. Больше — вряд ли стоит.

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

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

Помнится, у IBM была модель «программиста-мастера» — глупее никто еще ничего не придумал. Кто захочет быть на побегушках у опытного программиста?