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

Некоторые люди кажутся более способными противостоять этому, чем другие. У Чарли Мангера, партнера-инвестора Уоррена Баффета, есть список 24 стандартных причин человеческих заблуждений. Тема когнитивных искажений популярна среди разработчиков программного обеспечения, поскольку они пытаются заставить свой мозг вести себя как машины, которыми они пользуются.

Мы не рациональны, но иногда нам нужно быть ими.

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

Это понятно. Мы все становимся подчиненными нашему внутреннему иррациональному технологу. Вместо того, чтобы быть рациональным, выходить на улицу и находить факты, принимать решения, основанные на фактах, это отвратительное предубеждение принимает решения, основанные на тенденциях, анекдотах и ​​политике.

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

Вот что происходит:

Кто-то должен принять решение. Какой фреймворк будем использовать? Какая CMS? Достаточно ли хороша наша CRM? Какой хостинг «лучший»?

Рациональный технолог поймет, что делает эта технология, и определит компромиссы в решении. Иррациональный технолог будет искать «лучший» выбор, игнорируя тот факт, что вы идете на компромисс.

Каждое решение и нерешительность, которые мы принимаем, влияют на будущее и на компромиссы, которые, вероятно, коснутся всей команды и даже пользователей. Скорость реализации, отладки, развертывания и обучения — все это факторы выбора платформы. Различия, скажем, между Rails и Django в большинстве случаев могут быть не такими большими, но в некоторых случаях они будут больше. А при восприятии скорости зачастую проще уловить тренд, чем объективно взвесить варианты.

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

И я отношу себя к «инженерам». Мы все сделали это. Делимся с группой:

Переуправление: сделайте противоположное тому, что только что пошло не так.

Помните, когда вы впервые попробовали гоночную игру от первого лица? Все переусердствуют, все время. Требуется добрых 10 или 20 аварий, прежде чем вы научитесь не переруливать.

Проблема в том, что, будучи техническими архитекторами, мы не сталкиваемся с 10 или 20 сбоями в одной и той же среде, поэтому почти в каждом проекте мы преувеличиваем.

Давайте использовать что-то не такое «сложное» (без дополнительных объяснений). Давайте заранее проведем рефакторинг (который я называю «префакторинг»). Давайте получим 100% покрытие TDD.

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

Обучение на рабочем месте

Помните, когда вы изучали свой первый язык программирования или фреймворк? Это займет меньше времени, чем в прошлый раз, когда вы пытались обучаться на рабочем месте, потому что на рабочем месте (в некоторых организациях) вы не можете просто учиться. Вы не можете выбросить код.

Эта вредная привычка приводит к тому, что «новое» приравнивается к «трудному для изучения», а затем вы сужаете доступные варианты. Конечно, будьте прагматичны в том, что вы можете узнать, но в то же время прагматично относитесь к тому, как вы учитесь.

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

Выбор акций. Или: это в тренде на Hacker News, Github…

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

И это нормально, если вы понимаете, что популярность определяет доступные ресурсы, а не то, насколько технология вам подходит.

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

Решение без принятия решения

Аргх, чувак. Это действительно больно, потому что съедает время и ни к чему не приводит. Это проявляется несколькими способами:

Синдром нового человека: кто-то присоединяется и приносит новую технологию, которая принимается без вопросов. Это хорошо, но если это ваш подход, создайте постоянно меняющийся пул экспертов и фрилансеров, чтобы максимизировать процент попаданий.

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

Синдром отказа в последнюю минуту: Хуже всего, когда что-то просто нужно сделать, и кто-то выбирает что-то, потому что ему нужно что-то выбрать. Иногда это может быть хорошо; это побуждает вас добиваться цели.

Социальное доказательство: потому что сказал Боб. Обращение к конкретным людям за решением, а не копание в причинах, стоящих за ним, означает, что никто на самом деле не уверен, почему это хорошее решение. Побочным продуктом является то, что этих людей поощряют оставаться «в безопасности» и не пробовать новые вещи.

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

Первые 80 % выброса дофамина

Помните наш проект, в котором настройка базы данных была сложной? Я только что попробовал framework X, и я могу сделать это примерно за 5 минут. Мы должны использовать это.

Новые вещи, как правило, решают основную трудную проблему старых вещей, но это не значит, что они решают все остальные проблемы. Досадно, что вы в конечном итоге сталкиваетесь с противоположными аргументами: это решает 80% старых вещей, а может не решить остальные 20% и может создать новые проблемы.

Это приведет к непринятию решения, поэтому сядьте, проанализируйте его и примите твердое решение.

Мы даже не знаем, что строим

Это, кажется, корень большинства проблем выбора технологии. ИТ-специалистам сказали, что отделу маркетинга нужна CRM, поэтому они оценивают несколько. Или агентство просят создать инструмент управления проектами, и они его продвигают.

Кто-то должен быть уверен, что сочетание технологий решает проблему, а не просто накладывает штукатурку на то, что есть.

То же самое верно для фреймворков, библиотек, баз данных.

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

Шаг к рациональности

Какие плохие дефолты и когнитивные искажения вы встречали? Каковы ваши решения по этому поводу, или вы просто считаете это экспериментом?

Мы хотим помочь вам принимать более эффективные решения в отношении программного обеспечения. http://thebaseline.co