написание кода в «состоянии потока» обходится очень-очень дорого, как по времени на отладку, так и по количеству багов
если компания провоцирует впадать в «состояние потока», то тем самым замедляет работы над проектами. Буквально в разы увеличивая его себестоимость по деньгам и срокам или же в разы снижая качество, получая в результате бажное нечто.
объяснение этому явлению ещё не найдено.
Психика имеет свойство заниматься самообманом и подменой воспринимаемой реальности. Видимо, в состоянии потока выключается критичность — человек перестаёт замечать косяки. Скорее всего, подсознание выключает их восприятие, чтобы не ломать сознанию ощущение драйва.
Требую продолжения обсуждения. Ведь это же круче, чем про котиков и изоленту!
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Требую продолжения обсуждения. Ведь это же круче, чем про котиков и изоленту!
А что тут обсуждать? Всё верно Я два раза впадал в такое состояние. Всё как и сказано: в одном случае все смеялись при кодеревью, во втором случае получился код с кучей детских багов.
Было это N лет назад, сейчас я лучше пойду отдохну и обдумаю всякое, чем загоняться над "здесь и сейчас".
написание кода в «состоянии потока» обходится очень-очень дорого, как по времени на отладку, так и по количеству багов
ЭФ>
если компания провоцирует впадать в «состояние потока», то тем самым замедляет работы над проектами. Буквально в разы увеличивая его себестоимость по деньгам и срокам или же в разы снижая качество, получая в результате бажное нечто.
ЭФ>
объяснение этому явлению ещё не найдено.
ЭФ>Психика имеет свойство заниматься самообманом и подменой воспринимаемой реальности. Видимо, в состоянии потока выключается критичность — человек перестаёт замечать косяки. Скорее всего, подсознание выключает их восприятие, чтобы не ломать сознанию ощущение драйва.
ЭФ>Требую продолжения обсуждения. Ведь это же круче, чем про котиков и изоленту!
Состояние потока это предельная концентрация на задаче, выше просто быть не может. Объяснение уже давно найдено.
В состоянии потока ничего не выключается, наоборот — включается всё, что нужно. А вот если уровень кодинга низкий, то это проявится во всей красе, т.к. в состоянии потока максимальная продуктивность.
Если человек привык игнорировать важные вещи, то и в состоянии потока будет ровно то же — привычки сохраняются.
Странно противопоставлять критику и творчество. Это вобщем одно и то же. Критика это и синтез. Т.е. моделируем некоторую реальность, наблюдаем, делаем выводы. Критика это и анализ — выделаем некоторый аспект, рассматриваем его, делаем выводы. И то, и другое есть создание чего то нового, чего ранее не было.
Здравствуйте, Rhino, Вы писали:
R>Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>>Требую продолжения обсуждения. Ведь это же круче, чем про котиков и изоленту! R>А что тут обсуждать? Всё верно Я два раза впадал в такое состояние. Всё как и сказано: в одном случае все смеялись при кодеревью, во втором случае получился код с кучей детских багов. R>Было это N лет назад, сейчас я лучше пойду отдохну и обдумаю всякое, чем загоняться над "здесь и сейчас".
Ты путаешь состояние потока, т.е. максимально достижимая концентрация на задаче, и работу в духе "побыстрее закончить".
Здравствуйте, Ikemefula, Вы писали:
I>Ты путаешь состояние потока, т.е. максимально достижимая концентрация на задаче, и работу в духе "побыстрее закончить".
Да, согласен. Ща вспоминал как всё было...
Извиняюсь, мой косяк.
Здравствуйте, namespace, Вы писали:
ЭФ>>Требую продолжения обсуждения. Ведь это же круче, чем про котиков и изоленту! N>Требую ссылку на начало обсуждения.
Нечего там обсуждать. Люди путают состояние потока и чад кутежа и угар работы под адреналином в спешке.
Здравствуйте, Эйнсток Файр, Вы писали:
IT>> Если разработчик одержим идиотскими идеями и у него кривые руки, то в состоянии потока это всё многократно усиливается.
ЭФ>Это же отлично для фирмы, можно быстро выявлять криворуких разработчиков. ЭФ>В чём проблема?
В том, что если не уследить, то за пару месяцев такой разработчик в состоянии потока способен нанести непопровимые разрушения на проекте, которые потом годами придётся выпиливать.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Эйнсток Файр, Вы писали:
IT>> Если разработчик одержим идиотскими идеями и у него кривые руки, то в состоянии потока это всё многократно усиливается.
ЭФ>Это же отлично для фирмы, можно быстро выявлять криворуких разработчиков. ЭФ>В чём проблема?
1 в цене ошибки — зависит от области применения софта
2 в ответе на вопрос "что такое качество" — нет способа узнать, сколько неизвестных ошибок ушло в продакшн и какова разрушительность этих ошибок.
Пример — Если цена ошибки — человеческая жизнь(жизнеобеспечение, управление самолетом и тд), то ты узнаешь, что разработчик криворук после X смертей.
Другой пример — Если бизнес попроще, скажем, трейдинг, то узнаешь после того, как твоя контора ушла с молотка.
ЭФ>Идеальный вариант — никаких расходов на дорогу, все разработчики в одном месте, ЭФ>плюс экономия на аренде.
И при чем здесь состояние потока ?
ЭФ>Плохо кодишь — рраз и на улицу.
Проблема в том, что ошибки, который внес конкретный сотрудник остались в софте. И как правило ходить по этим граблям приходится очень долго.
ЭФ>Ну и совместное использование инфраструктуры: ЭФ>- переговорные ЭФ>- другие комнаты (или актовые залы) ЭФ>для того, чтобы проводить встречи с кем либо.
IT>В том, что если не уследить, то за пару месяцев такой разработчик в состоянии потока способен нанести непопровимые разрушения на проекте, которые потом годами придётся выпиливать.
Если за пару месяцев работы в компании никто не заметит "непопровимые разрушения", созданные одним человеком, то может этой конторе имеет смысл заняться организацией процессор разработки, а не валить все на одного человека...
I>1 в цене ошибки — зависит от области применения софта I>2 в ответе на вопрос "что такое качество" — нет способа узнать, сколько неизвестных ошибок ушло в продакшн и какова разрушительность этих ошибок. I>Пример — Если цена ошибки — человеческая жизнь(жизнеобеспечение, управление самолетом и тд), то ты узнаешь, что разработчик криворук после X смертей. I>Другой пример — Если бизнес попроще, скажем, трейдинг, то узнаешь после того, как твоя контора ушла с молотка.
Если в результате ошибки одного программиста компания обанкротится, то туда ей и дорога. Глядишь в следующий раз чуть сильнее озаботятся более надежными процессами управления разработкой.
Здравствуйте, Masterspline, Вы писали:
I>>Пример — Если цена ошибки — человеческая жизнь(жизнеобеспечение, управление самолетом и тд), то ты узнаешь, что разработчик криворук после X смертей. I>>Другой пример — Если бизнес попроще, скажем, трейдинг, то узнаешь после того, как твоя контора ушла с молотка.
M>Если в результате ошибки одного программиста компания обанкротится, то туда ей и дорога. Глядишь в следующий раз чуть сильнее озаботятся более надежными процессами управления разработкой.
Ага, через X смертей и банкротств. Хороший такой способ. А ну как это будет твоя компания и твоя смерть ? Готов заплатить такую цену за улучшение процессов ?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Требую продолжения обсуждения. Ведь это же круче, чем про котиков и изоленту!
Напомнило как недавно пришлось искать баг в функции длиной в 500 строк кода, в которой было 250 (двести пятьдесят) переменных. Вот уж точно — без состояния потока такого наворотить вряд ли получилось бы.
Здравствуйте, migun, Вы писали:
ЭФ>>Требую продолжения обсуждения. Ведь это же круче, чем про котиков и изоленту! M>Напомнило как недавно пришлось искать баг в функции длиной в 500 строк кода, в которой было 250 (двести пятьдесят) переменных. Вот уж точно — без состояния потока такого наворотить вряд ли получилось бы.
Состояние потока здесь ни при чем. Такое обычно получается или многократными правками в резное время и даже разными людьми, или разво — один особо упоротый проявляет себя во всей красе — просто по другому не получается.
Здравствуйте, migun, Вы писали:
M>Напомнило как недавно пришлось искать баг в функции длиной в 500 строк кода, в которой было 250 (двести пятьдесят) переменных. Вот уж точно — без состояния потока такого наворотить вряд ли получилось бы.
Как-то до хрена переменных. Или, скорее, строк маловато. В функции на 5000 строк 250 переменных могут жить. А в 500 получается объявлений едва ли не больше, чем кода. Если, конечно, это не Фортран и не PL/1, где переменных вообще объявлять не нужно.
Здравствуйте, Privalov, Вы писали:
M>>Напомнило как недавно пришлось искать баг в функции длиной в 500 строк кода, в которой было 250 (двести пятьдесят) переменных. Вот уж точно — без состояния потока такого наворотить вряд ли получилось бы.
P>Как-то до хрена переменных. Или, скорее, строк маловато. В функции на 5000 строк 250 переменных могут жить. А в 500 получается объявлений едва ли не больше, чем кода. Если, конечно, это не Фортран и не PL/1, где переменных вообще объявлять не нужно.
Справедливо. В этом чуде много "{{{" и "}}}" и объявлений по несколько переменных на строку. Если натравить туда clang-format с разумным конфигом, то до 1000-1500 строк она легко может увеличиться.
Я два раза впадал в такое состояние. Всё как и сказано: в одном случае все смеялись при кодеревью, во втором случае получился код с кучей детских багов.
Если нам не помогут, то мы тоже никого не пощадим.
