Hacker News Digest

Мой подход к решению проблем — это итеративный цикл из шести шагов: понимание доступной информации, сбор недостающих данных, чёткое определение проблемы, формулирование простого и ясного подхода, установление цели и срочное действие для её достижения. При появлении новой информации я возвращаюсь к шагам 3–5, обновляя свои предположения — этот процесс, хотя и может казаться хаотичным, является здоровым, если осознавать, что корректировка при новых данных — единственный путь к правильному решению. Я применяю эту структуру почти ко всем задачам и продуктам, поскольку продукт — это решение проблемы для пользователей.

Чаще всего ошибки возникают на шагах 3 и 4: нечёткое определение проблемы и сложный, неясный подход к её решению. Это приводит к запутанным планам и расплывчатым критериям успеха, особенно в сложных задачах, где сам создатель плана может не заметить недостатков. Поэтому я ценю обратную связь в реальном времени — как даю её, так и ожидаю её в ответ. Если часть этого мета-процесса окажется ошибочной, я готов её изменить. Я люблю ошибаться, потому что именно ошибки помогают точнее сформулировать проблему, найти правильное решение, ускорить обучение и в итоге решить задачу.

Подход из статьи воспринимается как тривиальный или вредный, если навязывается как жесткая рамка без приверженности итеративности и критическому мышлению. Критики считают фреймворк Бориса переформулировкой базовых шагов решения проблем и инструментом авторитарного контроля, что вызывает сопротивление команд. Основные претензии: — Требование «действовать со срочностью» противоречит основам инженерии, где некоторые задачи требуют времени на исследование. Это ведет к отсутствию приоритизации и созданию токсичной среды. — Логическая ошибка в структуре: определение цели на пятом шаге (после формулировки решения) лишает возможности объективно оценить качество этого решения. — Отсутствие примеров признанных и исправленных ошибок подрывает убедительность автора, особенно на фоне системных багов в Claude Code, которые игнорируются месяцами. — Стиль Бориса может быть следствием использования LLM, что делает текст «гладким», но пустым. При этом многие согласны, что точное определение проблемы — ключевой навык, а пропуск этапов анализа перед действием — распространенная проблема индустрии. Методы, аналогичные подходам Полиа или Amazon’s doc-writing, эффективны как инструменты глубокого анализа, а не шаблоны. Рекомендации: — Сбор информации должен идти в цикле с определением проблемы, чтобы избежать избытка нерелевантных данных. — Публичная рефлексия об ошибках без конкретных примеров исправлений выглядит как самопиар. — Ценность фреймворка следует демонстрировать через результаты, а не навязывать команде как обязательный стандарт.

Программное обеспечение сочетает скорость, деньги, сложность, абстракцию и почти неограниченную свободу менять своё мнение — и это делает людей неадекватными. Хотя большинство приложений по сути — просто электронные таблицы с интерфейсом, процесс их создания заставляет взрослых вести себя как злодеи из фильмов: каждая новая функция становится «той самой», а любая задержка — кризисом. В отличие от физического мира, где перестановка кухни требует сноса стен и влечёт видимые затраты, в программировании стоимость изменений скрыта: она проявляется в контекстном переключении, риске регрессии и архитектурном эрозии, но не в пыли или обломках. Эта непрозрачность порождает иллюзию бесплатности: то, что выглядит как «быстрая правка», может обернуться системным сбоем, а потому в дорожную карту попадает каждая «крутая идея», особенно если её можно реализовать за час.

Из-за отсутствия естественного трения между идеей и её реализацией «можем» быстро становится «должны», а затем — «почему ещё не сделано?». Всё начинает казаться стратегическим и срочным, потому что теоретический выигрыш огромен, а выбора решений — десятки. Технические споры превращаются в идеологические битвы, замедление воспринимается как провал, а терпение — как лень, поскольку индустрия поклоняется скорости. В результате команды бесконечно итерируются, пивотят и переплатформятся, пока исходная проблема не исчезает под слоями ненужной сложности. Через годы кто-то предлагает вернуться к простому решению — часто с чувством собственного превосходства. Но выход не в замедлении ради замедления, а в восстановлении пропорции: не каждая проблема экзистенциальна, не каждая идея нужна в бэклоге, не каждое ПО должно стать платформой, и не каждой компании нужно владеть миром. Иногда достаточно просто построить рабочий инструмент — как хорошую электронную таблицу — и оставить его в покое.

Основная причина безумия разработчиков — не само ПО, а его отрыв от реальных пользователей, финансовые стимулы, управленческие искажения и технологический шум. Изоляция от клиентов и взаимодействие только через менеджеров резко повышают риск безумия; регулярное общение с пользователями возвращает фокус на реальность. Современные команды из 60–80 человек разрабатывают CRUD-приложения, тогда как 20 лет назад небольшие команды из 4–5 человек создавали критически важные системы на C++ — это указывает на рост технологического шума и снижение эффективности. Технические лидеры ошибочно принимают успех в абстрактной модели за победу над реальной доменной областью, что ведёт к эгоцентризму и потере связи с потребностями пользователей. Программирование, лишённое физических ограничений, создаёт иллюзию неограниченной свободы, активируя неуверенность и компульсивное вмешательство. Большинство программ — электронные таблицы с интерфейсом, но сложная архитектура (сервис-меш, event-driven) используется как маркетинг, а не как необходимость, искажая восприятие ценности работы. Финансовые стимулы — обещание быстрых миллионов от стартапов — заставляют разработчиков искать «идеальный путь» вместо реального решения. Отсутствие жёсткой обратной связи и физических ограничений делает ПО средой для неадекватного поведения: ошибки не имеют немедленных последствий. Управление ПО часто осуществляется неразработчиками, которые воспринимают изменения в коде как простые физические доработки, не понимая их сложности и рисков. Современные инструменты, включая LLM, делают изменения в ПО дороже, снижая частоту произвольных правок, так как PM больше не могут «спасти» бюджет за счёт лёгких правок. Работа за экранами и цифровая перегрузка вызывают диссоциацию и потерю связи с реальностью — коллеги за 10 лет превращаются в истощённых «мурмурщиков». Оставлять всё как есть — недооценённый навык инженерии: постоянные изменения ради «улучшения» разрушают стабильность и создают психологическую нагрузку без реальной пользы. Интернет и цифровая среда создают замкнутую эпистемологию, где всё субъективно и самоподтверждающе, усиливая иррациональные убеждения и отрывая от внешней реальности. Пользователи хотят простые, надёжные инструменты — успешные приложения вроде BookFusion и Libro.fm доказывают, что минимализм и фокус на базовых функциях приводят к большей ценности. Совет: применяй зен-подход — смотри на код как на инструмент, а не как на средство для славы; тогда эго, соревнование и ненужные изменения теряют силу, и сохраняется психическое здоровье. Совет: используй MVP и быструю обратную связь — если функция не приживается, удаляй её, а не усложняй систему ради «идеального» решения, которое никто не использует.

Кодинг — не самый сложный элемент создания продукта. На деле программисты годами получали высокие зарплаты, сталкивались с выгоранием и жёсткими сроками, а книги вроде Clean Code и The Pragmatic Programmer стали классикой не из‑за лёгкости, а из‑за глубины задачи. Если бы написание кода было действительно простым, зачем требовались десятки‑тысячных часов обучения, интервью‑тесты LeetCode и герои вроде Джон Кармаха или Фабрис Беллард?

Определять, что именно построить, остаётся главным вызовом. Продукт‑менеджеры часто теряются в формулировках, а «понимание клиента» всё равно считается «мелкой» работой, хотя именно она определяет, будет ли функция востребована. Поэтому вместо того, чтобы писать десятки одинаковых прототипов, стоит научиться слушать пользователей, а не полагаться лишь на автоматический генератор кода. И помните: не отдавайте AI полную ответственность за ваш продукт — ваша эмпатия и суждение остаются уникальными.

Тред дополняет статью, показывая, что сложность кодинга зависит от уровня инженера и контекста: для джунов — написание кода, для сеньоров — архитектура, коммуникация и управление неопределённостью, а LLMs смещают нагрузку с написания на верификацию и управление поведением ИИ.

• Писать код, который работает — легко; писать корректный, поддерживаемый, масштабируемый код — сложно, и именно это требует десятков тысяч часов обучения и опыта.

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

• Современные инструменты, включая LLMs, не упрощают программирование, а переносят нагрузку на архитектуру, верификацию, контроль безопасности и управление поведением ИИ-генераторов кода.

• Код, который легко написать — это не то, что ценится в продакшене; ценится код, который надёжен, понятен, тестируем и легко расширяется — это требует высокой квалификации и дисциплины.

• Большинство инженеров сталкиваются с тем, что сложность смещается от написания кода к координации, требованиям, интеграциям, QA и коммуникации — особенно в крупных компаниях.

• LLMs усиливают необходимость в инженерии надёжности: теперь нужно строить системы, которые направляют, ограничивают и проверяют поведение ИИ, а не просто писать код.

• Программирование — это не только код, а процесс: анализ, проектирование, тестирование, документирование, поддержка — и только последний этап — это набор строк в редакторе.

• Спор: Некоторые считают, что 'код — лёгкая часть', потому что они работают в средах, где требования стабильны и архитектура уже определена — но это не применимо к большинству реальных проектов с неопределённостью.

• Спор: Утверждение, что 'код — лёгкий', игнорирует, что многие компании платят высокие зарплаты не за написание кода, а за способность выявлять скрытые требования и управлять техническим долгом.

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

• Совет: Если вы думаете, что код — лёгкий, проверьте, как долго вы тратите на отладку кода, сгенерированного LLM, и на то, чтобы убедиться, что он не создаёт уязвимостей или не отклоняется от требований.

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

• Книги вроде TAOCP и SICP не о коде — они о фундаментальных алгоритмах и структурах, которые требуют глубокого понимания, а не просто умения печатать.

• Автоматизация (включая LLMs) не устраняет сложность — она меняет её: теперь нужно понимать, как управлять системами, которые генерируют код, а не просто писать его.

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