Фокус: помодоро, deep work и защита от прерываний
В предыдущей статье мы поставили в календарь блоки под сосредоточенную работу. Но блок в календаре — это только заявка на внимание. Между заявкой и реальной работой стоят: Slack, ревью, дежурство, коллега с «на минутку», собственная привычка проверить почту после падения теста и физиология, из-за которой сорок минут подряд на одной абстракции — это не бесплатно.
Эта статья — про механику фокуса. Что происходит с головой инженера в первые пятнадцать минут задачи и почему их так легко потерять. Что реально доказано про помодоро (меньше, чем вам продают). Что такое deep work как гипотеза, а не как бренд. И, главное, — какие конкретные договорённости, настройки и привычки снижают число дорогих прерываний, потому что в одиночку победить среду разработки нельзя.
Почему у программиста фокус дороже, чем у большинства профессий
Работа инженера имеет три свойства, которые вместе делают прерывания непропорционально дорогими.
Контекст большой и целиком лежит в рабочей памяти. Чтобы менять код, нужно одновременно удерживать: текущее состояние ветки, инвариант, который вы чините, три места вызова, которые придётся поправить, гипотезу о причине бага и то, что вы уже проверили. Ничего из этого не записано. Это не «мысль», это граф в голове, который собирается медленно и рассыпается быстро.
Прогресс нелинеен. Первые двадцать минут вы не производите видимого результата — вы восстанавливаете модель системы. Отдача начинается после. Значит, час, разрезанный пополам, даёт заметно меньше половины: вы дважды платите за вход.
Прерывания приходят из системы, которая не знает о вашем состоянии. CI, алерты, чужие пулл-реквесты, дежурство. Это не отсутствие дисциплины — это дизайн среды.
Есть измерения. Chris Parnin и Spencer Rugaber в работе «Resumption strategies for interrupted programming tasks» проанализировали более 10 000 сессий в IDE и обнаружили, что после прерывания программист в большинстве случаев тратит 10–15 минут до первого содержательного редактирования кода, и лишь около 10 % возвращений происходят быстрее чем за минуту (PDF). Полевые наблюдения Gloria Mark с коллегами дали смежные цифры для офисной работы в целом: средний рабочий фрагмент — около 11 минут до переключения («No Task Left Behind?», CHI 2005, PDF), а возврат к исходной задаче после прерывания занимает в среднем 23 минуты 15 секунд («The Cost of Interrupted Work», CHI 2008, PDF).
Важная деталь, которую часто выкидывают из пересказов: в исследовании 2008 года прерванные задачи в итоге завершались быстрее, но ценой более высокого стресса, спешки и нагрузки. Люди компенсируют фрагментацию, ускоряясь и работая небрежнее. Это ровно та валюта, которой инженер платить не хочет: скорость набора текста растёт, качество решений падает.
Ещё один механизм — attention residue. Sophie Leroy показала, что при переключении между задачами часть внимания остаётся привязанной к предыдущей задаче, особенно если та не была завершена или не имела ясного плана окончания («Why is it so hard to do my work?», OBHDP 2009, DOI). Практический вывод из её же более поздних работ: остаток внимания заметно меньше, если перед переключением человек формулирует конкретный план возврата. Это ровно то, что мы ниже превратим в привычку «закладки».
Краткая история идей о фокусе
Обратите внимание: серьёзные измерения (Марк, Парнин, Цюгер) появились уже после того, как популярные методы (помодоро, deep work) были сформулированы. Методы не выведены из данных — данные пришли позже и подтвердили не всё.
Помодоро: честный разбор
Происхождение
Франческо Чирилло придумал технику в конце 1980-х, будучи студентом: взял кухонный таймер в форме помидора и поспорил с собой, что продержится за учебником 10 минут. Позже техника оформилась в книгу и коммерческий продукт (francescocirillo.com). Ядро — не «25 минут», а договор с самим собой: помидор либо звенит целиком, либо не считается вообще.
Механика
Три правила, которые чаще всего теряют при пересказе и без которых техника вырождается в таймер:
- Помидор неделим. Прервали — помидор аннулируется, а не «ставится на паузу». Это создаёт психологическую цену прерывания, а не только временную.
- Прерывания записываются. Внутренние («надо посмотреть, вышел ли релиз») — штрихом в блокноте, чтобы к концу недели у вас была статистика собственных отвлечений. Внешние — с пометкой, кто и зачем.
- Оценка в помидорах. Задача планируется как «3 помидора», и вечером вы сравниваете план с фактом. Это единственный дешёвый способ научиться оценивать: вы калибруете себя на единице длиной 25 минут, а не на абстрактных «полдня».
Что реально доказано
Прямых рандомизированных испытаний именно схемы 25/5 практически нет. То, на что обычно ссылаются, — про соседние явления.
- Микроперерывы работают, но скромно. Метаанализ Albulescu и соавторов «Give me a break!» (PLOS ONE, 2022) по 22 исследованиям показал значимый положительный эффект коротких перерывов (до 10 минут) на самочувствие и умеренный, зависящий от типа задачи, — на производительность; на когнитивно тяжёлых задачах эффект на результат слабее (DOI).
- Спад внимания реален, и переключение цели его снимает. Ariga и Lleras (Cognition, 2011) показали, что короткие отвлечения на другую цель восстанавливают точность на длинной монотонной задаче (DOI). Но их задача — 50 минут монотонного мониторинга, а не написание кода.
- Фиксированные перерывы могут быть хуже саморегулируемых. Biwer и соавторы сравнивали помодоро-перерывы и перерывы «когда сам решил» у студентов и не нашли преимущества жёсткого расписания; жёсткие перерывы иногда прерывали продуктивное состояние (British Journal of Educational Psychology, 2023, DOI).
- Эффект Зейгарник, которым объясняют «тягу вернуться», воспроизводится плохо. Оригинальная работа 1927 года многократно не реплицировалась в чистом виде; современное объяснение ближе к Лерой: незакрытое намерение занимает внимание, если нет плана его закрыть.
Вывод честный: помодоро — это не оптимизированный под нейрофизиологию протокол, а хорошая дисциплинарная обёртка. Его сила в трёх вещах: понижает барьер старта, делает прерывания видимыми, даёт единицу для оценки. Никакой магии в числе 25 нет.
Где помодоро ломается у инженера
| Ситуация | Что происходит | Что делать |
|---|---|---|
| Задача требует 40–90 минут удержания графа в голове | Таймер звенит ровно на плато, перерыв стоит дороже, чем даёт | Увеличить помидор до 45–90 минут или отказаться от таймера в этом блоке |
| Сборка/тесты идут 6 минут | Внутри помидора появляется вынужденная пауза | Не считать это прерыванием; заранее держать «холодный» пункт (ревью абзаца, чтение доки) на время сборки |
| Дежурство | Помидор аннулируется по чужому расписанию | В дежурные дни помодоро не применять: техника предполагает контроль над входящим потоком |
| Парное программирование / mob | Ритм задают двое | Договориться о ритме явно (популярно 25/5 именно здесь — таймер помогает ротации) |
| Ревью пулл-реквестов | Естественная длительность 10–20 минут на PR | Помидор как батч: «два помидора на очередь ревью», а не таймер на каждый PR |
Практический компромисс, который я видел работающим чаще всего: помодоро для входа, длинные блоки для работы. Когда не хочется начинать — ставите 25 минут, потому что 25 минут не страшно. Когда вошли и чувствуете, что идёт, — таймер отключаете и работаете до естественной точки остановки или до жёсткой границы календаря.
Deep work: полезная гипотеза, слабая доказательная база
Кэл Ньюпорт в «Deep Work» (2016) формулирует гипотезу глубокой работы: способность к длительной концентрации становится и всё более редкой, и всё более ценной, поэтому те, кто её сохранил, получают непропорциональное преимущество (calnewport.com). Книга — публицистика, а не исследование: аргументация построена на биографиях и рассуждении, контролируемых испытаний «глубокой работы» как вмешательства нет.
Что в книге ценно операционально:
- Разделение на deep и shallow. Полезная классификация: shallow work — то, что может выполнить сообразительный человек без вашего контекста после короткого обучения. Ревью типового PR — часто shallow. Проектирование схемы миграции без даунтайма — deep. Считать долю shallow в неделе полезно даже без всякой философии.
- Четыре режима планирования глубины: монастырский (полная изоляция, для инженера в команде нереалистичен), бимодальный (дни глубины / дни коммуникации — это day theming из статьи про календарь), ритмический (каждый день в одно и то же время — самый устойчивый), журналистский (ловить окна по ситуации — требует натренированного навыка входа).
- Ритуал завершения дня. Явная точка «работа закончена», после которой открытые петли записаны и голова отпущена. Это, пожалуй, самая эмпирически подкреплённая часть — она смыкается с attention residue.
Что стоит держать в уме как критику:
- Ньюпорт опирается на deliberate practice Эрикссона (Ericsson, Krampe, Tesch-Römer, 1993, DOI), включая наблюдение, что элитные исполнители работают сессиями по 60–90 минут и редко больше 4 часов в день. Но метаанализ Macnamara, Hambrick и Oswald (Psychological Science, 2014) показал, что осознанная практика объясняет заметно меньшую долю различий в результатах, чем утверждалось, — около 26 % в играх, 21 % в музыке, 18 % в спорте и всего ~4 % в профессиях (DOI). Профессиональная деятельность — как раз худший случай для этой теории.
- Норма «4 часа глубокой работы в день» — это наблюдение о скрипачах и шахматистах, а не закон физиологии. Ваша личная норма может быть 2 часа или 6, и она меняется с неделей, сном и стадией проекта.
- Deep work легко превращается в моральную рамку: «мало сфокусировался — плохо старался». Это ошибка, и ниже, в разделе про устойчивость, мы к ней вернёмся.
Про поток
Состояние потока (Чиксентмихайи, 1975/1990) — не то же самое, что deep work. Поток описывается условиями: ясная цель, немедленная обратная связь, баланс сложности и навыка. Программирование почти идеально подходит под эти условия — отсюда популярность идеи в индустрии.
Практическое ограничение: поток нельзя запланировать, можно только не мешать. Данные о нём в основном получены методом выборки переживаний (испытуемых пингуют и спрашивают, что они чувствуют) — это самоотчёт со всеми его проблемами. Так что «войти в поток» — плохая цель на день. Хорошая цель: «сегодня есть два окна по 90 минут, в которые никто не имеет права меня дёрнуть».
Таксономия прерываний
Не все прерывания одинаковы. Разделять их — первый шаг к тому, чтобы не бороться со всеми сразу.
По источнику: внешние (человек, алерт, встреча) и внутренние (собственный импульс переключиться). Полевые исследования показывают, что внутренних — примерно половина, а в некоторых замерах и больше. Это важно: половину проблемы нельзя решить настройками Slack.
По управляемости: отложимые и неотложимые. Падение прода неотложимо. «Глянь, пожалуйста, PR» — отложимо почти всегда, хотя воспринимается как срочное.
По цене возврата: дешёвые (вы писали документ) и дорогие (вы держали в голове состояние распределённой транзакции).
Ключевая ошибка — отвечать на всё по оси X (срочность) и игнорировать ось Y. Именно ось Y отличает инженера от менеджера: у менеджера почти всё в нижней половине, у инженера в разгар отладки — почти всё в верхней. Отсюда, кстати, знаменитое эссе Пола Грэма «Maker’s Schedule, Manager’s Schedule» (paulgraham.com): одна встреча в середине дня у «делателя» рушит не час, а половину дня, и это не преувеличение, а прямое следствие стоимости входа.
Защита: что делать конкретно
Дальше — практика, разложенная по слоям. Работает только вместе: индивидуальные приёмы без командных договорённостей выгорают за две недели.
Слой 1. Командные договорённости
Это самый эффективный слой и самый игнорируемый, потому что он требует разговора, а не установки приложения.
- SLA на ревью вместо мгновенности. Договорённость вида «PR получает первое ревью в течение рабочего дня» превращает ревью из прерывания в плановую работу. Практика: два окна в день (например, 11:30 и 16:30) по 30–40 минут, всё остальное время очередь ревью не трогается. Полезно измерять не «время ответа в минутах», а долю PR, получивших ревью в рамках SLA.
- Общее «тихое окно» команды. Полоса, в которую не назначаются встречи и не ожидается онлайн-реакция. Кросс-командно это работает лучше, чем индивидуально: если у соседей стендап в 11:00, ваш личный тихий слот в 11:00 бесполезен.
- Асинхронность по умолчанию. Вопрос сначала письменно в тред с полным контекстом, синхронный созвон — эскалация после того, как асинхронный обмен не сработал. Публичный пример подробно описанного процесса — handbook GitLab по асинхронной работе. Подробнее — в статье про встречи.
- Явная роль «дежурного по прерываниям». В командах, где много входящего от других отделов, помогает ротация: один человек в неделю принимает на себя вопросы, остальные защищены. Этот человек в свою неделю не берёт задач, требующих глубины, — и это нормально, планируется заранее.
- Индикатор занятости. Züger и соавторы в полевом эксперименте FlowLight (CHI 2017, DOI) повесили в офисах физические лампы, автоматически отражающие занятость по активности клавиатуры и мыши; число прерываний снизилось примерно на 46 %, и большинство участников продолжили пользоваться устройством после эксперимента. Дешёвый аналог — статус в мессенджере с временем окончания блока, наушники как явно оговорённый сигнал, эмодзи в имени канала.
Слой 2. Календарь и структура дня
Смысл нижней дорожки: в дежурный день глубокая работа не планируется вообще. Это не потеря, а честный учёт. Самая частая причина ощущения «день прошёл, ничего не сделал» — попытка воткнуть глубокую задачу в день, структурно к ней не приспособленный. Планируйте туда работу, устойчивую к разрезанию: документация, мелкие багфиксы, чистка бэклога, ответы на вопросы, обновление зависимостей.
Дополнительные правила, которые дёшево внедрить:
- Один глубокий блок в день, а не четыре. Реалистичная цель для человека внутри команды — 1–2 блока по 90 минут. Четыре — это либо очень зрелая среда, либо самообман.
- Блок ставится на пик энергии, а не на «когда осталось место». См. статью про внимание и энергию.
- Буфер после встреч. 10 минут после созвона на запись решений — иначе они всплывут внутри следующего блока фокуса.
- Правило «встречи справа». Все встречи в постоянные полосы (например, после 15:00), утро отдано глубине. Это бимодальный режим Ньюпорта на практике.
Слой 3. Личные привычки и техника
Закладка перед прерыванием. Ключевой приём, прямо следующий из работ Лерой и Парнина. Когда вас прерывают, у вас есть 20–40 секунд, чтобы сделать возврат дешёвым. Что записать:
## resume (2026-07-16 14:32)
Чиню: дубли в `OrderProjector` при ретрае консьюмера.
Гипотеза: idempotency key берётся из payload, а не из message id.
Проверено: ретраи действительно идут (лог kafka-consumer, 14:20), ключ совпадает.
Дальше: посмотреть `ProjectionStore.upsert`, строка ~180, есть ли upsert по (aggregate_id, version).
Открыто: 3 вкладки — jira ORD-4412, PR #881, доки exactly-once.
Такой файл живёт в корне репозитория (в .gitignore) или в дневной заметке. Разница между «вернулся за 15 минут» и «вернулся за 2» — вот эти пять строк.
Технические закладки в коде. Оставляйте состояние, которое само расскажет, где вы были:
# незавершённая работа фиксируется явно, но не попадает в историю ветки
git add -A && git commit -m "wip: idempotency в проекторе, см. resume.md" --no-verify
# альтернатива, если коммит не хочется
git stash push -m "wip idempotency ORD-4412"
Классический приём — оставить падающий тест. Уходя на прерывание, вы пишете тест, который падает ровно там, где вы остановились. Вернувшись, запускаете тесты и мгновенно оказываетесь в нужной точке. Это дешевле любых заметок, потому что закладка исполняемая.
Парковка внутренних импульсов. Импульс «а не проверить ли почту» — это чаще всего не желание почты, а сигнал о незакрытой петле («не забыть написать Ане про миграцию»). Держите под рукой файл-инбокс и записывайте туда одной строкой, не переключаясь. Механика подробно разобрана в статье про сбор задач.
Скрипт входа в режим. Ритуал важнее содержания: повторяемая последовательность действий сама становится сигналом «начинаем». Пример для Linux:
#!/usr/bin/env bash
# focus.sh — вход в блок глубокой работы
set -euo pipefail
MINUTES="${1:-90}"
# 1. Тишина: системные уведомления off (GNOME)
gsettings set org.gnome.desktop.notifications show-banners false
# 2. Отсечь самые дорогие источники отвлечения на уровне hosts
sudo cp /etc/hosts /etc/hosts.bak
printf '127.0.0.1 news.ycombinator.com\n127.0.0.1 www.reddit.com\n' | sudo tee -a /etc/hosts >/dev/null
# 3. Явно сказать команде, до какого времени вас нет
END=$(date -d "+${MINUTES} minutes" +%H:%M)
echo "статус: фокус до ${END}" # сюда же — вызов slack API, если настроен токен
# 4. Открыть заметку возврата
${EDITOR:-vim} resume.md
# 5. Таймер
sleep "$((MINUTES * 60))"
# 6. Откат
sudo mv /etc/hosts.bak /etc/hosts
gsettings set org.gnome.desktop.notifications show-banners true
notify-send "Блок закончен" "Запиши, где остановился, и сделай перерыв"
Не переоценивайте блокировщики. Блокировка сайтов помогает только против привычки-автоматизма; против настоящего избегания сложной задачи она бесполезна — вы найдёте другой способ. Про это подробно в статье о прокрастинации.
Перерыв должен быть перерывом. Скроллинг ленты в паузе не восстанавливает — он нагружает ту же систему. Работают: движение, вода, взгляд вдаль, короткая прогулка, ничегонеделание. Метаанализ по микроперерывам (Albulescu et al.) фиксирует эффект в первую очередь на самочувствии, и это уже достаточная причина.
Слой 4. Уведомления и инструменты
Тонкая настройка уведомлений — тема отдельной статьи (информационная гигиена), здесь только минимум, без которого остальное не работает:
- В телефоне и десктопе оставить пробивающими тишину только алерты дежурства и звонки от узкого списка людей.
- Убрать бейджи с непрочитанным: они превращают любой взгляд на экран в микропрерывание.
- Отписаться от автоматических уведомлений трекера про чужие тикеты; оставить только явные упоминания и назначения.
- IDE: выключить всплывающие подсказки о новых версиях, «советы дня» и уведомления плагинов.
- Почта и мессенджер закрыты во время блока, а не свёрнуты. Свёрнутое окно с бейджем — это отложенное прерывание.
Как измерять, не превращая это в самонадзор
Соблазн — считать помидоры и строить графики. Проблема в том, что счётчик помидоров быстро становится целью: вы начинаете выбирать задачи, которые хорошо ложатся в 25 минут, и избегать тех, что требуют трёх часов и не дают «зачётов».
Метрики, которые не деформируют поведение:
| Метрика | Как снимать | Что показывает |
|---|---|---|
| Число дней в неделе с хотя бы одним блоком 90+ минут без прерываний | Галочка в дневной заметке | Основной сигнал: среда позволяет работать или нет |
| Число внешних прерываний за блок | Штрих на полях | Нужен ли разговор с командой, а не с собой |
| Число внутренних прерываний за блок | Штрих другого цвета | Что чинится личными привычками |
| Доля недели в shallow work | Грубая оценка вечером пятницы | Смещается ли роль в сторону координации |
| Ретроспективная оценка «удалось ли продвинуться» | Одна строка вечером | Субъективно, но коррелирует с реальностью лучше, чем счётчик часов |
Меряйте не больше двух недель подряд. Цель замера — поставить диагноз и изменить договорённости, а не вести бесконечный журнал. Постоянный самомониторинг сам становится источником прерываний и тревоги.
Отдельно: не сравнивайте себя с чужими цифрами. Meyer и соавторы, замеряя реальные рабочие дни разработчиков, показали, что типичный день сильно фрагментирован и наполнен переключениями даже у продуктивных инженеров («The Work Life of Developers», IEEE TSE 2017, DOI). Их же более раннее исследование восприятия продуктивности (FSE 2014, DOI) обнаружило, что ощущение продуктивного дня связано прежде всего с завершением значимых задач и малым числом переключений, а не с количеством часов.
Типичные ошибки
- Считать фокус вопросом воли. Если вас прерывают восемь раз в день из-за организации процессов, никакая техника не поможет. Начинайте со слоя договорённостей, а не с приложения-таймера.
- Мгновенно отвечать на всё, потому что «команда ждёт». Проверьте: чаще всего никто не ждёт, просто никто не договорился о нормальном времени ответа. Отсутствие явного SLA всегда читается как «немедленно».
- Планировать четыре блока глубокой работы в день. План не выполняется, вы делаете вывод, что «нет дисциплины». На самом деле вы просто ошиблись в модели.
- Использовать помодоро в дежурство. Техника предполагает контроль над входящим потоком; в дежурство его нет по определению.
- Гнаться за потоком как целью. Поток — побочный продукт условий, а не результат усилия. Ставьте задачи на условия.
- Экономить на перерывах. Три часа подряд без паузы обычно означают, что последний час вы производили код, который завтра будете переписывать.
- Не оставлять закладку. Самая дорогая привычка из всех: вы платите 10–15 минут за каждый возврат, хотя могли бы платить одну.
- Настроить идеальную систему и не поговорить с тимлидом. Тихое окно, зафиксированное в командном календаре, стоит больше, чем весь ваш личный тулинг.
- Считать shallow work злом. Ревью, менторство, ответы джунам — это работа, а не помеха работе. Вопрос в их доле и в том, батчатся ли они.
Фокус и устойчивость: где проходит граница
Есть версия «фокуса», которая на самом деле является выжиманием: четыре блока по 90 минут, режим без пауз, самообвинения за «слабый» день. Здесь важно сказать прямо: способность к концентрации — это состояние, а не черта характера. Она падает при недосыпе, тревоге, болезни, перегрузке, конфликте в команде, неопределённости на проекте. Это нормальная физиология и нормальная реакция на среду.
Если сосредоточиться не получается неделями подряд, если раньше знакомая работа стала вызывать отвращение, если утром нет сил на то, что вчера было интересным, — это не сигнал «взять более жёсткий таймер». Это сигнал посмотреть на нагрузку, режим и, при необходимости, обратиться к специалисту. Выгорание — организационное и медицинское явление, а не дефицит дисциплины; ВОЗ описывает его как синдром, связанный с хроническим рабочим стрессом (ВОЗ, 2019). Мы разбираем это отдельно и подробно в статье про выгорание и устойчивый темп.
Техники из этой статьи — способ тратить внимание там, где оно важно, а не способ добывать из себя больше внимания, чем есть.
Мини-итог
- Цена прерывания для программиста измерена: 10–15 минут до первого содержательного действия в коде, порядка 23 минут до полного возврата к задаче. Это делает арифметику «поработаю между встречами» ложной.
- Помодоро — дисциплинарная обёртка, а не физиологический протокол. Его ценность: барьер входа, видимость прерываний, единица оценки. Число 25 не священно; фиксированные перерывы не всегда лучше саморегулируемых.
- Deep work — полезная классификация и полезные режимы планирования, но слабая доказательная база; норма «4 часа» — наблюдение о музыкантах, а не закон.
- Поток нельзя запланировать, можно только создать условия и не мешать.
- Половина прерываний — внутренние; их лечат парковкой мыслей, а не настройками мессенджера.
- Самый мощный рычаг — командные договорённости: SLA на ревью, тихие окна, асинхронность по умолчанию, честное планирование дежурных дней.
- Закладка перед прерыванием (заметка возврата, WIP-коммит, падающий тест) — самая дешёвая и самая недооценённая привычка.
- Меряйте дни с блоками 90+ минут и число прерываний, а не помидоры. Меряйте недолго, чтобы поставить диагноз.
Источники
- Chris Parnin, Spencer Rugaber. Resumption strategies for interrupted programming tasks. Software Quality Journal, 2011. PDF
- Gloria Mark, Victor González, Justin Harris. No Task Left Behind? Examining the Nature of Fragmented Work. CHI 2005. PDF
- Gloria Mark, Daniela Gudith, Ulrich Klocke. The Cost of Interrupted Work: More Speed and Stress. CHI 2008. PDF
- Sophie Leroy. Why is it so hard to do my work? The challenge of attention residue. OBHDP, 2009. DOI
- Patricia Albulescu et al. «Give me a break!» A systematic review and meta-analysis on the efficacy of micro-breaks. PLOS ONE, 2022. DOI
- Atsunori Ariga, Alejandro Lleras. Brief and rare mental «breaks» keep you focused. Cognition, 2011. DOI
- Felicitas Biwer et al. Understanding effort regulation: Comparing «Pomodoro» breaks and self-regulated breaks. BJEP, 2023. DOI
- Brooke Macnamara, David Hambrick, Frederick Oswald. Deliberate Practice and Performance: A Meta-Analysis. Psychological Science, 2014. DOI
- Manuela Züger et al. Reducing Interruptions at Work: A Large-Scale Field Study of FlowLight. CHI 2017. DOI
- André Meyer et al. The Work Life of Developers: Activities, Switches and Perceived Productivity. IEEE TSE, 2017. DOI
- Tom DeMarco, Timothy Lister. Peopleware: Productive Projects and Teams. 1987.
- Cal Newport. Deep Work. 2016. calnewport.com
- Paul Graham. Maker’s Schedule, Manager’s Schedule. 2009. paulgraham.com
Что дальше
Мы научились защищать блоки внимания. Но защищённый блок бесполезен, если в работе одновременно висят семь начатых задач: тогда каждый блок начинается с вопроса «а чем я сейчас занимаюсь». Следующий шаг — ограничить количество одновременной работы явно.