TL;DR мы ждем поставок LCD экранов для начала массового производства. Поставщик обещает доставить экраны в конце сентября, и как только мы их получим, сможем начать массовое производство.

Все что не позволяет нам запустить массовое производство — это отсутствие комплектующих из-за кризиса полупроводников. Подробнее об этом можно почитать в прошлой публикации. Мы не можем на это повлиять напрямую, и поэтому пока полностью сфокусировались на разработке прошивки и мобильных приложений.

• Ответы на главные вопросы
• Прошивка Flipper Zero теперь доступна на Github
• Утилиты для обновления прошивки
• Независимые обзоры Флиппера

Удивительно, но некоторые разработчики до сих пор считают, что коммуникации в работе не нужны или даже вредны. «Наша задача кодить, а не болтать». Конечно это эффективнее некуда, сидеть три часа и пытаться самостоятельно разобраться, как работает соседний сервис, вместо того чтобы просто спросить у коллеги и получить ответ за 15 минут. Или додумывать за ПО спорные моменты в задаче, а потом выкинуть 90 % работы и переделать заново после первого демо. Или не услышать или не понять критику на обсуждении технического решения, а потом переделывать, костылить, велосипедить и получать критические ошибки и блокеры в середине спринта. Или начать сразу разрешать инцидент, не рассказав про него владельцу продукта и бизнесу, и получить тонны негативной обратной связи от клиентов и бизнеса. Или внезапно узнать, что можно было бы обойтись меньшей кровью, ничего не разрабатывая, а решив проблему административными методами.

Ваша задача — приносить пользу. И самый лучший разработчик — тот, который может решить проблему, не программируя вообще.

Про когнитивные искажения много пишут и много говорят.

Однако всегда не хватало более чёткого понимания, как именно это влияет на профессиональную деятельность, мою и моих коллег. Какие решения я как тимлид и программист принимаю неправильно. Что мне подправить, на что обратить внимание.

Поэтому я решил взять справочник когнитивных искажений и поискать примеры из реальной IT-жизни по каждому пункту.

Если вам интересно, добро пожаловать под кат.

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

Несмотря на то, что технологии модульного тестирования существуют уже 30 лет (в 1989 году Кент Бек написал статью “Simple Smalltalk Testing: With Patterns”), тем не менее не все программисты владеют этой технологией и не все компании сделали автоматическое тестирование частью своей корпоративной культуры. Даже несмотря на очевидные преимущества автоматического тестирования, все равно поведенческое сопротивление достаточно сильное. Кто пробовал внедрять автоматические тесты, тот знает, что всегда найдется какая-то причина, почему это не удалось сделать.

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

Все возражения я сгруппировал в пирамиду надежного программирования, которая включает четыре уровня: