The post has been translated automatically. Original language: Russian
In the early 2000s, one of the authors that we programmers really read was Joel Spolsky. Today he is known as one of the creators of Stack Overflow. Prior to that, he worked for Microsoft in the Excel team, where he was responsible for the release of VBA in Excel 5.0, and in 2000 he co-founded Fog Creek Software. In the same year, he started running Joel on Software, writing about programming, developer management, and the software business in the simple language of a man who did it himself.
It was important to us. At that time, we were, by and large, anonymous programmers. There was no current number of conferences, YouTube channels, Telegram, social networks and an endless stream of speeches by technical directors of large companies. And here, a man who worked at Microsoft talked about how software development actually works.
And then some of his thoughts practically changed our work. One of them is that a programmer cannot be constantly distracted.
Fifteen minutes to start working
In August 2000, Joel published the famous "Joel Test" — twelve questions for which he offered to quickly assess the working conditions of the development team. One of the questions was something like this: do programmers have a peaceful working environment?
And then there was an explanation that I particularly remember. Joel wrote about the state of deep concentration when a person is completely immersed in a task. According to his estimate, it takes about 15 minutes on average to reach maximum productivity. And it's very easy to knock a person out of this state: a phone, noise, a colleague with a question. Even a minute's distraction can lead to the programmer returning to normal work for up to half an hour.
For a programmer, this idea is especially clear. When you write a program, there are a lot of things in your head at the same time: the current function, the state of the variables, the data structure, the previous section of the code, what is called next, where an error may occur. You don't just type text — you spend some time building a model of a working system in your head.
And then someone comes up: "Listen, for a minute..."
The minute ends quickly, and the model in my head has to be reassembled.
Then Joel went even further.
In 2001, he wrote a separate article, Human Task Switches Considered Harmful, about the cost of switching between tasks. It was no longer just about the fact that the programmer was distracted by a conversation.
Joel wrote about a situation where a developer is given several full-fledged tasks at the same time and constantly switches it between them. According to his own feeling, switching between two large software projects could cost him about six hours. His managerial conclusion was quite radical: a good manager should help a person focus on one task, and not constantly toss the next one.
But personally, I was initially influenced by a simpler version of this idea.: do not touch the programmer when he is programming.
And I just had the perfect conditions to test it in practice.
One programmer and many officers
At that time, I was working on a Defense Ministry contract. I was the only programmer. And there were a lot of officers around, and we were all in the same room.
This had a completely predictable consequence. If something needed to be changed in the program, someone found a mistake or just noticed something that they wanted to fix, everyone considered it their duty to immediately come to me and inform me about it.
For the person who reports the error, everything looks completely logical: he saw the problem, it's three meters to the programmer, why not tell him right now? One came up, then the second, the third also needs to be clarified. Each one takes five minutes, and nothing terrible seems to have happened.
But it is almost impossible to program at the same time. The problem wasn't the number of minutes of conversation, but the constant destruction of the state I was in before the conversation.
And then Joel appeared.
When I read Spolsky's explanation, I finally had a good argument. It wasn't just "don't bother me with my work" anymore. It was possible to explain exactly why it was not necessary to interfere.
I brought this idea to everyone and set a fairly simple rule: if I'm sitting at the computer, don't touch me. When I get up, please. If you want to tell me about a mistake, suggest a change, or discuss something, no problem, but not while I'm sitting and programming.
And surprisingly, it worked. They really stopped touching me.
For one programmer to work in a room full of people, it turned out to be a huge change. There was no new development methodology, no complex management system — it was just that others began to realize that a person who was silently looking at a monitor was not necessarily idling at that moment. Perhaps the most difficult part of his job is happening right now.
Of course, we used it a bit later.
I must admit to the other side of this story. When the programmers got this argument, it turned out to be very convenient: sitting at a computer is a sacred territory, do not touch it.
But whether it's really at this moment that you're at the fifth level of concentration and solving an incredibly complex algorithmic problem is another matter. Sometimes, of course, we used it.
But that didn't make the idea wrong. A programmer really works differently than a person who can interrupt one conversation, hold another, and then continue the first one from the same place. The more complex the system, the more time it takes to restore its state in your head.
A quarter of a century has passed
It's interesting to look at this thought now. In the early 2000s, Joel's main enemy was a colleague who came to your desk.
Everything is much more efficient today. To distract a programmer, a person does not even need to get up from his seat: there is Telegram, mail, company messengers, a task system, Git notifications, calls, a phone and a browser with forty tabs open at the same time.
We've automated almost everything, including ways to keep people from concentrating.
And then the AI appeared.
At first glance, it seems that AI should solve the problem. Now you don't have to go ask a colleague how the function works or why the error occurs: you can ask the AI. And it really reduces some of the external distractions.
But a new kind of switching has appeared. A modern developer can simultaneously ask the AI to fix a bug in one module, generate tests for the second, look at the architecture of the third, and while all this is being done, open the fourth task.
Technically, this looks like an increase in performance. But the human head did not get four additional processors from this. When the AI returns four results, the person still has to understand each of them, restore the context of the task and decide what to do next.
Therefore, the problem that Joel wrote about a quarter of a century ago has not disappeared. She just changed her form: before we were switched by the boss, now we are perfectly able to switch ourselves.
AI especially raises the price of concentration
There is another paradox. AI speeds up the writing of code, which means that an increasing part of the programmer's value is not in the speed of typing characters.
The main thing is the ability to understand the task, maintain the architecture of the system, formulate constraints, check the result and notice an error. That is exactly the part of the job that requires concentration.
You can get a thousand lines of code very quickly. But if a person switches between tasks every five minutes, the presence of AI does not guarantee that they understand which system they are building in the end.
I would even say that in the age of AI, Joel's recommendation is becoming more important.: It is no longer the time of writing code that needs to be protected, but the time of thinking.
What's left of Joel's advice
Almost everything has changed in a quarter of a century: computers, languages, development tools, methodologies, version control systems, and cloud infrastructure. Now AI is also writing code with us.
But people still don't know how to instantly upload a large software project to their head after each notification. Therefore, one of the ideas of Joel on Software survived all these changes with almost no losses.
If a programmer is really immersed in a difficult task, do not approach him "for a minute." This minute may be much longer than it seems.
This thought actually helped me once. I just told the people around me: If I'm sitting at my computer, don't touch it. If I get up, please.
And they stopped touching me.
Well, the fact that later we programmers sometimes used this rule a little more widely than necessary is a completely different story.
В начале 2000-х одним из авторов, которых мы, программисты, действительно читали, был Джоэл Спольски. Сегодня его знают как одного из создателей Stack Overflow. До этого он работал в Microsoft в команде Excel, где отвечал за выпуск VBA в Excel 5.0, а в 2000 году стал сооснователем Fog Creek Software. В том же году он начал вести Joel on Software — писать о программировании, управлении разработчиками и софтверном бизнесе простым языком человека, который сам этим занимался.
Для нас это было важно. Мы тогда были, по большому счёту, безымянными программистами. Не было сегодняшнего количества конференций, YouTube-каналов, Telegram, социальных сетей и бесконечного потока выступлений технических директоров крупных компаний. А здесь человек, работавший в Microsoft, рассказывал, как на самом деле устроена разработка программ.
И некоторые его мысли потом совершенно практически меняли нашу работу. Одна из них — программиста нельзя постоянно отвлекать.
Пятнадцать минут, чтобы начать работать
В августе 2000 года Джоэл опубликовал знаменитый «Тест Джоэла» — двенадцать вопросов, по которым предлагал быстро оценить условия работы команды разработчиков. Один из вопросов звучал примерно так: есть ли у программистов спокойные условия для работы.
И дальше шло объяснение, которое мне особенно запомнилось. Джоэл писал о состоянии глубокой концентрации, когда человек полностью погружается в задачу. По приведённой им оценке, в среднем требуется около 15 минут, чтобы выйти на максимальную продуктивность. А выбить человека из этого состояния очень легко: телефон, шум, коллега с вопросом. Даже минутное отвлечение может привести к тому, что программист будет потом ещё до получаса возвращаться к нормальной работе.
Для программиста эта мысль особенно понятна. Когда пишешь программу, в голове одновременно находится множество вещей: текущая функция, состояние переменных, структура данных, предыдущий участок кода, что вызывается дальше, где может возникнуть ошибка. Ты не просто печатаешь текст — ты некоторое время строишь у себя в голове модель работающей системы.
И тут кто-то подходит: «Слушай, на минутку...»
Минута заканчивается быстро, а модель в голове приходится собирать заново.
Потом Джоэл пошёл ещё дальше
В 2001 году он написал отдельную статью Human Task Switches Considered Harmful — о стоимости переключения между задачами. Там речь шла уже не только о том, что программиста отвлекли разговором.
Джоэл писал о ситуации, когда разработчику одновременно дают несколько полноценных задач и постоянно переключают его между ними. По его собственному ощущению, переключение между двумя крупными программными проектами могло стоить ему около шести часов. Его управленческий вывод был довольно радикальным: хороший менеджер должен помогать человеку сосредоточиться на одной задаче, а не постоянно подбрасывать следующую.
Но лично на меня сначала повлияла более простая версия этой идеи: не трогайте программиста, когда он программирует.
И у меня как раз были идеальные условия, чтобы проверить её на практике.
Один программист и много офицеров
В то время я работал над контрактом Министерства обороны. Программист был один — я. А офицеров вокруг было много, причём мы все находились в одном помещении.
Это имело совершенно предсказуемое последствие. Если в программе требовалось что-то изменить, кто-нибудь находил ошибку или просто замечал что-то, что ему хотелось поправить, все считали своим долгом сразу подойти ко мне и об этом сообщить.
Для человека, который сообщает об ошибке, всё выглядит совершенно логично: он увидел проблему, до программиста идти три метра, почему бы не сказать прямо сейчас? Один подошёл, потом второй, третьему тоже нужно уточнить. Каждый отнимает пять минут, и вроде бы ничего страшного не произошло.
Но программировать при этом практически невозможно. Проблема была не в количестве минут разговора, а в постоянном разрушении того состояния, в котором я находился до разговора.
И тут появился Джоэл
Когда я прочитал объяснение Спольски, у меня наконец появился хороший аргумент. Это уже было не просто «не мешайте мне работать». Можно было объяснить, почему именно не надо мешать.
Я донёс эту мысль до всех и установил довольно простое правило: если я сижу за компьютером — меня не трогать. Когда встану — пожалуйста. Хотите рассказать об ошибке, предложить изменение, что-то обсудить — без проблем, но не в тот момент, когда я сижу и программирую.
И удивительно, но это сработало. Меня действительно перестали трогать.
Для работы одного программиста в комнате, полной людей, это оказалось огромным изменением. Никакой новой методологии разработки, никакой сложной системы управления — просто окружающие начали понимать, что человек, который молча смотрит в монитор, в этот момент не обязательно бездельничает. Возможно, именно сейчас происходит самая сложная часть его работы.
Конечно, потом мы этим немного пользовались
Надо признаться и в другой стороне этой истории. Когда программисты получили такой аргумент, он оказался очень удобным: сидишь за компьютером — священная территория, не трогать.
А действительно ли именно в этот момент ты находишься на пятом уровне концентрации и решаешь невероятно сложную алгоритмическую задачу — это уже другой вопрос. Иногда мы, конечно, этим пользовались.
Но сама идея от этого неправильной не стала. Программист действительно работает иначе, чем человек, которому можно прервать одну беседу, провести другую, а потом продолжить первую с того же места. Чем сложнее система, тем больше времени требуется, чтобы восстановить её состояние у себя в голове.
Прошло четверть века
Интересно посмотреть на эту мысль сейчас. В начале 2000-х главным врагом Джоэла был коллега, который подошёл к твоему столу.
Сегодня всё гораздо эффективнее. Чтобы отвлечь программиста, человеку даже не нужно вставать со своего места: есть Telegram, почта, мессенджеры компании, система задач, уведомления Git, созвоны, телефон и браузер, где одновременно открыто сорок вкладок.
Мы автоматизировали почти всё — в том числе способы не давать человеку сосредоточиться.
А потом появился ИИ
На первый взгляд кажется, что ИИ должен решить проблему. Теперь не нужно идти спрашивать коллегу, как работает функция или почему возникает ошибка: можно спросить ИИ. И это действительно уменьшает часть внешних отвлечений.
Но появился новый вид переключения. Современный разработчик может одновременно попросить ИИ исправить ошибку в одном модуле, сгенерировать тесты для второго, посмотреть архитектуру третьего и, пока всё это выполняется, открыть четвёртую задачу.
Технически это выглядит как увеличение производительности. Но человеческая голова от этого не получила четыре дополнительных процессора. Когда ИИ возвращает четыре результата, всё равно человеку приходится понять каждый из них, восстановить контекст задачи и решить, что делать дальше.
Поэтому проблема, о которой Джоэл писал четверть века назад, никуда не исчезла. Она просто изменила форму: раньше нас переключал начальник, теперь мы прекрасно умеем переключать себя сами.
ИИ особенно повышает цену концентрации
Есть ещё один парадокс. ИИ ускоряет написание кода, а значит, всё большая часть ценности программиста находится не в скорости набора символов.
Главной становится способность понять задачу, удерживать архитектуру системы, сформулировать ограничения, проверить результат и заметить ошибку. То есть именно та часть работы, которая требует концентрации.
Можно очень быстро получить тысячу строк кода. Но если человек каждые пять минут переключается между задачами, наличие ИИ не гарантирует, что он понимает, какую систему в итоге строит.
Я бы даже сказал, что в эпоху ИИ рекомендация Джоэла становится важнее: защищать нужно уже не время написания кода, а время мышления.
Что осталось от совета Джоэла
За четверть века изменилось почти всё: компьютеры, языки, средства разработки, методологии, системы контроля версий, облачная инфраструктура. Теперь ещё и ИИ пишет код вместе с нами.
Но человек по-прежнему не умеет мгновенно загрузить в голову большой программный проект после каждого уведомления. Поэтому одна из идей Joel on Software пережила все эти изменения практически без потерь.
Если программист действительно погрузился в сложную задачу, не надо подходить к нему «на минутку». Эта минута может оказаться гораздо длиннее, чем кажется.
Мне эта мысль когда-то практически помогла. Я просто сказал окружающим: если сижу за компьютером — не трогайте. Встану — пожалуйста.
И они перестали меня трогать.
Ну а то, что потом мы, программисты, иногда пользовались этим правилом немного шире необходимого, — это уже совсем другая история.
Share
