Комментарии 45
Позвольте возразить против демонизации переключений. Кроме очевидных минусов, когда тебя очевидно раздергивают, это может быть и полезно. Это важный навык работы с вниманием, сознанием, когнитивным ресурсом, как индивидуальным так и групповым. При обсуждениях, например, бывает аналитический паралич. Или когда, например, застрял в задаче и чувствуешь что нужно "выдернуться" - полезно пройтись, переключиться на другую задачу, иногда даже специально сделать это максимально резко (подвесить "гештальт" чтобы оно само там поварилось в "котелке"). Не зря ведь считается, что переключение - это форма отдыха. Когда включаются другие "нейроансамбли" перегруженные отдыхают, восстанавливаются. Вообще, рекомендую добавить в свои фундаментальные, базовые убеждения что-то типа "нет ничего плохого, есть лишь когда оно неуместно, не вовремя или чрезмерно" (как "все яд и все лекарство").
Я думаю, вы путаете контекст текущей задачи и контекст деятельности в целом. При смене деятельности вы действительно можете отдохнуть, особенно, если эта деятельность затрагивает другие участки мозга или вообще почти никакие не затрагивает, однако постоянная смена контекста в рамках одной задачи это действительно проблема. Мозгу просто сложно держать такой объем данных в памяти, сложно концентрироваться, нагрузка возрастает.
Прости, но нет. Переключения внимания действительно надолго убивают концентрацию. Возможно, у всех людей это происходит по-своему, но лично я после ответа на короткий телефонный звонок могу 23 минуты просто вспоминать, что я вообще делал до этого
Бывает что убивает, а бывает что и помогает. Как нож, например.
Ну так разница в том, запланированы ли они. Когда у тебя паралич - нужно сбросить наброски на бумагу и пойти гулять или посмотреть что-нибудь. Но когда ты продуктивно работаешь, выстроив в голове сложную сеть фактов/понятний и их связей, незапланированное отвлечение разрушает, оставляя обломки и забирая кучу времени на восстановление (это если если получится восстановить контекст, у некоторых, типа поэтов, вдохновение может не повториться в той же конфигурации - и черновик стиха просто выбрасывается).
Не могу быть так категоричен. С чего я и начинал - все бывает очень по-разному, в спектре от вреда и до пользы. Более того, есть ситуации когда надо смотреть шире "моей задачи", когда подворачивается возможность обговорить что-то более важное по проекту. Не вижу проблемы с переключениями, когда я сам ими управляю, взвешиваю за и против и беру ответственность за последствия.
Ого, открытие. Вот буквально недавно читал подобную статью. Когда ж это было? В 2005? Или 2004? Склероз одолел. Про поток там еще было.
https://habr.com/ru/articles/166715/
Никогда не отвлекай программиста
Не будите программиста: https://alexvgrey.livejournal.com/34039.html
переключение контекста реальная проблема. Иногда после короткого вопроса в мессенджере приходится по 20-30 минут вспоминать, на чем остановился. У кого какие лайфхаки для борьбы с этим?"
Карандаш
Записал контекст - переключился.
Я даже трубку телефона не сразу поднимаю чтобы контекст не забыть
Иногда весь контекст не запишешь, ибо он включает в себя структуру программы, алгоритм, кучу переменных, сложные взаимосвязи между ними, и в потоке просто генерируется код, так как весь локальный мир на данный момент абсолютно понятен. Чтобы это всё выгрузить – понадобится ну очень много времени.
В такие моменты даже не хочется заканчивать работу, потому что в следующий раз придётся тратить кучу времени на загрузку всего этого великолепия обратно в оперативную память
Отключите уведомления. Мессенджер всё-таки асинхронное средство связи, можно прочитать сообщение когда удобно.
Наши мозги не рассчитаны на постоянное переключение контекста
Я не нейробиолог, но этот тезис кажется мне спорным. Люди исторически - всеядные собиратели, которым за пять минут может понадобиться откопать съедобный корень, спрятатся от ягуара на дереве и попутно сожрать три сырых яйца из удачно подвернувшегося птичьего гнезда. Без переключения тут не обойтись.
Сейчас мы хоть по деревьям и не лазаем, конструкция нашего мозга пока не изменилось слишком сильно
Люди исторически - всеядные собиратели... А не программисты. Не надо сравнивать лазанье по деревьям и умственную деятельность. Биохимия разная совершенно.
Не надо сравнивать лазанье по деревьям и умственную деятельность. Биохимия разная совершенно.
Белка-летяга, которая за несколько секунд с помощью глаз и мозга просчитывает расстояние до соседнего дерева с потрясающей точностью, может с вами поспорить :)
Вы что серьезно считаете что белка-летяга в прыжке занимается осознанной умственной деятельностью? Или вы скажем когда перепрыгиваете лужу с потрясающей точностью тоже занимаетесь в этот момент какой-то осознанной умственной деятельностью?
У белки-летяги это всё запрограммировано на уровне hardware, всё за тысячелетия оптимизировано на аппаратном уровне. Вот если бы у людей пару сотен тысяч лет шел естественный отбор по умению вертеть красно-чёрные деревья, то и собесы выглядели бы по-другому.
Боксёр тоже обрабатывает жуткое количество информации с немыслимой скоростью, но про то, чтобы из боксеров хорошие программисты выходили, я не слышал.
Ну да, как верно сказали выше -- исторически люди не очень-то приспособлены к программированию. Сидячий образ жизни нас вообще убивает.
Во-первых, как уже написали, программисты и собиратели это немного разное.
Во-вторых вы почему-то аксиоматически полагаете, что человек идеально приспособлен к своей роли. А это очень сомнительное предположение.
Белка-летяга, которая за несколько секунд с помощью глаз и мозга просчитывает расстояние до соседнего дерева с потрясающей точностью, может с вами поспорить :)
За физическую активность вроде вообще другие отделы мозга отвечают.
Запараллелить можно лишь автоматические действия, которые не требуют обработки информации лобными долями. Решение абстрактных задач требует сосредоточенности.
С точки зрения эволюции человеческий мозг формировался в условиях, где многозадачность в современном понимании не была типичной задачей. Наши предки жили в относительно стабильной среде, где выживание зависело от сосредоточенности на конкретных задачах: охоте, сборе пищи, наблюдении за угрозами. Мозг эволюционировал для глубокого фокуса на одной цели (например, выслеживании добычи или избегании хищников)
Постоянное переключение внимания между задачами не давало эволюционного преимущества, потому что оно снижало эффективность и увеличивало риск ошибки
Это было полезно, но в современном мире, где мы сталкиваемся с бесконечным потоком уведомлений, сообщений и задач, такой механизм оказывается перегруженным
Еще один хороший лайфхак, подсмотренный в одной из команд.
"Никогда не назначаем новые митинги на сегодня, только не ранее чем завтра". Это позволяет в голове иметь четкий план на сегодня и идти по нему. И знать что менеджер тебя не побеспокоит.
Довольно странно рядом с описанием ужасного ужаса от прерываний помещать совет про помодоро, где будильник через 25 минут выдергиваеи из контекста. В чем смысл? 23 минуты погружаемся в контекст, 2 минуты работаем - потом бессмысленный перерыв, и все сначала?
Да, есть такое противоречие. Но в pomodoro, по крайней мере в том виде, в котором я его узнал, предусмотрены серии помидор. У меня это 30-5-30-5-30. Получается 100 минут конецнтрации (соответствует рекомендациям этой статьи про 90-минутные отрезки глубокой работы). В перерывах просто не надо переключаться на умственную задачу (новости, соцсети в том числе), они - чтобы пройтись, размяться, сделать чай/кофе, посмотреть в окно.
Вы когда-нибудь замечали, что ваш разум испытывает замешательство при переключении с чтения электронного письма на написание кода?
Вот вообще не замечал ни разу. Более того, я спокойно могу делать одну задачу, отвлечься на письмо о новой задаче, быстренько прочесть его, задать уточняющие вопросы и продолжить делать первую задачу. Мне кажется, если понимаешь, что делаешь, то никакие переключения контекста тебя не выбьют из колеи. Это как вождение автомобиля: в первый раз испытываешь настолько сильную когнитивную перегрузку, что отвлекает всё: музыка, разговоры. А когда умеешь, то без музыки уже скучно ездить.
Рабочий процесс программиста лишь часть рабочих процессов соответствующего бизнеса в целом. Попытка выстраивать только его приведёт только к конфликтам с другими структурами организации и ухудшению интегральных показателей.
К примеру несколько команд программистов пишут сервисы которые контора разворачивает и продаёт. Кроме отдела инженеринга - несколько команд программистов, QA, разного рода менеджмента, есть отделы с соотв группами дев и тех опсов, отделы продаж, маркетинг и тепе. QA, допустим, проводит финальную регрессию нового релиза, у техопов стейджинг, девелоперы в середине активной разрабтки следующего, в продакшене предыдущий, продажники мутят новые фичи с клентами, маркетинг тоже что-то мутит со стратегей. Понятно, что запросы к разработчикам от этих подразделений или их отдельных представителей, обладают разным приоритетом, сложностью и допустимой задержкой ответа. Однако игнорировать запрос QA на посмотреть логи за неделю до релиза не получится, да и вредно - не релиз же сдвигать. Или от саппорта, когда у нового клиента или другого, старого и большого, что-то стало не так после использования какого то нового сценария использования.
В статье (всё что в ней перечислено - работает) есть рекомендации, что надо вводить правила, и они верные. Но правила надо совместно разрабатывать для всей организации. К примеру, запрос из QA или продакшена должен быть предметным - юзкейс, сценарий, идентификаторы логов, интенсивность ошибок. Понятно, что никто никогда ничего не менял в этих отделах)), но хорошо бы так же сведения об историях изменения окружения, тестовых скриптов и тепе. Для этого надо проводить тренинги тех, с кем девелоперы коммуницируют, устанавлвать формы и виды взаимодействия, временные рамки реакций.
В общем в одном отдельно взятом доме щастье построить не получится, имхо)
ну заполни этот эксель с зависимостями для начальства 🤡
Меня даже пару раз уволили по причине глубокого погружения в проект. Выключал месенжер. Чтобы не отвлекали, не выводили из потока.
Когда я работал ещё в офисе, думал что неплохо у каждого на столе иметь небольшой светофор
Зелёный - подходите поп ..поговорить
Жёлтый - только по работе
Красный - отвлекать только на пожар и крах серверов
А теперь надо равномерно через 10 мин посылать сообщения
Привет ты тут?
Есть вопрос
Короткий, на минутку
Не отвлекаю?
Точно не отвлекаю?
Секунду
А, все, сам разобрался
Умение делать push context, отвлечься, pop context - такой же навык, это тренируется. Правда, замечал за собой, что глубина стека, всё-же, ограничена 😊
Here are my tricks to keep context between interruptions:
1. Navigation among uncommitted changes in git. That means - one commit per day. Right after the commit to spend ~20 minutes working on a new task. Next day, all uncommitted changes will be a good reminder.
2. My phone is always off. It lives in the kitchen. My friends know that I'm not available 24/7, but before I go to sleep I check text messages.
3. I use Chat GPT to talk. Not for coding, just for planning. Any additional thoughts and progress upon the task I'm posting there. That creates a chain of contexts (15-50 messages).
4. At the beginning of the coding session, I'm providing for Gpt a detailed list of what I'm working on, the state of progress, where are the concerns. It's a start topic. This helps me achieve a stream state immediately after I realize what is the next step is required to continue working.
5. Commit messages - it includes what is required to do next. That gives the whole tree of interrupted tasks and requirements.
6. 2 coding sessions per day by ~4 hours, sleep in between.
7. Nicotine gum
8. Listening to some podcasts during coding sessions. It works 50% of the time, esp when the problem seems "unsolvable." Looking through the logs and code until an idea appears.
What is damaging:
1. Shopping spoils the whole day, so do it once per 2-3 weeks.
2. Talks with recruiters (that's my phone is off)
3. Corporate environment.
4. unplanned events. Any unplanned activity spoils at least one day when you become aware of it, one day before the event, the day of the event, and the next couple of days, when you realize that a context is lost.
Переключение контекста — главный убийца продуктивности разработчика