Holding a Program in One's Head

Август 2007

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

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

Ваш код — это ваше понимание исследуемой проблемы. Поэтому только когда вы держите код в голове, вы по-настоящему понимаете проблему.

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

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

Избегайте отвлечений. Отвлечения вредны для многих видов работы, но для программирования — особенно, потому что программисты, как правило, работают на пределе объёма деталей, который способны удержать.

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

Как ни странно, запланированные отвлечения могут быть хуже незапланированных. Если вы знаете, что через час у вас совещание, вы даже не начинаете работать над чем-то сложным.

Работайте длинными сессиями. Поскольку каждый раз, когда вы начинаете работать над программой, есть фиксированные затраты на вход, эффективнее работать несколькими длинными сессиями, чем множеством коротких. Разумеется, наступит момент, когда вы отупеете от усталости. У каждого это по-разному. Я слышал о людях, которые программировали 36 часов подряд, но максимум, что мне удавалось, — около 18, а лучше всего я работаю блоками не длиннее 12.

Оптимум — не предел, который вы можете физически выдержать. У перерыва в работе над проектом есть не только издержки, но и преимущества. Иногда, вернувшись к задаче после отдыха, вы обнаруживаете, что подсознание оставило вам готовый ответ.

Используйте лаконичные языки. Более мощные языки программирования делают программы короче. А программисты, похоже, мыслят о программах хотя бы отчасти на языке, на котором их пишут. Чем лаконичнее язык, тем короче программа и тем легче загрузить и удержать её в голове.

Эффект мощного языка можно усилить с помощью стиля, называемого восходящим программированием, при котором программа пишется в несколько слоёв, а нижние слои выступают в роли языков программирования для верхних. Если сделать это правильно, вам нужно удерживать в голове лишь верхний слой.

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

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

Работайте маленькими группами. Когда вы манипулируете программой в голове, ваше видение останавливается на границе кода, который принадлежит вам. Остальные части вы понимаете хуже и, что ещё важнее, не можете обращаться с ними вольно. Поэтому чем меньше программистов, тем полнее проект может мутировать. Если программист один — а на старте часто так и бывает — можно делать всеобъемлющие переработки архитектуры.

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

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

Если вы хотите привлечь к проекту нескольких человек, разделите его на компоненты и отдайте каждый одному человеку.

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

Поразительно, как часто программисты случайно попадают во все восемь пунктов. У кого-то появляется идея нового проекта, но поскольку она не одобрена официально, приходится заниматься ею в нерабочее время — которое оказывается более продуктивным из-за отсутствия отвлечений. Движимый энтузиазмом к новому проекту, он работает над ним много часов подряд. Поскольку поначалу это лишь эксперимент, вместо «продакшен»-языка он использует какой-нибудь «скриптовый» — который на самом деле куда мощнее. Он полностью переписывает программу несколько раз; для официального проекта это было бы неоправданно, но это дело любви, и он хочет, чтобы всё было идеально. А поскольку кроме него это никто не увидит, он опускает все комментарии, кроме заметок для себя. Он работает в маленькой группе вынужденно — потому что либо ещё никому не рассказал об идее, либо она кажется настолько бесперспективной, что никому другому не позволяют над ней работать. Даже если группа есть, несколько человек не могут редактировать один код — он меняется слишком быстро. А проект начинается с малого, потому что сама идея поначалу мала: просто крутой хак, который хочется попробовать.

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

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

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

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

Хорошим программистам всё равно удаётся сделать многое. Но зачастую это требует чуть ли не бунта против нанявших их организаций. Возможно, станет легче, если больше людей поймут, что поведение программистов диктуется требованиями их работы. Они работают долгими запоями, забрасывая все прочие обязательства, бросаются сразу программировать вместо того чтобы сначала писать спецификации, и переписывают уже работающий код не потому, что безответственны. Предпочитают работать в одиночку и рычат на тех, кто суёт голову в дверь, чтобы поздороваться, не потому, что нелюдимы. У этой, казалось бы, случайной коллекции раздражающих привычек есть единственное объяснение: сила удержания программы в голове.

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

Благодарности: Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev и Stephen Wolfram за чтение черновиков этого эссе.