Критическое мышление

Ментальные модели IT-инженера

Чем опытнее инженер, тем реже он пишет код - и тем больше времени тратит на мышление. Ментальные модели - это то, что отличает «человека, который просто делает» от «человека, который понимает, что и почему».

  • Илон Маск использует First Principles для снижения стоимости ракет
  • Чарли Мангер (Berkshire Hathaway) использует набор из 100+ ментальных моделей для инвестиционных решений
  • Инверсия - core часть процесса pre-mortem в Amazon (working backwards)

Предварительные знания

  • Argumentation: Logic vs Rhetoric

First Principles: думать от основ

**First Principles Thinking** - разложить проблему до базовых, неоспоримых истин и построить решение заново, не полагаясь на аналогии и «всегда так делали». Метод Декарта, Аристотеля, Маска. Противоположность: **reasoning by analogy** - «такой же как X».

**Три вопроса First Principles:** 1. Что я знаю точно (неоспоримые факты)? 2. Что я принял как данность, но на самом деле это аналогия/assumption? 3. Если бы я строил с нуля, зная только п.1, к чему бы пришёл? Самый трудный шаг - увидеть свои assumptions как assumptions, а не как факты.

Команда рассматривает переход с монолита на микросервисы «как Netflix». Как применить First Principles?

Инверсия и эффекты второго порядка

**Инверсия (Inversion):** вместо «как достичь успеха?» спросить «что гарантированно приведёт к провалу?» и избегать этого. Часто проще предотвратить провал, чем оптимизировать успех. **Second-Order Effects:** «А что произойдёт после того, как произойдёт следствие нашего решения?» Первый порядок очевиден; второй и третий - там скрыты неожиданные последствия.

**Закон непредвиденных последствий:** у каждого решения есть эффекты второго и третьего порядка, которые часто перевешивают очевидные выгоды первого порядка. Добавить фичу → вырос scope → замедлился Time-to-Market → команда выгорела. Инвертируй: что может пойти не так с этой фичей?

Команда решила сделать весь API синхронным для «простоты». Какой второй порядок эффектов?

Расширенный инструментарий: Occam, Hanlon, Maps

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

**Как применять ментальные модели на практике?** Не стоит применять все сразу. Достаточно выбрать 2-3 наиболее релевантных для текущей проблемы. Со временем они становятся автоматическими паттернами мышления - «мышечная память» рассуждения.

Production падает. Логи показывают timeout на вызов внешнего API. Какую ментальную модель применить первой?

Ключевые идеи

  • First Principles: разложить до неоспоримых истин, отбросить аналогии, строить заново
  • Инверсия: вместо «как добиться X» спрашивать «что точно помешает X»
  • Second-Order Effects: последствия последствий часто важнее первоначального эффекта
  • Occam: простейшее объяснение - отправная точка диагностики
  • Hanlon: ошибка объясняет больше, чем злой умысел
  • Map ≠ Territory: модели упрощают реальность; знай границы своих абстракций

Что дальше

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

  • Разбор реальных технических решений — Кейс-стади: как ментальные модели применяются в реальных архитектурных решениях

Вопросы для размышления

  • Возьмите последнее архитектурное решение команды. Были ли проверены second-order effects? Что было упущено?
  • Что такое «бритва Оккама» в debugging? Что стоит проверять первым делом при любом инциденте?
  • Где проходят границы Circle of Competence у опытного инженера? Что хорошо известно, а где нужна консультация?

Связанные уроки

  • st-01-feedback-loops
Ментальные модели IT-инженера

0

1

Войти