Представьте, что вы сосредоточили свое внимание на карточной башне, а прерывания ее сбивали. Если бы ваша продуктивность зависела от карточной башни, разве вы не расстроились?
Я слышал эту аналогию от своего друга несколько лет назад. Я повторил аналогию для быстрого визуального сосредоточения, и мне это всегда нравилось, поэтому я обратился к своему другу, чтобы узнать, есть ли у него источник.
Если вы когда-либо пытались построить карточную башню, вы знаете, сколько времени может потребоваться, чтобы сбалансировать карты и контролировать окружающую среду вокруг вас. Особенно неприятно, когда ваш друг закрывает дверь и вызывает порыв ветра, который каким-то образом находит прямой путь к вашей карточной башне.
Как и в случае с карточными башнями, разработчик тщательно выстраивает фокус, объединяет несколько элементов вместе и может быть легко разрушен.
Кодирование требует большого мышления. Некоторые дни лучше, чем другие, но цель каждого дня — достичь потока или состояния абсолютной сосредоточенности.
Также известный как «зона», поток — это ментальное состояние работы, в котором программист погружается в чувство энергичной сосредоточенности, полной вовлеченности и удовольствия в процессе кодирования. Поток — это не уникальная концепция компьютерного программирования, но разработчики программного обеспечения хорошо с ней знакомы.
— CoderHood 15 лучших способов добиться потока
Когда я нахожусь в потоке, я хочу, чтобы он оставался таким как можно дольше. Это не магия вуду или что-то в этом роде, но приятно полностью погрузиться в свою работу.
Многие по-разному относятся к потоку, но общая идея заключается в том, что это период времени, когда происходит ваша лучшая работа. Взгляните на некоторые из лучших результатов поиска в Google по запросу «поток достижения программного обеспечения» и убедитесь в этом сами. Вы найдете: Важность потока в разработке программного обеспечения, Как попасть в состояние потока | Станьте производительным ЗВЕРЬОМ !, и поток в гибкой разработке программного обеспечения: что, почему и как.
В статьях рассказывается о том, что поток — это период времени, когда вы добиваетесь своих лучших результатов. По моему опыту, это не обязательно, когда я работаю лучше всего; это может быть единственная работа, которую я выполняю за день.
Чтобы получить поток, требуется сосредоточенность, и это сложный предмет. Факторы, влияющие на поток, могут варьироваться от того, сколько я выспался, была ли работа достаточно сложной или слишком сложной, моей зарплаты, видения компании, вплоть до того, нравятся ли мне мои коллеги или нет.
Чтобы немного упростить поток, я решил сузить его до процесса сбора контекста (или информации) об ошибке в фрагменте кода. Сбор контекста — долгий и утомительный процесс. Чтобы проиллюстрировать это, я попытался пройти через то, что происходит во время типичного сеанса кодирования. Все начинается со строительства Башни Фокуса.
Башня имеет фундамент, средний ярус и пик. В простой трехуровневой карточной башне 15 карточек. 8 карт для основы, 5 карт для середины и 2 карты для вершины. Я назвал слои «ПОЧЕМУ», «Компромиссы» и «Проверка» соответственно.
Каждая из этих карточек является контекстом для задачи, которую я выполняю. Я строю эти слои по одной карте за раз, осторожно прислоняя их друг к другу.
Содержание статьи
База — понимание кода
Базовый уровень представляет собой поиск «почему» или первоначального намерения. На мой взгляд, это самый сложный контекст для сбора информации. Чтобы с уверенностью внести изменения в код, мне нужно выяснить первоначальное намерение, которое было вложено в него.
Так как же выглядит поиск намерения? Давайте посмотрим на фрагмент кода.
Совершенно очевидно, что первоначальный автор обнаружил кое-что, когда писал это. Я могу это сказать, потому что они поместили много строк с комментариями (строки, начинающиеся с //). Я начну задаваться вопросом, почему они приложили столько усилий для этого?
Вы удивитесь, узнав, что этот код является частью более широкой картины и любое изменение в нем может иметь непреднамеренные побочные эффекты на более высоких уровнях цепочки. (Он выполняется из набора методов и находится внутри нескольких для циклов).
Если я исследую ошибку, связанную с этим кодом, мне придется переваривать каждую строку. Имена переменных, такие как reader и n тонкие различия между каждым оператором if и т. Д. По ходу я добавляю карточку в свою башню фокуса для каждого один.
Я буду исследовать тесты, фиксировать сообщения или даже болтать с первоначальным автором (если они все еще существуют), чтобы попытаться понять, что они пытались сделать. Обнаружение первоначального намерения более или менее похоже на роль детектива в расследовании тайного убийства.
За исключением вышеизложенного, это исключение из правил. На самом деле там были комментарии … Обычно происходит то, что меня бросают в тот же код, что и выше, но без комментариев и бесполезных сообщений о фиксации. У меня действительно нет другого выбора, кроме как прочитать весь код, чтобы понять его в тройном вложенном цикле для слава цикла.
Что еще хуже, это лишь легкое испытание ставит меня на распутье. Если я его поменяю, я не пойму, устанавливаю ли я фугас, чтобы впоследствии взорвать его в самый неподходящий момент.
Я трачу много времени на улучшение тестов или просто скрещиваю пальцы, немного тестирую и двигаюсь дальше?
Каждая вещь, которую я обнаруживаю, продолжает добавлять карты к моему базовому слою моей башни фокусировки. Если код даже немного сложен, я настраиваюсь на создание 4-х или даже 5-слойной башни фокуса. В этом случае, скажем, мне нужно было только 3 треугольника или 3 слоя в целом.
Средний уровень — Компромиссы и обходные пути
Следующий уровень определяет, что нужно изменить, а что сломано, и как это можно исправить.
Продолжая рассмотрение примера исправления ошибки, я начну погружаться в то, где были напечатаны определенные сообщения журнала и в каких частях кода. Сообщение журнала можно рассматривать как свидетельство или запись поведения программы (кровь на ковре, если вы детектив). Иногда журналы отображают полную картину, но часто они неполны или отсутствуют.
Что мне нужно сделать, так это попытаться воспроизвести ошибку. Я добавлю больше сообщений журнала или воспользуюсь инструментом отладчика (способ пройти по программе по одной строке за раз). Я добавлю несколько комментариев или заметок о том, как это работает. Я могу изменить одну или две переменные, чтобы посмотреть, как это повлияет на результат работы программы. Обычно, проделывая это несколько раз, я могу сузить или выделить, какая часть кода взломана.
Если мне повезет, я получу точное воспроизведение ошибки, и этого достаточно, чтобы найти исправление, но в противном случае мне нужно указать пару компромиссов или обходных путей. Более сложные проблемы могут быть решены в разной степени, но, по сути, они сводятся к двум вариантам:
- Настоящее исправление (занимает много времени)
- Исправление (может сломаться позже, но работает очень быстро)
Чаще всего бизнес соглашается с исправлением, позволяющим быстрее решить проблему (это тема для целого сообщения в блоге в другой раз). Все это добавляет карты в мою башню, и это становится довольно уравновешивающим действием.
Пик — проверка и проверка
Последний слой проверяет, работает ли он в производстве. Производство — это просто модное слово для обозначения клиентской части программного обеспечения. Лучше всего добавить несколько тестов, но иногда подойдет пробный прогон кода на компьютере разработчика. Важная часть — продолжать, пока контекст еще свеж в вашей голове, а слои все еще накладываются друг на друга. На тот момент вы знаете больше всего о коде и о том, как его исправить, если что-то пойдет не так.
В идеальном мире я мог бы свободно переходить от базового слоя, среднего слоя, а затем к пику без перерывов. Но на самом деле мой день разбит на встречи или перерывы.
Charity Majors, технический директор Honeycomb, лучше всего говорит об этом, говоря о том, почему они практикуют «15 минут или перебор».
Если у вас есть быстрый цикл обратной связи … У вас есть то первоначальное намерение, которое свежо в вашей голове, вы точно знаете, что пытаетесь сделать: почему, все компромиссы, которые вам пришлось пойти, все имена переменных , и все. Вы никогда не получите это снова. Он начинает разлагаться сразу же, как только вы отвлекаетесь от него…
— Charity Majors, технический директор Honeycomb, The New Faces of Continuous Improvement
Представьте, что я только что потратил пару часов на постройку башни фокусировки, а потом налетает порыв ветра. Прерывание. Мне выдают вызов, чтобы помочь решить проблему X, и это очень «срочно» (в Slack @channel — это способ уведомить всех и подразумевает срочность).
@channel просто хотел сообщить вам, что мы перенесли встречу через две недели на пятницу. Обновление есть в вашем календаре
@channel so and so только что написал, что хотел бы попробовать X. Возможно ли это?
Поскольку они использовали сигнал о прибытии врага и приближении войны или известный как @channel, я чувствую, что немедленно обязан помочь.
Я бы сказал, что в 95% случаев @channel не нужен и вносит большой вклад в разрушенные башни фокусировки. Большинство вещей можно дождаться встреч поддержки или передать одному человеку, которому в этот день назначена помощь. Смены можно запланировать поочередно, чтобы распределить задачу между несколькими членами команды (проверьте Tellspin как простой способ ротации @ упоминаний в Slack).
Эти перерывы отвлекают меня от работы, и моя фокусная башня немедленно начинает разрушаться. Если меня не будет на час или больше, вы можете просто направить фен на мою башню и продуть его.
Для ясности, небольшие перерывы на несколько минут обычно допустимы. Я могу вернуться к своей задаче, не заметив этого. Однако я утверждаю, что даже после небольшого толчка существует высокий риск того, что я не вернусь к тому, что делаю. Я пойду и проверю свою электронную почту или посмотрю, что понравилось в моем твиттере. Чем больше времени потребуется, чтобы вернуться к моей первоначальной задаче, тем сильнее будет распад.
Итак, что мы можем сделать? Самое важное — знать, что прерывания не бесплатны. Вероятно, есть причина, по которой ваш коллега установил блокировку в своем календаре или установил периоды режима "Не беспокоить". Будьте добры друг к другу.
С другой стороны, я часто сам себе злейший враг, когда дело доходит до отвлекающих факторов. Я составил список вещей, на которых мне было полезно сосредоточиться.
1. Сократите перерывы в работе Slack на уровне команды
Если вы специально имеете дело с прерываниями из-за Slack, ознакомьтесь с моими советами по сокращению прерываний работы Slack для вашей команды. В нем конкретно говорится о том, как вы можете работать со своими передовыми группами поддержки, чтобы помочь распределить перебивающую нагрузку между членами вашей внутренней команды. Мой рекомендуемый совет оттуда — планировать перерывы, устанавливая график смены дежурного по вызову.
2. Создайте трение, чтобы отвлечься
Я вызвал небольшое трение, переместив мои главные отвлекающие факторы на другой рабочий стол, такой как Slack, Twitter, связанные ссылки или электронная почта, на другой рабочий стол. Всякий раз, когда у меня появляется желание взглянуть на эти вещи, мне приходится нажимать несколько клавиш, чтобы переключиться. Трение служит напоминанием о том, что я хотел сосредоточиться и отлично работает. Я также еще больше увеличил трение, свернув окно или полностью закрыв его.
3. Создайте запрещенную группу вкладок Chrome
Одна вещь, с которой я борюсь, — это постоянная проверка показателей своего бизнеса. Чтобы помочь себе в достижении этой цели, я создал запрещенную группу вкладок красного хрома.
В группу входят сообщества, к которым я принадлежу, ссылки, Twitter, Slack и мои страницы аналитики. Я знаю, что нельзя открывать группу в периоды глубокого сосредоточения. Да, да, я знаю, я мог бы вообще закрыть вкладки, но у меня есть привычка открывать сайты заново. Хранение их взаперти в группе помогает мне помнить, что они больше всего меня отвлекают.
Еще одна вещь, которую я пытался принять, — это стратегия, изложенная Майклом Линчем, согласно которой показатели проверяются только один раз в неделю в последнюю пятницу. У него также были проблемы с проверкой метрики:
Проверка показателей — это «мелкая работа»: она не требует глубокого внимания или критического мышления, но кажется продуктивной.
…
Пока я не отказался от привычки постоянно проверять статистику, я никогда не осознавал, сколько места это занимает в моем мозгу.
— Майкл Линч, Как быстро расти и никогда не получать прибыль.
4. Записывайте контекст по ходу дела
Последний совет по борьбе с распадом контекста — делать заметки на ходу. Мне нравится иметь сценарий bash в каждом каталоге с именем .zing . Он игнорируется моим глобальным git-ignore, поэтому я могу разместить их рядом с кодом, над которым я работаю. Вот пример одного, с которым я работал на прошлой неделе.
#! / Bin / bash
# Задачи:
# - проверьте, запускался ли он дважды, обновляет ли он использование за этот день
# - использовать end_ts для даты
# - использовать последнюю пришедшую запись
# - ceil ежемесячное использование 219.002 == 220
./report_to_stripe.rb 05 /
выход
../bin/monthly_report.rb 05 /
выход
Мой файл .zing служит двум целям. Он хранит список задач и заметок, а также историю последней выполненной мной команды. Когда я возвращаюсь утром, я могу выполнить сценарий, увидеть вывод кода и быстро начать свой день обратно к тому, что я делал.
Я использую https://github.com/jewel/zing для выполнения скрипта из vim или моего терминала, набрав z . Это удобный способ ускорить мои итерации.
Каждый день — это битва за то, чтобы моя башня сосредоточения была построена и свободна от стремительного ветра отвлекающих факторов и отвлекающих факторов. Совместная работа по предотвращению ненужных перерывов — это коллективные усилия, и если все сделано правильно, это может иметь огромное влияние на производительность и увеличить шансы разработчиков в достижении потока.
Загрузка...
