Когнитивные искажения в программировании
Всем привет!
Сегодня мы поговорим о такой интересной и забавной вещи, как когнитивные искажения. Что это? Зачем это? Как с этим бороться или, быть может, их даже можно использовать? Для начала давайте разберемся, о чем же мы говорим.
Итак, когнитивные искажения. Википедия услужливо выдает такое определение: это систематические ошибки в мышлении или шаблонные отклонения, которые возникают на основе дисфункциональных убеждений, внедренных в когнитивные схемы, и легко обнаруживаются при анализе автоматических мыслей.
Очень надеюсь, что вы ничего не поняли. Если поняли, то пора отключаться, ибо вряд ли я расскажу вам что-то новое и интересное.
Для тех, кто не закрыл вкладку, объясню простыми словами.
Когнитивные искажения — это ошибки, баги или паттерны, которые возникают у нас в голове и влияют на наши поступки, суждения и решения. Обычно они легко обнаруживаются, если заниматься самоанализом и отслеживать свой мыслительный процесс.
Надеюсь, такое грубое объяснение осознать проще. Для понимания всей картины предлагаю еще посмотреть на то, откуда берутся и чем обусловлены эти звери.
Снова обратимся к Википедии. Когнитивные искажения являются примером эволюционно сложившегося поведения. Некоторые из них выполняют адаптивную функцию, поскольку способствуют более эффективным действиям или более быстрому принятию решений. Другие, по-видимому, происходят из отсутствия соответствующих навыков мышления или из-за неуместного применения навыков, бывших адаптивными в других условиях.
Ну, а теперь чуть попроще. Когнитивные искажения обусловливаются субъективными убеждениями (предубеждениями) и стереотипами, социальными, моральными и эмоциональными причинами, сбоями в обработке и анализе информации, а также физическими ограничениями и особенностями строения человеческого мозга.
Пожалуй, с теорией можно завязывать, точнее с вводной ее частью, и переходить непосредственно к искажениям.
Искажения можно разделить на 4 группы:
искажения, связанные с поведением и принятием решений;
социально обусловленные искажения;
искажения, связанные с вероятностями и стереотипами;
искажения, связанные с ошибками памяти.
Эти группы весьма условны. Многие искажения — это разные аспекты одного и того же процесса. Существуют и другие разделения. Но наша задача не заниматься группировкой, а разобраться, как искажения влияют на наши решения, поступки и суждения.
Прежде чем перейти непосредственно к искажениям, предлагаю затронуть один вопрос, который, возможно, у вас возникнет. Стоит ли бороться с искажениями? Определенно да. Но надо помнить, что, контролируя и отслеживая одни искажения, вы легко можете попасть во власть других. Надо просто о них знать и корректировать свое поведение, когда это требуется. Вы должны быть для себя умным наблюдателем и, когда искажения не играют вам на руку, одергивать себя.
Итак, поехали. Сегодня мы поговорим только об искажениях из первой группы, о тех, которые связаны с поведением и принятием решений.
Что ж, начнем!
Амплификация
Это происходит, когда мы вкладываем в достижение цели больше усилий, чем необходимо. Чрезмерно детальное планирование при объективном отсутствии данных и обилии факторов, которые влияют на результат.
Знакомо? Я думаю, да. Сюда же можно включить и, например, преждевременную оптимизацию. Кстати, методология Agile отчасти пытается бороться с этим искажением.
С одной стороны, мы как программисты должны всегда думать о последствиях тех или иных решений. Но иногда это заходит слишком далеко. И в конечном итоге можно обнаружить, что наше решение, безусловно, прекрасно, избавлено от всех недостатков, устойчиво, может применятся где угодно, только есть одна проблема: его или нет, или проект уже закрылся.
Совет: поглядывайте на часы. И если вы потратили уже немало времени на проектирование архитектуры компонента, слоя логики и т. д., остановитесь! Отбросьте мысли на тему «А что если»? Реализуйте решение, которое наиболее приемлемо здесь и сейчас. И прекратите задавать себе вопрос: «А что если?».
Опережение
Кто из нас не пытался продумать архитектуру проекта, когда еще даже ТЗ не пришло? Мы заранее строим замки, решаем, какие библиотеки возьмем, а в итоге оказывается, что надо брать совсем другое и решать все иначе. Но усилия уже потрачены. Энергия ушла в никуда.
Совет: всему свое время и место. Глупо возводить стены, когда не залит фундамент. Каждый раз, когда принимаетесь за какую-то задачу, задайте себе вопрос: «А достаточно ли исходных данных для реализации я имею?». Бежать впереди паровоза, наверное, круто и иногда весело, но в итоге вы все равно споткнетесь, а 85 тонн — это 85 тонн, и просто так они не остановятся.
Уклон в сторону поиска информации
Начинаете гуглить проблему. Находите решение, но все же хотите посмотреть еще пару ссылок по теме. А через три дня вы понимаете, что кроличья нора была слишком глубока…
Совет: нужно вовремя остановиться. Отслеживайте время, потраченное на поиск информации. Как только информации достаточно для решения задачи, останавливайте поиск. Иначе вы закончите чтением спецификации по обработке процессором исполняемых команд.
Феномен Баадера-Майнхоф или иллюзия частотности
Нам начинает попадаться на каждом шагу то, что в текущий момент занимает наши мысли. Например, может показаться, что какой-то фреймворк или решение пользуется большой популярностью. Это, кстати, работает и в обычной жизни. Решили купить себе какую-то машину, и вот — кругом в городе только на них все и ездят.
Совет: старайтесь принимать во внимание статистику. Взгляните, а сколько других решений в подборке материалов, которые вы открыли на «Хабре»? Сколько вокруг других машин, кроме той, на которую вы обратили внимание? Нужно помнить, что наше восприятие субъективно, и стараться найти объективные показатели.
Отклонение в сторону результата
Это то, чем мы грешим, когда получаем код в наследство от других разработчиков. На самом деле тут сразу несколько когнитивных искажений, но об остальных мы поговорим позже. Как правило восклицание после знакомства с проектом выглядит примерно так:»***************************************************************************!».
Простите, пришлось зацензурить.
Так вот, мы обычно смотрим на результат, не принимая во внимание обстоятельства, при которых было принято то или иное решение. А это может быть: плохое ТЗ, невнятная постановка задачи, нехватка времени, отсутствие на тот момент готовых, хороших и проверенных решений. Разумеется, не факт. Может, там и правда просто студенты журфака код писали. Такое тоже не исключено. (Ничего не имею против студентов журфака, среди них, вероятно, тоже есть толковые программисты.)
Совет: каждый раз, прежде чем оценить результат, постарайтесь понять, как и при каких обстоятельствах он был получен. Только после этого вы будете иметь хоть какое-то моральное право сказать: «Ужас ужасный! Я бы такого ни за что не наворотил».
Ну что, знакомые ловушки? Уверен, многие из вас попадались в них не раз и не два, порой даже не замечая подвоха. И это лишь малая часть тех граблей, что заботливо разбросаны по полям нашего сознания. О других, не менее интересных, я расскажу вам в следующей статье. До встречи!
