Комментарии 18
Когнитивная лягушка, часть I. C+++. Раст 😏😌🎉🙏
Мне кажется, что вы не там ищете ответы. Всё намного проще и если вооружиться бритвой Оккама, то места для когнитивных искажений не останется
Почему опытные разработчики создают переусложненные системы, которые никто не может поддерживать?
Потому что на старте проекта разработчики представляли себе архитектуру иначе, а после многочисленных смен парадигм и требований не было выделено достаточного времени для рефакторинга архитектуры.
Почему команды упорно продолжают использовать устаревшие технологии, когда существуют более эффективные альтернативы?
Потому что альтернативы несут в себе риски, которые сейчас не видны. Здесь есть другой ответ и он вам не понравится: потому что альтернативы не очень-то более эффективны.
Почему мы так яростно защищаем код, который написали сами, даже когда он очевидно плох?
Потому что он работает. Потому, что в него вложено очень много человеко-часов. В написание, переписывание, отладку.
Почему 90% команд разработки регулярно не укладываются в сроки, несмотря на всё более изощренные методологии планирования?
Потому что реально можно оценить лишь видимую часть работы. Так получается, что сложные задачи имеют подводную часть. И какая она по объёму - предсказать невозможно.
Я бы еще раз прошелся бритвой, даже по вашей блистательной выжимке.
Почему срывают сроки?
Потому что люди, определившие эти сроки — некомпетентны.
Я никогда не поверю в названную в часах цифру, я верю только в трипл «оптимистичный сценарий, пессимистичный сценарий, страховка». Где страховка напрямую зависит от уровня компетенции команды в данной задаче, а пессимистичный сценарий учитывает и называет все потенциальные подводные камни.
Потому что люди, определившие эти сроки — некомпетентны.
А может, девелопер, который делает оценку, не только оптимистичную, сколько оценивает чисто кодинг? Добавьте всякое про уточнение ТЗ, зависимости, тестирование и деплой - получится то, что в реальности?
последний пункт и бритва оккама, я с вами солидарен, очень важно показывать ) в этом случае 3д картинку, еще добавлю ( на чем был написан майнкрафт и в каком году) ), сегодня после опыта Анриала наверно никто и не поверит на чем )
Если ничего не понятно то я говорю срок 10х, а если кто-то не согласен с оценкой, то я предлагаю сделать это самому. Грубо, но работает. Тогда мне предлагают исследовать вопрос, уточнить сроки... Стадия торга)
Опыт показывает, что изначально неточная постановка задачи, рекурсивная реализация и уточнение задачи сильно увеличивает риски переделок с нуля и в среднем а разы увеличивает срок реализации. Не экономьте на уточнении задачи, на аналитике, на архитектуре. Если только это не совсем типовая задача. Постепенное уточнение требований работает только если заказчик совсем ничего не знает и скажет только глядя на работающее демо.
Когда мы сталкиваемся с информацией, противоречащей нашим убеждениям, активируются те же области мозга, что и при физической угрозе, вызывая защитную реакцию.
Я видел несколько другую инфу: исследования показали, что убеждения (т.е. чисто ментальные конструкции) воспринимаются мозгом примерно так же, как материальные блага. И при атаке на убеждения активируются те же механизмы мозга, что и при посягательстве на имущество.
"Наша самописная ORM работает уже 5 лет, зачем её менять?"
Но и правда, зачем?
Отличная статья. Дьявол как всегда в деталях и часто они не на поверхности, и в мышлении. Особенно понравилось про
Почему мы так яростно защищаем код, который написали сами, даже когда он очевидно плох?
Может и неочевидно, а при объективной оценке заметно, но это факт, и большинство яростно защищают собственное решение, воспринимая обоснованную критику как личное оскорбление или по другим защитным причинам не принимают ее.
Спасибо за разъяснение с точки зрения когнитивного искажения, это интересно.
Люди защищают свой код не потому, что они обидчивые и озлобленные дегенераты, а потому, что они его понимают гораздо лучше, чем окружающие, а окружающие слишком часто апеллируют не к бенчмаркам или другим измеряемым количественным характеристикам, а к авторитету и «миллионы мух, использующих библиотеку от гугла, не могут ошибаться».
Согласна, защищают не потому, что обидчивые и озлобленные дегенераты – впрочем, я такого и не писала. В целом, в командной работе важно, чтобы все понимали, что и зачем мы делаем. Если разработчик хороший кодер, но плохо объясняет, задача лидера – выудить из него весомые аргументы, понять и убедительно изложить их команде. Лидер может сам быть не согласен – из-за разницы в скиллах или бизнес-ограничений (например, требований использовать только проверенные решения). Во втором случае либо команда берёт время на тестирование и сбор доказательств эффективности, либо следует за "миллионами мух", если сроки не позволяют.
У меня был другой опыт: часто код потом использовать не стали, но это отдельные истории. И получается, на примере каждой, как раз когнитивные искажения могли влиять на то восприятие автора, мешая объективно оценивать альтернативные решения и заставляли вставать в оборону и защищать ПД даже на аргументированные критические замечания. В следующей части статьи ожидаю прочесть рекомендации о том, как сбалансировать уверенность в своём коде и открытость к улучшениям. Плюс в карму уже поставила 🙂
как сбалансировать уверенность в своём коде и открытость к улучшениям
У Сомерсета Моэма в «Подводя итоги» было прекрасное описание примерно этого случая (применительно к театральным режиссёрам с позиции драматурга, цитата по памяти): «Режиссёр — очень опасный человек. У него есть идеи. Но их настолько мало, что в каждую из них он вцепляется мёртвой хваткой».
Когда идей и собственного кода много — совершенно не жалко признать одну из них неудачной и выбросить её вместе с кодом в мусорное ведро. А вот когда эта идея — единственная…
:)
Кажется, мы почти пришли к общему пониманию:) Получается, что чем больше у разработчика опыта и реализованных решений, тем легче ему признавать ошибки? Эффект IKEA и похоже на эффект владения (Endowment Effect), когда у человека мало идей (или опыта), он оценивает каждую из них намного выше, чем она того объективно стоит и человек слишком привязывается к своему коду. Как вы думаете, можно ли как-то тренировать открытость к новым решениям?
Кажется, мы почти пришли к общему пониманию
Кажется, мы от него никуда и не уходили.
можно ли как-то тренировать открытость к новым решениям?
Конечно. Есть два пути, оба сформулированы Сергеичем двести лет назад:
опыт, сын ошибок трудных
гений, парадоксов друг
Есть люди, и с некоторыми из них мне посчастливилось быть знакомым, которым это золотое качество даётся чуть ли не с молоком матери. Их тренировать не нужно. Они и так искренне рады, когда ошибаются — возможно, от доминирующей редкости самого явления, возможно — просто в силу повышенной эмпатии.
А тренировать — можно только опытом (ну, из известных мне способов). Первое самостоятельное решение нужно хвалить, второе — мягко критиковать, а третье и последующие 10-20 — выбрасывать в урну.
Меня часто в самых разных коллективах спрашивают: как стать хорошим разработчиком? — Я всегда отвечаю: «Это несложно. Нужно написать сто тысяч строк отвратительного кода и без сожаления выбросить их все в корзину.»
100 000 это мало, особенно если выбрсывать. Нужно скорее 500 000
Кажется, мы почти пришли к общему пониманию
Кажется, мы от него никуда и не уходили.
Уходили еще как))
Почему мы так яростно защищаем код, который написали сами, даже когда он очевидно плох?
Моя позиция про когнитивное искажение в виде Эффект IKEA и эффекта владения - в тему публикации, а у вас похоже было направление в сторону позиции, где разработчик защищает не поэтому, а потому что он свой код понимает гораздо лучше, чем окружающие.
Я рада итогу, и полагаю, что обе ситуации возможны. Главно не путать одно с другим и стараться избегать чрезмерной привязанности к коду, если она мешает находить лучшие решения. Ну, или хотя бы быть осознанными в своём упрямстве :)
Ну вот, оказывается, если не на то сообщение ответить, то даже удалить этот ответ нельзя, только отредактировать. Так и будет теперь болтаться ни к селу ни к городу ответ.
Психология разработки: как когнитивные искажения влияют на архитектурные решения и качество кода (часть 1)