Критическое мышление
Ментальные модели IT-инженера
Чем опытнее инженер, тем реже он пишет код - и тем больше времени тратит на мышление. Ментальные модели - это то, что отличает «человека, который просто делает» от «человека, который понимает, что и почему».
- Илон Маск использует First Principles для снижения стоимости ракет
- Чарли Мангер (Berkshire Hathaway) использует набор из 100+ ментальных моделей для инвестиционных решений
- Инверсия - core часть процесса pre-mortem в Amazon (working backwards)
Предварительные знания
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 у опытного инженера? Что хорошо известно, а где нужна консультация?