Каждый раз, когда в сеть попадает очередной кусок «кривого» кода из Google, Meta, Amazon или Microsoft, вокруг начинается один и тот же спор:
«Как же так? Эти компании нанимают лучших инженеров мира — неужели они не могут писать нормально?»
Но правда в том, что плохой код в больших компаниях пишут хорошие инженеры.
И делают это не из-за отсутствия навыков, а потому что сама система толкает их в такие условия, где другого результата просто не может быть.
Новость, о которой идёт речь, отлично вскрывает этот парадокс. А я хочу расширить картину: показать, почему это не трагедия, а закономерная цена за масштаб, гибкость и скорость корпоративных гигантов.
🧑💻 Большая часть изменений делает новичок
Звучит жёстко, но это факт. В Big Tech инженеры:
- 🧭 в среднем сидят на месте 1–2 года
- 🔄 почти ежегодно попадают под реорганизацию
- 🌪️ регулярно переходят в новые проекты «по внутренней мобильности»
При этом кодовые базы живут по 10–15 лет.
Получается эффект «вечного новичка»:
человек приходит в проект, не успевает глубоко погрузиться — и уходит.
Поэтому специфическая, опасная, «хрупкая» логика часто оказывается в руках разработчика, который:
- впервые видит этот модуль,
- не знаком с историей решений,
- не знает, что отламывалось пятью годами ранее,
- работает под давлением сроков.
В такой среде идеальный код — миф.
🧓 «Старожилы» есть… но они перегружены
В больших компаниях всегда есть старожилы (old hands) — люди, которые:
- хорошо знают наследие систем
- понимают исторические компромиссы
- могут предсказать, где что сломается
Но у них есть две проблемы:
🕒 1. Их слишком мало
Большие проды — десятки сервисов.
Инженеров-экспертов — единицы.
📥 2. Они завалены ревью, консультациями и совещаниями
Им буквально некогда читать каждый коммит.
В результате контроль качества становится фрагментарным:
успели посмотреть — хорошо; не успели — «ну ладно, потом поправим».
🎛️ Почему компании это терпят
На первый взгляд звучит абсурдно:
«Почему бы не удерживать экспертизу и не сократить текучку?»
Но вот важный момент: для Big Tech это осознанная стратегия.
🧱 Что им важно на самом деле:
- ⚡ гибкость — возможность срочно перекинуть людей на проект месяца
- 📊 управляемость — кто чем занимается, кто куда назначен
- 🔄 обмен ресурсами — чтобы команды могли быстро меняться местами
- 💼 компенсационная логика — RSU-циклы, которые стимулируют ротацию
Компании сознательно идут на компромисс:
качеством жертвуют ради манёвренности.
Это не баг — это архитектурное решение.
🪛 Почему мой взгляд немного отличается
Статья критикует систему, но я смотрю на неё чуть шире — и практичнее.
🧠 1. Невозможно написать хорошую систему, оставаясь вечным новичком
Монолит, построенный десятилетиями, нельзя «освоить» за квартал.
Код — это культурный артефакт, а не математическое уравнение.
🚧 2. Любая сложная организация будет производить шум
Google, Meta, Microsoft — это тысячи разработчиков, сотни команд, десятки уровней менеджмента. Отсутствие хаоса было бы подозрительным.
🔁 3. Неидеальный код — часть стратегии быстрого роста
Иногда важно выкатить («ship it»), а не «идеально зарефакторить».
Facebook даже придумал этому культовый лозунг:
Действуй быстро, даже если что-то сломаешь (Move fast and break things).
🧩 4. «Плохой» код в Big Tech часто работает лучше, чем «идеальный» код в стартапах
Потому что он поддерживается инфраструктурой, SLA, SRE, защитными слоями, тестами и fallback-процедурами.
🧨 Пример из реальной жизни (моё наблюдение)
Я видел такие фрагменты кода в крупных компаниях:
- обработчики ошибок, которые ловят Exception и делают pass
- 500-строчные SQL-запросы, которые никто не трогает
- сервисы, которые никто не берётся переписать, потому что «прожили 8 лет — доживут ещё»
- конфиги, которые понимает один человек, уволившийся два года назад
И знаете что?
Эти системы работают на миллиарды пользователей.
Это не значит, что плохой код — хорошо.
Это значит, что идеальный код — не цель.
Цель — работающая система, выдерживающая нагрузку, катастрофы и организационные перестановки.
🛑 Можно ли исправить ситуацию?
Только системно. И только если компания решит, что:
- долгосрочная экспертиза важнее гибкости
- качество важнее скорости
- стабильность важнее резких разворотов
Но пока гонка за ИИ, рынок и акционеры требуют скорости,
«неидеальный код» будет частью экосистемы Big Tech.
🔮 Моё резюме
Плохой код от хороших инженеров — не парадокс.
Это закономерность, возникающая при:
- большой организационной инерции
- высокой текучке
- культуре быстрых результатов
- непрерывных реорганизациях
- отсутствии мотивации удерживать глубокую экспертизу
И как бы ни хотелось винить людей,
проблема — в структуре, не в инженерах.
Это как пытаться обвинять электрика за кривую проводку в доме, который заказчик перестраивает каждые два месяца.
📎 Источники
🔗 Оригинальная статья
https://www.seangoedecke.com/bad-code-at-big-companies/