(no subject)
Блиин. Ну вот бывает же западло. Пару дней уделяла время, переводила статью, с которой идейно согласна, пол вечера оформляла, а её вперёд меня другой человек вывесил. Да не один.
Ну пусть хоть тут повисит, всё-таки жалко так выкидывать.
The interruptible programmer или как делать перерывы без потери эффективности
Мне 37 и я уже 16 лет как (профессиональный) разработчик. Вы могли подумать, что за это время я постиг эффективный стиль работы, который приносит желанные результаты без пагубных цепных реакций, но, к сожалению, вы были бы не правы. Я думаю, то, что я практиковал в первые 15 лет своей карьеры, делал каждый увлечённый программист: вкладывал в дело массу времени.
12-16+ часов в день, марафоны кодирования по вечерам и в выходные, пицца в клавиатуре, критические моменты, дебаггинг в 3 часа ночи, когда вы просто не можете пойти спать, потому что вы просто чувствуете источник этого бага между кончиками пальцев, чёрт, отчаянный коддинг в последние минуты до дедлайна, когда вы ухитряетесь втиснуть последний кусок кода, как Джек Бауэр, как раз перед тем, как всё навернётся. Если вы из тех, о ком я говорю, вы сейчас мудро киваете и, возможно слегка усмехаетесь, вспоминая о прошлых испытаниях и славе. Такой тип сумасшедшей самоотверженности уважаем в наших кругах, и этого ожидают от каждого разработчика, который претендует на успех.
Но выясняется, что это качество не полезно для вашего здоровья - кто бы мог подумать?
Те из вас, кто знает меня, помнят, как я с трудом избавлялся от старых привычек из-за проблем со спиной, которые я сначала игнорировал, потом пытался приспособиться, и наконец уступил и занялся проблемой серьёзно. То, что я занимался собственным делом было главной проблемой. Вылезание из этой ямы, которую я сам себе вырыл, заняло много времени и принесло массу расстройств - я читал довольно мало книг о продуктивности, пытаясь найти ответы на вопрос, как продолжать работать, и в конце концов понял, что ответы, которые вы сами для себя формируете оказываются лучшими. Я бы хотел поделиться одной вещью, которую я узнал, пройдя такой путь.
Но я «в ударе»!!
Итак, я хочу поговорить о самой большой проблеме, с которой я столкнулся: о периодах концентрации. Теперь я не могу сидеть за столом дольше чем час к ряду. Если я не буду вставать, делать пару хороших потягиваний и т.д. по крайней мере раз в час, однажды я дорого за это заплачу, сделав неловкое движение, и потеряю, возможно, ещё несколько дней. Также я теперь не могу работать без боли больше, чем стандартные 8 часов. Проблема была в том, что стиль в котором я работал более 15-ти лет включал в себя постепенный переход в состояние «в ударе» и непрерывное программирование на протяжении очень долгих промежутков времени. Это обычное дело среди кодеров, которые любят прятаться на несколько часов от всех, носить наушники, чтобы избежать отвлечений внимания, иметь «часы для медитации» и так далее - и это также причина того, что мы плохо реагируем, когда отвлекают.
Программирование требует концентрации, а концентрация - она как двигатель, прогревается не сразу, и единожды запустив, вам уже не хочется его выключать, потому что запускать его снова - это время.
Я думал, что у неё нет решения, и хотел уже смириться с тем, что из-за этого буду менее продуктивным. Однако, в течение последних 6-ти месяцев я понял, что подход «медленный разогрев, долгое время пребывания в ударе» не неразрешимая проблема, а больше поведенческий момент, и вполне возможно переучить себя справляться и по-другому. Немного похоже на то, как люди учатся полифазному сну - это не то, чего вы не можете сделать, просто когда вы привыкли делать что-то определенным образом, изменение этого даётся очень, очень тяжело. Но не невозможно, если иметь достаточно мотивации и времени для привыкания.
Так, моей целью было акклиматизироваться к множеству коротких отрезков работы, вместо пары длинных, с сохранением продуктивности. Ключевым моментом было научиться возвращаться в состояние «В ударе» за наикратчайшее возможное время - совсем как эти сони тренируются достигать быстрого сна скорее. Я уже почти добился своего, или, по крайней мере, сильно продвинулся по сравнению с тем, что было раньше. Так какие техники я использовал, чтобы осуществить эту перемену?
1. Примите перерывы.
Это преимущественно не техника, а осознанная психологическая адаптация затрагивающая все практические подходы, о которых я расскажу дальше. Это тяжело - вы должны попытаться отодвинуть в сторону годы сопротивления перерывам и поначалу, пока вы не приспособитесь, будете чувствовать, будто сделали недостаточно. Многие люди, вероятно, захотят сдаться, если у них не будет какого-то особого мотиватора - для меня ежедневная боль отлично выполняла эту функцию. Главное, что я хочу сказать здесь, это то, что переход -это только фаза, и что действительно возможно быть прерываемым программистом, который по-прежнему доводит дела до конца. Но вы не должны бороться с перерывами, поэтому я поставил это правило на первое место.
2. Не держите контекст в голове.
Большинство проблем с прерываниями случаются из-за потери контекста. Когда вы в ударе, вы жонглируете целой кучей контекста в своей голове, постоянно перестраивая его на лету, поддерживая и корректируя связи между сущностями. Перерывы рушат всё это и чтобы снова собрать требуется время. Мой ответ на это - выносите это из головы, насколько возможно, воплощайте это в заметки, тексты, схемы и т.д., на всех возможных уровнях.
2.1 Непрерывно поддерживайте работу с комментариями к текущему заданию.
Я сам себе хроникёр. Я пишу записки о том, чем я занимаюсь, всё время, будь это добавление комментария в строку, частые фиксации обдуманного и написание подробных записок, каляканье картинок на (упорядоченных) бумажках. Это действительно не так тягостно, и, кстати, воплощение ваших мыслей на бумаге часто может помочь вам прояснить их. По сути, смысл в том, что примерно каждые 30 минут я должен был генерировать новый кусочек контекста, который я хранил где-то не в голове. Если бы я этого не делал, мне было бы труднее построить его после прерывания. Это обычно не занимает много времени, зато приносит дополнительную пользу, как, например, наличие записи процесса вашего обдумывания проблемы и решений.
2.2 Безжалостно игнорируйте вопросы, не относящиеся к делу.
Вы может быть заметили, что в предыдущем абзаце я использовал «текущее задание» в единственном числе. Не «задания». Нет больше в вашей жизни места для многих заданий. Есть только одно задание и отвлечения.
Наверное, мы все используем багтрекеры и тикет-системы чтобы отслеживать багги и отображать требования, но когда вы работаете над тикетом часто можете встретить новый баг или найти возможность для улучшения, или придумать классную новую фичу. Как много из нас сразу разбираются с этим сразу, потому что это область, в которой мы уже находимся, или это «банально», или это классная идея, и вы хотите заняться этим прямо сейчас? Я знаю, я тоже таким был - но больше нет, все побочные вопросы, не связанные с тем, что я делаю в данный момент, сливаются в тикет-систему и немедленно забываются до тех пор, пока я не сделаю текущее задание, не взирая на его размер, значимость или приоритет. Это звучит просто и очевидно, и это может быть даже официально закреплено в вашей организации, но кто из вас действительно делает так всегда? Польза этого правила в том, что вы избавитесь от лишнего уровня контекста, добавляемого даже самым маленьким отвлечением.
Чтобы это работало, вам нужна быстрая, лёгкая и не заставляющая вас бепокоиться о том, сколько деталей вы вкладываете, тикет-система. Вы должны отвлечься и вернуться за 30 секунд, тогда вы сможете выгрузить свои мысли без отвлечения - вы расширите их позже.
2.3 Всегда знайте, что вы будете делать дальше.
Этот совет из Getting Things Done, но это хороший. Когда вы возвращаетесь с перерыва или прерывания, вы должны не тратить время на выяснение, что вам делать дальше. Ваша тикет-система поможет вам здесь, равно как и комментарии, которые вы делали к своему текущему заданию. Если вас заставили прерключаться между задачами или проектами, пока вы поддерживаете контекст внешним, у вас не должно быть проблем с узнаванием, какие следующие действия следует предпринять по каждой позиции. Важно иметь одно следующее действие на каждом проекте. Если их несколько, вы проведёте больше времени, выбирая между ними и тратя время попусту. В любой момент вы должны не только иметь одно текущее задание, но ещё и одно чётко выраженное следующее действие по этому заданию. Половина проблемы эффективной работы в знании, что делать дальше.
3. Расставляйте приоритеты негативно.
Я упоминал следующие действия в предыдущем параграфе, но как решить, что идёт следом? Масса времени может быть растрачена в мучениях над приоритетами, и мне приходилось бороться с этим, я заносил всё, что я хотел сделать, в список и нужно было просто выяснить, что мне необходимо сделать сначала. Я открыл, что я могу сэкономить кучу времени и также сделать лучше, предположив для начала, что я не буду делать никакое из заданий, и оценив отрицательные последствия от не деланья каждого из них.
Поэтому вместо «Какая из функций А или Б важнее?» вопрос стал таким: «Давайте предположим, мы обойдёмся без А или Б. Какие последствия мы получим в каждом случае?» Это может показаться тонким различием, но возможность(хоть и гипотетическая) исключить задание целиком, вместо того, чтобы устанавливать относительный порядок предполагая, что они все в конечном итоге будут сделаны, как правило, даёт возможность оценить приоритеты точнее.
4. Признайте преимущества перерывов.
Большая часть из написанного о том, как ограничить негативные аспекты перерывов, но на самом деле они имеют и связанные с работой преимущества. Готов поспорить, что все кодеры оставались на работе допоздна, пытаясь пофиксить ошибку, а потом обнаруживали, что на следующий день они потратят на это 15 минут или додумаются до ответа в каком-нибудь неподходящем месте типа душа. Причина очень проста - растянутые периоды концентрации кажутся продуктивными, и для операционного/последовательного мышления может быть и так, но для всего остального, такого как креативное мышление или решение проблем, это часто наоборот. Идело не только в том, что уставшие умы мыслят менее чётко, но часто ответ на проблему лежит не в там, где вы напрасно ищете на протяжении последних нескольких часов, а стоит посмотреть на проблему с другой стороны - и вот он. Длинные периоды концентрации обычно «фиксируют» последовательности мыслей, делая слишком редкими приходы вдохновения и приступы гениальности. Креативность всегда приходит когда вы не мучаетесь. Так что прерывание последовательности мыслей вполне моет быть очень полезным.
Я ещё много могу сказать, но пока достаточно. Надеюсь кто-то найдёт это интересным и полезным=)
Ну пусть хоть тут повисит, всё-таки жалко так выкидывать.
The interruptible programmer или как делать перерывы без потери эффективности
Мне 37 и я уже 16 лет как (профессиональный) разработчик. Вы могли подумать, что за это время я постиг эффективный стиль работы, который приносит желанные результаты без пагубных цепных реакций, но, к сожалению, вы были бы не правы. Я думаю, то, что я практиковал в первые 15 лет своей карьеры, делал каждый увлечённый программист: вкладывал в дело массу времени.
12-16+ часов в день, марафоны кодирования по вечерам и в выходные, пицца в клавиатуре, критические моменты, дебаггинг в 3 часа ночи, когда вы просто не можете пойти спать, потому что вы просто чувствуете источник этого бага между кончиками пальцев, чёрт, отчаянный коддинг в последние минуты до дедлайна, когда вы ухитряетесь втиснуть последний кусок кода, как Джек Бауэр, как раз перед тем, как всё навернётся. Если вы из тех, о ком я говорю, вы сейчас мудро киваете и, возможно слегка усмехаетесь, вспоминая о прошлых испытаниях и славе. Такой тип сумасшедшей самоотверженности уважаем в наших кругах, и этого ожидают от каждого разработчика, который претендует на успех.
Но выясняется, что это качество не полезно для вашего здоровья - кто бы мог подумать?
Те из вас, кто знает меня, помнят, как я с трудом избавлялся от старых привычек из-за проблем со спиной, которые я сначала игнорировал, потом пытался приспособиться, и наконец уступил и занялся проблемой серьёзно. То, что я занимался собственным делом было главной проблемой. Вылезание из этой ямы, которую я сам себе вырыл, заняло много времени и принесло массу расстройств - я читал довольно мало книг о продуктивности, пытаясь найти ответы на вопрос, как продолжать работать, и в конце концов понял, что ответы, которые вы сами для себя формируете оказываются лучшими. Я бы хотел поделиться одной вещью, которую я узнал, пройдя такой путь.
Но я «в ударе»!!
Итак, я хочу поговорить о самой большой проблеме, с которой я столкнулся: о периодах концентрации. Теперь я не могу сидеть за столом дольше чем час к ряду. Если я не буду вставать, делать пару хороших потягиваний и т.д. по крайней мере раз в час, однажды я дорого за это заплачу, сделав неловкое движение, и потеряю, возможно, ещё несколько дней. Также я теперь не могу работать без боли больше, чем стандартные 8 часов. Проблема была в том, что стиль в котором я работал более 15-ти лет включал в себя постепенный переход в состояние «в ударе» и непрерывное программирование на протяжении очень долгих промежутков времени. Это обычное дело среди кодеров, которые любят прятаться на несколько часов от всех, носить наушники, чтобы избежать отвлечений внимания, иметь «часы для медитации» и так далее - и это также причина того, что мы плохо реагируем, когда отвлекают.
Программирование требует концентрации, а концентрация - она как двигатель, прогревается не сразу, и единожды запустив, вам уже не хочется его выключать, потому что запускать его снова - это время.
Я думал, что у неё нет решения, и хотел уже смириться с тем, что из-за этого буду менее продуктивным. Однако, в течение последних 6-ти месяцев я понял, что подход «медленный разогрев, долгое время пребывания в ударе» не неразрешимая проблема, а больше поведенческий момент, и вполне возможно переучить себя справляться и по-другому. Немного похоже на то, как люди учатся полифазному сну - это не то, чего вы не можете сделать, просто когда вы привыкли делать что-то определенным образом, изменение этого даётся очень, очень тяжело. Но не невозможно, если иметь достаточно мотивации и времени для привыкания.
Так, моей целью было акклиматизироваться к множеству коротких отрезков работы, вместо пары длинных, с сохранением продуктивности. Ключевым моментом было научиться возвращаться в состояние «В ударе» за наикратчайшее возможное время - совсем как эти сони тренируются достигать быстрого сна скорее. Я уже почти добился своего, или, по крайней мере, сильно продвинулся по сравнению с тем, что было раньше. Так какие техники я использовал, чтобы осуществить эту перемену?
1. Примите перерывы.
Это преимущественно не техника, а осознанная психологическая адаптация затрагивающая все практические подходы, о которых я расскажу дальше. Это тяжело - вы должны попытаться отодвинуть в сторону годы сопротивления перерывам и поначалу, пока вы не приспособитесь, будете чувствовать, будто сделали недостаточно. Многие люди, вероятно, захотят сдаться, если у них не будет какого-то особого мотиватора - для меня ежедневная боль отлично выполняла эту функцию. Главное, что я хочу сказать здесь, это то, что переход -это только фаза, и что действительно возможно быть прерываемым программистом, который по-прежнему доводит дела до конца. Но вы не должны бороться с перерывами, поэтому я поставил это правило на первое место.
2. Не держите контекст в голове.
Большинство проблем с прерываниями случаются из-за потери контекста. Когда вы в ударе, вы жонглируете целой кучей контекста в своей голове, постоянно перестраивая его на лету, поддерживая и корректируя связи между сущностями. Перерывы рушат всё это и чтобы снова собрать требуется время. Мой ответ на это - выносите это из головы, насколько возможно, воплощайте это в заметки, тексты, схемы и т.д., на всех возможных уровнях.
2.1 Непрерывно поддерживайте работу с комментариями к текущему заданию.
Я сам себе хроникёр. Я пишу записки о том, чем я занимаюсь, всё время, будь это добавление комментария в строку, частые фиксации обдуманного и написание подробных записок, каляканье картинок на (упорядоченных) бумажках. Это действительно не так тягостно, и, кстати, воплощение ваших мыслей на бумаге часто может помочь вам прояснить их. По сути, смысл в том, что примерно каждые 30 минут я должен был генерировать новый кусочек контекста, который я хранил где-то не в голове. Если бы я этого не делал, мне было бы труднее построить его после прерывания. Это обычно не занимает много времени, зато приносит дополнительную пользу, как, например, наличие записи процесса вашего обдумывания проблемы и решений.
2.2 Безжалостно игнорируйте вопросы, не относящиеся к делу.
Вы может быть заметили, что в предыдущем абзаце я использовал «текущее задание» в единственном числе. Не «задания». Нет больше в вашей жизни места для многих заданий. Есть только одно задание и отвлечения.
Наверное, мы все используем багтрекеры и тикет-системы чтобы отслеживать багги и отображать требования, но когда вы работаете над тикетом часто можете встретить новый баг или найти возможность для улучшения, или придумать классную новую фичу. Как много из нас сразу разбираются с этим сразу, потому что это область, в которой мы уже находимся, или это «банально», или это классная идея, и вы хотите заняться этим прямо сейчас? Я знаю, я тоже таким был - но больше нет, все побочные вопросы, не связанные с тем, что я делаю в данный момент, сливаются в тикет-систему и немедленно забываются до тех пор, пока я не сделаю текущее задание, не взирая на его размер, значимость или приоритет. Это звучит просто и очевидно, и это может быть даже официально закреплено в вашей организации, но кто из вас действительно делает так всегда? Польза этого правила в том, что вы избавитесь от лишнего уровня контекста, добавляемого даже самым маленьким отвлечением.
Чтобы это работало, вам нужна быстрая, лёгкая и не заставляющая вас бепокоиться о том, сколько деталей вы вкладываете, тикет-система. Вы должны отвлечься и вернуться за 30 секунд, тогда вы сможете выгрузить свои мысли без отвлечения - вы расширите их позже.
2.3 Всегда знайте, что вы будете делать дальше.
Этот совет из Getting Things Done, но это хороший. Когда вы возвращаетесь с перерыва или прерывания, вы должны не тратить время на выяснение, что вам делать дальше. Ваша тикет-система поможет вам здесь, равно как и комментарии, которые вы делали к своему текущему заданию. Если вас заставили прерключаться между задачами или проектами, пока вы поддерживаете контекст внешним, у вас не должно быть проблем с узнаванием, какие следующие действия следует предпринять по каждой позиции. Важно иметь одно следующее действие на каждом проекте. Если их несколько, вы проведёте больше времени, выбирая между ними и тратя время попусту. В любой момент вы должны не только иметь одно текущее задание, но ещё и одно чётко выраженное следующее действие по этому заданию. Половина проблемы эффективной работы в знании, что делать дальше.
3. Расставляйте приоритеты негативно.
Я упоминал следующие действия в предыдущем параграфе, но как решить, что идёт следом? Масса времени может быть растрачена в мучениях над приоритетами, и мне приходилось бороться с этим, я заносил всё, что я хотел сделать, в список и нужно было просто выяснить, что мне необходимо сделать сначала. Я открыл, что я могу сэкономить кучу времени и также сделать лучше, предположив для начала, что я не буду делать никакое из заданий, и оценив отрицательные последствия от не деланья каждого из них.
Поэтому вместо «Какая из функций А или Б важнее?» вопрос стал таким: «Давайте предположим, мы обойдёмся без А или Б. Какие последствия мы получим в каждом случае?» Это может показаться тонким различием, но возможность(хоть и гипотетическая) исключить задание целиком, вместо того, чтобы устанавливать относительный порядок предполагая, что они все в конечном итоге будут сделаны, как правило, даёт возможность оценить приоритеты точнее.
4. Признайте преимущества перерывов.
Большая часть из написанного о том, как ограничить негативные аспекты перерывов, но на самом деле они имеют и связанные с работой преимущества. Готов поспорить, что все кодеры оставались на работе допоздна, пытаясь пофиксить ошибку, а потом обнаруживали, что на следующий день они потратят на это 15 минут или додумаются до ответа в каком-нибудь неподходящем месте типа душа. Причина очень проста - растянутые периоды концентрации кажутся продуктивными, и для операционного/последовательного мышления может быть и так, но для всего остального, такого как креативное мышление или решение проблем, это часто наоборот. Идело не только в том, что уставшие умы мыслят менее чётко, но часто ответ на проблему лежит не в там, где вы напрасно ищете на протяжении последних нескольких часов, а стоит посмотреть на проблему с другой стороны - и вот он. Длинные периоды концентрации обычно «фиксируют» последовательности мыслей, делая слишком редкими приходы вдохновения и приступы гениальности. Креативность всегда приходит когда вы не мучаетесь. Так что прерывание последовательности мыслей вполне моет быть очень полезным.
Я ещё много могу сказать, но пока достаточно. Надеюсь кто-то найдёт это интересным и полезным=)