обещал поднять тему ~"Психологические аспекты и приёмы в SE"
но чета после нахождения работы стало влом всё это систематизировать
вот бессвязная бредятина из головы, ничего не оформлял
тут всё верно, можно кое-что уточнить будет или обсудить
главная мораль басни:
моральная энергия разработчика — ценный, медленно восстановимый ресурс, от которого и должен плясать процесс разработки


эффективна первая 5-6 часов разработки, затем эффективность снижается
она может оставаться высокой, если разработчик сам вошел в "поток", и остаётся там даже в конце дня
в него невозможно вогнать человека принудительно
он должен сосредоточиться, войти в контекст, и мысли сами потекут

по максимуму сократить митинги, особенно массовые

любое прерывание мысли разработчика сбивает ему контекст
и работу по восстановлению контекста ему приходится начинать практически с начала

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

если задача на 2 часа, а у разработчика есть 3 интервала по 1.5 часа — задачу он скорее всего не решит

в связи с нежелательностью отвлечений, важно не вторгаться в середине процесса со срочными проблемами (да ещё если ко всем)

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

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

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

моральные силы восстанавливаются но довольно медленно (на сколько помню нас учили что примерно на 5-6 часов за сутки)
на это нужно время
и ещё время нужно чтобы хоть запланировать как человек будет конкретно восстанавливаться — гулять, кататься на коньках, смотреть кино и т.п.

разработка вредит здоровью в следующих аспектах:
кровеносная система
опорнодвигательный аппарат
зрение
при этом критически важно кровоснабжение мозга, которое страдает при длительном сидении как от ухудшения тонуса сосудов, так и возможного пережимания сосудов в позвонках
человеку нужно ходить хотя бы около 8 км в день (на одно это нужно больше часа)
при проблемах со зрением могут появляться гнетущие мысли, которые будут мешать сосредоточиться

необходимость отвлекаться на отслеживание почты, и тем более отдельных сообщений в каналах
нас учили, что почту правильно проверять раз утром и раз в конце дня

сколько стоит отвлечь разработчика?
допустим он как раз кодирует сейчас уже 2 часа,
а ему следует поработать в потоке 3 часа, чтобы решить всю задачу
если в задаче нет "контрольных точек" — этапов, которые можно завершить и переходить к следующему
то в принципе потери могут составить все 2 программисто-часа

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

"никогда, ни в коем случае не делайте рабочий день программиста от звонка до звонка" (приписываю Терехову старшему)
(звонок в конце дня гарантированно собьёт контекст или не позволит начать задачу)

разработчик сможет поработать и неделю по 12 часов, но есть граница когда это приведёт к аппатии, болезням
и восстановление после такой недели займёт не 3 дня (20 дополнительных часов делить на 8), а больше

важны и тонус тела и моральные силы

бодрый и свежий программист, но у него может болеть голова

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

обещал поднять тему ~"Психологические аспекты и приёмы в SE"
но чета после нахождения работы стало влом всё это систематизировать
вот бессвязная бредятина из головы, ничего не оформлял
тут всё верно, можно кое-что уточнить будет или обсудить
главная мораль басни:
моральная энергия разработчика — ценный, медленно восстановимый ресурс, от которого и должен плясать процесс разработки


эффективна первая 5-6 часов разработки, затем эффективность снижается
она может оставаться высокой, если разработчик сам вошел в "поток", и остаётся там даже в конце дня
в него невозможно вогнать человека принудительно
он должен сосредоточиться, войти в контекст, и мысли сами потекут

по максимуму сократить митинги, особенно массовые

любое прерывание мысли разработчика сбивает ему контекст
и работу по восстановлению контекста ему приходится начинать практически с начала

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

если задача на 2 часа, а у разработчика есть 3 интервала по 1.5 часа — задачу он скорее всего не решит

в связи с нежелательностью отвлечений, важно не вторгаться в середине процесса со срочными проблемами (да ещё если ко всем)

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

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

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

моральные силы восстанавливаются но довольно медленно (на сколько помню нас учили что примерно на 5-6 часов за сутки)
на это нужно время
и ещё время нужно чтобы хоть запланировать как человек будет конкретно восстанавливаться — гулять, кататься на коньках, смотреть кино и т.п.

разработка вредит здоровью в следующих аспектах:
кровеносная система
опорнодвигательный аппарат
зрение
при этом критически важно кровоснабжение мозга, которое страдает при длительном сидении как от ухудшения тонуса сосудов, так и возможного пережимания сосудов в позвонках
человеку нужно ходить хотя бы около 8 км в день (на одно это нужно больше часа)
при проблемах со зрением могут появляться гнетущие мысли, которые будут мешать сосредоточиться

необходимость отвлекаться на отслеживание почты, и тем более отдельных сообщений в каналах
нас учили, что почту правильно проверять раз утром и раз в конце дня

сколько стоит отвлечь разработчика?
допустим он как раз кодирует сейчас уже 2 часа,
а ему следует поработать в потоке 3 часа, чтобы решить всю задачу
если в задаче нет "контрольных точек" — этапов, которые можно завершить и переходить к следующему
то в принципе потери могут составить все 2 программисто-часа

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

"никогда, ни в коем случае не делайте рабочий день программиста от звонка до звонка" (приписываю Терехову старшему)
(звонок в конце дня гарантированно собьёт контекст или не позволит начать задачу)

разработчик сможет поработать и неделю по 12 часов, но есть граница когда это приведёт к аппатии, болезням
и восстановление после такой недели займёт не 3 дня (20 дополнительных часов делить на 8), а больше

важны и тонус тела и моральные силы

бодрый и свежий программист, но у него может болеть голова

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

рекомендуется использовать обволакивающие наушники, защищающие от отвлечений в опенспейсе


средний человек может держать во внимании не очень много объектов — штук 7
отсюда структура древних военных подразделений — пятидесятники = 7х7 +1 командующий
авиадиспетчера могут держать больше всех — от 18 до 24 объектов
программисты выше среднего, но до авиадиспетчеров не дотягивают — в районе 12-15

так или иначе это выливается в предельное количество строчек/стейтментов в метода или процедуре, которое можно охватить мыслью
также предельное количество вложенных элементов в древовидной структуре, например методов в классе, хорошо ограничивать этим предельным числом самого слабого члена команды разработки
(хыхы, и избавляться от слабых звеньев, как дополнительный вывод)

то есть плохо не только метод на несколько экранов, но и больше 15 содержательных строчек
метод на несколько экранов — это грубое нарушение технологии, поскольку для восприятия потребуется локальное переключение контекста при листании страниц