Книжное
Читаю книгу Procrastination and Blocking, научное исследование того, как программисты забивают хер на работу как писатели и тому подобные творческие личности забивают болтъ и, пребывая в творческом ступоре, не могут написать ни строчки.
Книга почему-то сложная для чтения, хотя незнакомых слов очень мало, но структура предложений как-то более непонятная, чем, скажем, в The Social Animal или там вообще в каком-нибудь Real World Haskell или TAPL.
Но тема забивания на работу и ступора при работе над проектами рассматривается достаточно серьезно и с нетривиальной стороны. До практических исследований и советов "как начать работать", пока не дочитал.
Вкратце, там описывается, что люди забивают на неприятную работу или работу с отложенным далеко вознаграждением, ради коротких и быстро дающих результат действий типа "помыть посуду", "посортировать файло", "поделать бэкапы", "посраться в ЖЖ", вплоть до тех пор, пока не наступает дедлайн, а потом ебошат по ночам как проклятые, чтобы успеть. И так по кругу.
Там же упоминается, что лучше работать понемногу каждый день, чем иногда "входить в поток" и делать за день работу целой недели. С этим не совсем понятно, т.к. качество кода в случае "потока" получается сильно лучше, чем когда сидишь и "через немогу" пилишь тупизм, заодно сокращается оверхед на вход-выход из рабочего контекста. Но там написано, что подобный способ работы в долгосрочной перспективе снижает производительность. Похоже, что так оно и есть, я после недели-двух экстремального пиления кода потом неделями могу ничего не делать, кроме мелочевки.
Я вообще считал, что обычно такое тупление над работой возникает когда нужно делать какую-нибудь бессмысленную хрень, причем под давлением, или там является следствием работы в условиях постоянных отвлекающих факторов. Но практика показывает, что даже при убранных отвлекающих факторах с течением времени оно усугубляется и не дает делать ничего, кроме сверхкоротких действий на 2-4 часа (админство, мелкие прожки, саппорт).
Пока вроде выводы такие, что способствующими туплению факторами является самостоятельная работа вне команды, привычка делать все короткими импульсами быстрой работы, ориентация на конечный результат, а не на процесс работы и перфекционизм.
Книга почему-то сложная для чтения, хотя незнакомых слов очень мало, но структура предложений как-то более непонятная, чем, скажем, в The Social Animal или там вообще в каком-нибудь Real World Haskell или TAPL.
Но тема забивания на работу и ступора при работе над проектами рассматривается достаточно серьезно и с нетривиальной стороны. До практических исследований и советов "как начать работать", пока не дочитал.
Вкратце, там описывается, что люди забивают на неприятную работу или работу с отложенным далеко вознаграждением, ради коротких и быстро дающих результат действий типа "помыть посуду", "посортировать файло", "поделать бэкапы", "посраться в ЖЖ", вплоть до тех пор, пока не наступает дедлайн, а потом ебошат по ночам как проклятые, чтобы успеть. И так по кругу.
Там же упоминается, что лучше работать понемногу каждый день, чем иногда "входить в поток" и делать за день работу целой недели. С этим не совсем понятно, т.к. качество кода в случае "потока" получается сильно лучше, чем когда сидишь и "через немогу" пилишь тупизм, заодно сокращается оверхед на вход-выход из рабочего контекста. Но там написано, что подобный способ работы в долгосрочной перспективе снижает производительность. Похоже, что так оно и есть, я после недели-двух экстремального пиления кода потом неделями могу ничего не делать, кроме мелочевки.
Я вообще считал, что обычно такое тупление над работой возникает когда нужно делать какую-нибудь бессмысленную хрень, причем под давлением, или там является следствием работы в условиях постоянных отвлекающих факторов. Но практика показывает, что даже при убранных отвлекающих факторах с течением времени оно усугубляется и не дает делать ничего, кроме сверхкоротких действий на 2-4 часа (админство, мелкие прожки, саппорт).
Пока вроде выводы такие, что способствующими туплению факторами является самостоятельная работа вне команды, привычка делать все короткими импульсами быстрой работы, ориентация на конечный результат, а не на процесс работы и перфекционизм.
no subject
no subject
no subject
пароль 111
no subject
no subject
no subject
no subject
no subject
no subject
no subject
спасибо, ребе, буду читать
логично же, сцуко.
а почему тогда в каждой второй статье и книжке - "ориентированность на результат"? наверно, результаты у них простые и короткие.
озарение
no subject
no subject
no subject
no subject
no subject
no subject
no subject
пароль тот же
no subject
no subject
no subject
Такой гипер-структурирующий принцип, который рано или поздно натыкается либо на неструктурируемый внешний мир: "А захрена писать эту программу для лотерейных билетов, если логичней вообще эту отрасль запретить?", или на тупизм внутри самой предметной области, типа какой-нибудь книги продаж. И принципу становится хреноватенько, и программеру вместе с ним )).
no subject
Подобная книжка уже попадалась, тезисы зацепили, достаточно долго наблюдал за собой и за коллегами в свете этих тезисов.
Работа сверх 8 часов в день, действительно плохо влияет на производительность в долгосрочной перспективе.
Для себя объяснил тем, что 2 лишних часа на работе надо компенсировать 4 часами лишнего отдыха. А т.к. никто эти лишние 4 часа не добавит, то усталость накапливается и мозг устаёт.
"Вход в поток" - это невероятное состояние, которое в буквальном смысле увеличивает результативность в 5 раз. И за один день можно выполнить недельную стопку работы.
Однако, есть два фактора.
Во-первых, состояние "потока" само не приходит. Надо как минимум каждый день выполнять некоторый объем работ, чтобы "случайно увлечься".
Во-вторых, всё же есть некое вуду под названием "биоритмы", когда войти в состояние потока проще. Ибо случаются совпадения, когда все факторы присутствуют: и работа интересная, и отдохнувший, и задачу знаешь как делать, и не отвлекает никто - а в поток войти не можешь.
И, сильно в тему, но у тебя пропущено (или акцента нет).
"Быстрое вознаграждение" реально получать и на долгосрочных проектах. Мне повезло и PM на практике продемонстрировал полезность совещаний. Буквально за 15-30 минут совещания вся группа (8 человек) получала "волшебный пендель" и с новыми силами бросалась в работу. А ничего "архи" не было: за 3-7 минут подводились итоги предыдущей недели (без пафоса, просто "Итого"), расставлялись приоритеты (надо срочно "добить" вот этот кусок; вот этот кусок маленький, поэтому его сделайте в первую очередь и т.д.), блиц-опросом выяснялось на чём застрял каждый из членов команды. Если затык был "серьёзный", то всех отправляли работать, а "счастливчики" получали "доступ к телу" еще на 15 минут, за которые он умудрялся или разрулить проблему, или отправить к специалисту.
Такие совещания проводились 2 раза в неделю: вторник и пятница.
no subject
no subject
no subject
no subject
no subject
Это можно в спокойных условиях изучить при интересе, или же целенаправленными усилиями.
no subject
no subject
no subject