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

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

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

Сейбел:Какие навыки, кроме умения писать код, нужны тем, кто приходит в индустрию ПО?

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

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

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

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

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

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

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

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

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

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

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

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

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