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

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

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

Стоимость отвлечения можно изучить наблюдая за работой в офисе. Задача, во время которой работника отвлекали, занимает в два раза больше времени и содержит в два раза больше ошибок по сравнению с задачей, во время которой работника не беспокоили. При этом, обычно работники работают в режиме переключения между задачами и 57% задач выполняются с переключение внимания работника.

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

Отвлечь программиста

На основании анализа 10 000 записей наблюдения за 86 программистами и опросов 414 разработчиков мы обнаружили, что:

  • Разработчику требуется от 10 до 15 минут на то, чтобы вернуться к работе после того, как его отвлекли
  • Если отвлечь разработчика во время редактирования метода, то только 10% разработчиков могут возобновить работу в течении минуты
  • Обычно в течении дня у разработчика бывает только один двух часовой период без того, чтобы его отвлекли Мы также обратили внимание на несколько моментов, как разработчики возвращаются к работе:
  • Большинство разработчиков просматривают несколько различных мест в коде, чтобы восстановить ситуацию
  • Разработчики часто вставляют вызов ошибки в то место на котором они остановились, до того как их прервали
  • Выполнение diff кода помогает получить все изменения, но не помогает восстановить ситуацию

Худшее время, чтобы отвлечь программиста

Исследования показывают, что хуже всего, когда разработчика отвлекают в момент максимально интенсивной работы мозга. Для определения интенсивности работы мозга использовался метод пуппилометрии (основанный на корреляции работы мозга с величиной зрачка). Благодаря этому мы смогли определить различные уровни мозговой активности во время решения проблемм: Активности мозга разработчика

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

  • Во время редактирования кода, особенно если оно осуществляется в нескольких местах
  • При навигации и поиске в коде
  • При обдумывании и понимании рабочего процесса программы
  • Если окно IDE не в фокусе

Минимизация последствий

Окружение

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

Будущая память

Будущая память содержит в себе напоминание о будущих действиях и их порядке, например купить молоко по пути домой.

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

Умное напоминание - это напоминание которое срабатывает только при каком-то условии, например во время ревью кода или по таймеру. Для создания умных напоминаний я создал расширения для Chrome pm, которое позволяет привязать умное напоминание к определенному url, и расширение для Visual Studio attachables, которое позволяет привязать todo к умным напоминаниям в редакторе:

Умное напоминание в Chrome Умное напоминание в Visual Studio

Внимательная память

Внимательная память - это сознательная память воспоминания из которой могут быть легко извлечены.

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

Ассоциативная память

Ассоциативная память - это память которая содержит список связей между различными объектами.

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

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

Ассоциативные связи помогают разработчикам проще ориентироваться в ситуации и улучшают читабельность текста: Стиль написания программы

Короткая память

Короткая память содержит список последних событий.

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

Комментарии и подсказки помогают разработчикам вспомнить контекст с которым он работал. 1

Абстрактная память

Абстрактная память - это что-то среднее между непосредственными восприятиями и абстракциями. Как мозг запоминает такие вещи, как молоток, или концепцию, как инструмент? Вначале, мозг запоминает отдельные черты объекта (например форму и материал из которого делаются гвозди), а потом объединяет это в одну абстрактную модель.

Разработчикам необходимо постоянно поддерживать актуальность своих знаний. К сожалению, это достаточно сложный процесс:

  • для того чтобы стать экспертом в технологии требуется поработать порядка 10 000 часов
  • кроме того, даже если вы экперт в одной области, при переходе в другую вам придется изучить множество новых концепций.

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

Sketchlets помогает разработчикам выделять абстракции и обновлять восспоминания, когда это потребуется:

2

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