Hacker News Digest

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Многие компании упускают огромный потенциал, отказываясь нанимать джуниор-инженеров, предпочитая только сеньоров. Это даёт конкурентное преимущество тем, кто готов инвестировать в молодые таланты: мотивированные джуниоры быстро обучаются с помощью ИИ, привносят свежие идеи и демонстрируют высокую лояльность. Например, Shopify планирует нанять 1000 стажёров, отмечая их энергию и влияние на команду.

Ключевые ошибки работодателей — устаревшие представления о длительном онбординге и интервью, сфокусированные на алгоритмах, а не на реальных навыках. Джуниоры, свободные от шаблонов, часто превосходят сеньоров в гибкости и скорости обучения. Чтобы найти лучших, стоит искать кандидатов вне традиционных каналов, например, среди тех, кто не прошёл в Y Combinator, но проявил инициативу.

• Сложности найма джунов из-за заучивания LeetCode и использования ИИ в учебе, снижения страсти к профессии.
• Риски найма слабых джунов и необходимость эффективных фильтров для выявления талантов.
• Переизбыток выпускников CS на фоне сокращения числа вакансий для новичков.
• Важность реального опыта для джунов и конкуренции с ИИ.
• Разные подходы к оценке джунов: сложные задачи vs. простые, проверка мышления и сотрудничества.

Почему наём — боль

Компании теряют время: 9 раундов, охота за «трендовыми» разрабами, не могут отличить программиста от LLM. Кандидаты страдают: лучшие разрабы (Rust, Haskell) проваливают стресс-интервью, рекрутеры называют их «не-технарями», а потом пропадают на месяцы.

Каким должен быть хороший процесс

1. Различать сеньора и маркетолога с ChatGPT.
2. Применимо к работе: код, архитектура, ревью, документация.
3. Долгосрочно: люди не взаимозаменяемы, уход дорого, специализация под стек выучивается за месяц.
4. Экономно: инженерное время дорого.
5. Уважительно: неуважение отпугивает лучших.
6. Вкус: быстрое, но грязное решение — долгий долг команде; «клей» (поддержка коллег) множит продуктивность.

Почему популярные форматы не работают

• Live-coding / LeetCode
  Не различают, не про работу, уничтожают уважение и вкус, дорогие при многократных раундах.

• Take-home
  Легко сгенерировать ChatGPT, неуважительны к времени кандидата, отпугивают сильных.

• Проектирование архитектуры
  Лучше: ChatGPT не пройдёт, близко к реальной работе, можно оценить вкус и командное влияние.

• Современные «интервью» больше похожи на серию экзаменов, чем на профессиональный разговор.
• Многие считают, что достаточно 1-2 коротких встреч или пробы через контракт «temp-to-perm», чтобы понять, подходит ли человек.
• Популярные live-coding и leetcode почти не отражают реальную работу и отбирают не тех специалистов.
• Лучше обсуждать реальные задачи, ревьюить существующий код или решать мелкий баг в паре — это ближе к ежедневным обязанностям.
• Кандидаты теряют время и энергию на домашние задания и 9-часовые циклы, поэтому всё чаще «интервьюируют» и сами компании.