Почему мы так яростно защищаем код, который написали сами, даже когда он очевидно плох?
Моя позиция про когнитивное искажение в виде Эффект IKEA и эффекта владения - в тему публикации, а у вас похоже было направление в сторону позиции, где разработчик защищает не поэтому, а потому что он свой код понимает гораздо лучше, чем окружающие.
Я рада итогу, и полагаю, что обе ситуации возможны. Главно не путать одно с другим и стараться избегать чрезмерной привязанности к коду, если она мешает находить лучшие решения. Ну, или хотя бы быть осознанными в своём упрямстве :)
Кажется, мы почти пришли к общему пониманию:) Получается, что чем больше у разработчика опыта и реализованных решений, тем легче ему признавать ошибки? Эффект IKEA и похоже на эффект владения (Endowment Effect), когда у человека мало идей (или опыта), он оценивает каждую из них намного выше, чем она того объективно стоит и человек слишком привязывается к своему коду. Как вы думаете, можно ли как-то тренировать открытость к новым решениям?
Согласна, защищают не потому, что обидчивые и озлобленные дегенераты – впрочем, я такого и не писала. В целом, в командной работе важно, чтобы все понимали, что и зачем мы делаем. Если разработчик хороший кодер, но плохо объясняет, задача лидера – выудить из него весомые аргументы, понять и убедительно изложить их команде. Лидер может сам быть не согласен – из-за разницы в скиллах или бизнес-ограничений (например, требований использовать только проверенные решения). Во втором случае либо команда берёт время на тестирование и сбор доказательств эффективности, либо следует за "миллионами мух", если сроки не позволяют.
У меня был другой опыт: часто код потом использовать не стали, но это отдельные истории. И получается, на примере каждой, как раз когнитивные искажения могли влиять на то восприятие автора, мешая объективно оценивать альтернативные решения и заставляли вставать в оборону и защищать ПД даже на аргументированные критические замечания. В следующей части статьи ожидаю прочесть рекомендации о том, как сбалансировать уверенность в своём коде и открытость к улучшениям. Плюс в карму уже поставила 🙂
Отличная статья. Дьявол как всегда в деталях и часто они не на поверхности, и в мышлении. Особенно понравилось про
Почему мы так яростно защищаем код, который написали сами, даже когда он очевидно плох?
Может и неочевидно, а при объективной оценке заметно, но это факт, и большинство яростно защищают собственное решение, воспринимая обоснованную критику как личное оскорбление или по другим защитным причинам не принимают ее.
Спасибо за разъяснение с точки зрения когнитивного искажения, это интересно.
Как упоминалось в статье, прежде чем приступать, нужно многое обдумать. Эта рекомендация полезна не только для новичков в автоматизации. Если товар находится не в тестовой базе данных или копии продакшена, я рекомендую на ретроспективе задать вопрос «почему», предложить и обсудить возможные улучшения. Тем не менее, ваш отзыв помогает сделать материал полезнее и понятнее для начинающих автоматизаторов, за что вам огромное спасибо.
Благодарю за комментарий 🙂 Другие авторы наверняка не менее интересно рассказывают и на примерах, которые вас интересуют. Рекомендую воспользоваться поиском по сайту — значок «лупа» в правом верхнем углу, он первый слева направо.
Статья для начинающих автоматизаторов, и я старалась донести мысль не начинать покрытие с UI‑тестов, а пирамида тестирования — это базовая концепция, которая помогает расставить приоритеты и найти баланс между уровнями.
Считаю, что пирамида работает. Другое дело, что юнит‑тесты часто не пишут от простого отсутствия задачи и отсутствия такой привычки у разработчиков — как, например, ставить висячую запятую в JS‑объектах, не пишут при нехватке времени, которое компания закладывает в ресурсы, но стоит отметить, что тоже часто — на основании оценки разработчика, ведь тот сам рассчитывает время при планировании реализации задачи и др. Тем не менее, вы правы, подходы к тестированию зависят от контекста и специфики проекта. Если проект позволяет больше полагаться на API‑тесты, это здорово. Но, как мне кажется, полностью отказываться от юнит‑тестов не стоит — хотя бы для покрытия критически важных частей кода. Спасибо за ваш комментарий — он подчеркивает, что в тестировании как везде, успех реализации зависит от гибкости и осознанного подхода.
Сравнивался ток рост популярности за год — старички в професси продолжают развиваться изучая новый для себя питон и молодые выбирают изучать пайтон, но не факт, что станут специалистами, а тем временем, джава с джаваскриптом, рнр и др. сидят на своих местах что заняли давно и тоже в росте пользователей не останавливаются.
Обычно работают с тестовой копией базы данных, чтобы исключить внешние изменения, поэтому не понимаю пока, зачем удалять товар, что используется в тестировании. Если вам подходит, можно еще согласовать сценарий, при котором перед началом теста отправляется POST‑запрос на создание товара, затем использовать его URL, а в постусловии удалять созданный товар, чтобы не засорять базу данных. Тогда у вас будет гарантированно свежий и рабочий URL при каждом запуске. Главное — правильная стратегия и постепенное улучшение процессов.
Уходили еще как))
Почему мы так яростно защищаем код, который написали сами, даже когда он очевидно плох?
Моя позиция про когнитивное искажение в виде Эффект IKEA и эффекта владения - в тему публикации, а у вас похоже было направление в сторону позиции, где разработчик защищает не поэтому, а потому что он свой код понимает гораздо лучше, чем окружающие.
Я рада итогу, и полагаю, что обе ситуации возможны. Главно не путать одно с другим и стараться избегать чрезмерной привязанности к коду, если она мешает находить лучшие решения. Ну, или хотя бы быть осознанными в своём упрямстве :)
Кажется, мы почти пришли к общему пониманию:) Получается, что чем больше у разработчика опыта и реализованных решений, тем легче ему признавать ошибки? Эффект IKEA и похоже на эффект владения (Endowment Effect), когда у человека мало идей (или опыта), он оценивает каждую из них намного выше, чем она того объективно стоит и человек слишком привязывается к своему коду. Как вы думаете, можно ли как-то тренировать открытость к новым решениям?
Согласна, защищают не потому, что обидчивые и озлобленные дегенераты – впрочем, я такого и не писала. В целом, в командной работе важно, чтобы все понимали, что и зачем мы делаем. Если разработчик хороший кодер, но плохо объясняет, задача лидера – выудить из него весомые аргументы, понять и убедительно изложить их команде. Лидер может сам быть не согласен – из-за разницы в скиллах или бизнес-ограничений (например, требований использовать только проверенные решения). Во втором случае либо команда берёт время на тестирование и сбор доказательств эффективности, либо следует за "миллионами мух", если сроки не позволяют.
У меня был другой опыт: часто код потом использовать не стали, но это отдельные истории. И получается, на примере каждой, как раз когнитивные искажения могли влиять на то восприятие автора, мешая объективно оценивать альтернативные решения и заставляли вставать в оборону и защищать ПД даже на аргументированные критические замечания. В следующей части статьи ожидаю прочесть рекомендации о том, как сбалансировать уверенность в своём коде и открытость к улучшениям. Плюс в карму уже поставила 🙂
Отличная статья. Дьявол как всегда в деталях и часто они не на поверхности, и в мышлении. Особенно понравилось про
Может и неочевидно, а при объективной оценке заметно, но это факт, и большинство яростно защищают собственное решение, воспринимая обоснованную критику как личное оскорбление или по другим защитным причинам не принимают ее.
Спасибо за разъяснение с точки зрения когнитивного искажения, это интересно.
Спасибо, что обратили внимание, это моя ошибка - кликнула хаб, а в статье про веб-сборку WASM действительно ничего нет. Уже поправила👌
Как упоминалось в статье, прежде чем приступать, нужно многое обдумать. Эта рекомендация полезна не только для новичков в автоматизации. Если товар находится не в тестовой базе данных или копии продакшена, я рекомендую на ретроспективе задать вопрос «почему», предложить и обсудить возможные улучшения. Тем не менее, ваш отзыв помогает сделать материал полезнее и понятнее для начинающих автоматизаторов, за что вам огромное спасибо.
fallback, статистика, аналитика, добрые отношения с бэкендером и будет нам счастье:)
Благодарю за комментарий 🙂
Другие авторы наверняка не менее интересно рассказывают и на примерах, которые вас интересуют. Рекомендую воспользоваться поиском по сайту — значок «лупа» в правом верхнем углу, он первый слева направо.
Статья для начинающих автоматизаторов, и я старалась донести мысль не начинать покрытие с UI‑тестов, а пирамида тестирования — это базовая концепция, которая помогает расставить приоритеты и найти баланс между уровнями.
Считаю, что пирамида работает. Другое дело, что юнит‑тесты часто не пишут от простого отсутствия задачи и отсутствия такой привычки у разработчиков — как, например, ставить висячую запятую в JS‑объектах, не пишут при нехватке времени, которое компания закладывает в ресурсы, но стоит отметить, что тоже часто — на основании оценки разработчика, ведь тот сам рассчитывает время при планировании реализации задачи и др. Тем не менее, вы правы, подходы к тестированию зависят от контекста и специфики проекта. Если проект позволяет больше полагаться на API‑тесты, это здорово. Но, как мне кажется, полностью отказываться от юнит‑тестов не стоит — хотя бы для покрытия критически важных частей кода. Спасибо за ваш комментарий — он подчеркивает, что в тестировании как везде, успех реализации зависит от гибкости и осознанного подхода.
Сравнивался ток рост популярности за год — старички в професси продолжают развиваться изучая новый для себя питон и молодые выбирают изучать пайтон, но не факт, что станут специалистами, а тем временем, джава с джаваскриптом, рнр и др. сидят на своих местах что заняли давно и тоже в росте пользователей не останавливаются.
Обычно работают с тестовой копией базы данных, чтобы исключить внешние изменения, поэтому не понимаю пока, зачем удалять товар, что используется в тестировании. Если вам подходит, можно еще согласовать сценарий, при котором перед началом теста отправляется POST‑запрос на создание товара, затем использовать его URL, а в постусловии удалять созданный товар, чтобы не засорять базу данных. Тогда у вас будет гарантированно свежий и рабочий URL при каждом запуске. Главное — правильная стратегия и постепенное улучшение процессов.
Code seams и правильнее наверное было написать инъекции зависимостей? Спасибо, что обратил внимание.
Code seams и наверное правильнее было написать инъекции зависимостей? Спасибо, что обратил внимание.