Большие технические проекты часто ломают даже самых опытных разработчиков. Сначала — эйфория, азарт, кофе по ночам, бесконечные коммиты. Потом — апатия, перфекционизм и фраза «ну я потом доделаю».
Митчелл Хашимото, создатель HashiCorp (Terraform, Vagrant, Nomad, Vault), в своей статье My Approach to Building Large Technical Projects делится личным методом борьбы с этим феноменом. И, на мой взгляд, его философия удивительно применима не только к коду, но и к жизни.
💡 Суть метода — "видимый прогресс"
Главная идея Митчелла проста: всегда видеть результат своей работы.
Он предлагает строить процесс вокруг частых демонстраций — пусть не идеальных, но работающих.
🧩 Вместо того чтобы сразу замахнуться на огромную цель («сделать свой терминал, поддерживающий Neovim»), он предлагает искать минимальный кусок, дающий ощутимый результат. Например:
- 🧠 написать парсер VT-последовательностей;
- 🪟 вывести пустое окно терминала;
- 🐚 запустить дочерний процесс bash и просто считать его вывод.
И всё — можно показать самому себе демо. Пусть даже «сырой» CLI, который потом будет выброшен. Главное — почувствовать движение вперёд.
⚙️ Почему это работает
С точки зрения психологии разработчика, метод Хашимото идеально ложится на механику дофаминовых циклов: каждое успешное демо, каждый зелёный тест активирует мотивацию.
Это не просто «разделяй и властвуй», это разделяй и радуйся.
💬 Как он пишет: “Do not let perfection be an enemy of progress.” - Не позволяй стремлению к совершенству стать врагом прогресса.
Именно это отличает завершённый проект от мёртвого в репозитории.
🧪 Ранняя обратная связь — ключевой элемент
Митчелл советует делать демо раз в неделю. Даже если вы работаете в одиночку, демонстрируйте прогресс самому себе.
Это важно по трём причинам:
- 🔍 помогает увидеть продукт «вживую», а не в абстрактных классах;
- 🧭 позволяет быстро скорректировать курс, если идея оказалась неудачной;
- ⚡ поддерживает азарт и ощущение осмысленности.
Мне особенно близка его мысль, что опыт иногда мешает. Опытные инженеры часто застревают в оптимизации и красивой архитектуре, забывая, что пользователю (или самому себе) нужен не «идеальный код», а живой результат.
🧠 Build for yourself
Ещё один принцип: делай для себя.
Пока вы не начнёте реально пользоваться своим инструментом — это всего лишь код.
Хашимото использовал свой терминал как ежедневный драйвер, и именно тогда появились настоящие инсайты:
- стрелки не работают — добавляем обработку;
- курсор моргает неправильно — исправляем рендеринг;
- шрифт нечитабельный — улучшаем рендеринг.
Так рождается не просто MVP, а настоящий инструмент, потому что он решает реальные боли разработчика.
🪄 Мой взгляд: метод “progress-loops”
То, что предлагает Хашимото, — фактически циклический конвейер прогресса.
Если адаптировать его для себя, я бы назвал эту систему “progress-loops”:
🔁 Цикл прогресса:
- 🎯 Выбери микрозадачу, которая даст видимый результат.
- 🧩 Реализуй минимальную версию (не идеальную, но работающую).
- 🧪 Протестируй и покажи (себе, команде, миру).
- 🧠 Извлеки обратную связь.
- ⚙️ Повтори цикл, добавляя функциональность по потребности.
Такой подход идеально подходит для open-source, хакатонов, и даже личных pet-проектов — от симулятора физики до ИИ-бота.
Главное — не гнаться за «готовым релизом», а за ощущением живого движения.
💬 Заключение
Метод Митчелла Хашимото — это не про Jira и не про Agile.
Это про человеческую сторону инженерии — про то, как сохранять мотивацию, когда проект кажется бездной.
Его философия — напоминание, что каждый “прошёл один тест” важнее, чем “всё почти готово”.
Инженерия — это путь, и важно видеть следы, которые ты оставляешь на этом пути каждую неделю.
🔗 Источники и материалы:
- Митчелл Хашимото — My Approach to Building Large Technical Projects
https://mitchellh.com/writing/building-large-technical-projects
🧠 Если вы программист, попробуйте сделать маленькое демо сегодня. Даже если это просто “Hello, world!” в новом проекте — это уже первый шаг к большому делу.