Разбивая большие «приятные» задачи на части и добавляя их по частям к более мелким задачам, вы можете повысить свою продуктивность.

Сколько раз вам говорили не прыгать с задачи на задачу? Сосредоточьтесь на одной задаче до ее завершения, а затем переходите к следующей. Если вы читаете это, я предполагаю, что либо вы боретесь с концентрацией внимания, либо это делает кто-то, кого вы любите.

Для разработчиков программного обеспечения это может быть еще более сложной задачей. У нас так много разных вещей, которые мы хотим выполнить. Мы хотим закончить этот тикет, достроить эту фичу, почистить этот код, но что бы мы ни делали, эта вещь висит у нас над головой.

Исполнительная дисфункция

Исполнительная дисфункция проявляется во многих вещах. Лень. Прокрастинация. Паралич выбора. Независимо от того, как это проявляется, исполнительная дисфункция — это наш СДВГ, который мешает нам выполнять задачу, которую мы хотим выполнить.

Почему это происходит? Об этом немного рассказывает журнал ADDitude в статье Что такое исполнительная функция? 7 дефицитов, связанных с СДВГ. Существенным для того, о чем мы говорим сегодня, является раздел о цепи Почему. Особенно в том, что касается разработки программного обеспечения и работы, наш мозг с СДВГ иногда будет бороться с тем, почему мы должны выполнять задачу.

И даже если мы знаем, почему задача важна, это не значит, что наш мозг сможет ее обработать в данный момент. Если вам скучно или задача кажется сложной, «почему» будет отфильтровано через все это. Это снизит вашу способность выполнять задачу, потому что задача будет казаться менее важной.

Пример: рефакторинг кода

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

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

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

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

Ни то, ни другое не хорошо.

С такой большой задачей может быть сложно взяться за нее, даже если клиент счастлив, что мы это делаем.

Каждый файл — это задача.

Каждая ошибка в каждом файле — это задача.

Каждая команда для получения каждой ошибки в каждом файле — это задача.

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

Это может быть только я.

Объединение (несколько) похожих задач

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

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

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

Это простое решение, но эффективное.

Когда это может пойти не так?

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

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

Вывод

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

Я надеюсь не дать вам «один идеальный способ решить ваш СДВГ», а предоставить вам пример того, что работает для меня, в надежде, что это может сработать для вас. Или, по крайней мере, это может подтолкнуть к идее чего-то, что действительно сработает для вас.