Нередко для описания хромых кодовых баз используют метафоры вроде «тонущий корабль». Я же считаю, что эта аналогия ошибочна. Бизнес начинает тонуть задолго до того, как код достигнет гипотетического дна. Технический долг нельзя свести к банкротству, чтобы начать с чистого листа. Именно поэтому подобные метафоры, подразумевающие достижение некоего конца, лишь создают ложное чувство спокойствия.
Программное обеспечение существует в умозрительной сфере. Его нельзя сравнивать со зданием или мостом, которые находятся в физическом мире, где вы можете их полноценно видеть и осязать. Если вы продолжите бесконечно добавлять в здание этажи и комнаты, оно в конечном итоге рухнет. Но у ПО нет такого жёсткого предела. Код всегда можно сделать ещё хуже. Всегда можно внести очередной слой абстракции или ещё больше ослабить производительность.
1. Посадка на тонущий корабль
Впервые я столкнулся с уродливым легаси кодом больше десяти лет назад. Тогда я только окончил универ и устроился в Amazon на должность «инженера разработки ПО» в команду, отвечавшую за код обработки заказов1. Снаружи задачи нашего кода выглядели довольно простыми. Для обработки заказа требовалось записывать некоторые данные в БД и вызывать сервисы других команд — для проверки валидности данных или обновления информации на их стороне. Мы с коллегами прикинули, что для уверенной поддержки и развития этого сервиса нам потребуется не более двух десятков хороших разработчиков. Но в нашей организации работали сотни людей, и система разрослась так сильно, что разобраться в её внутреннем устройстве стало невозможно.
В этой организации мало кто задерживается дольше, чем на пару лет, и полноценно сохранить преемственность знаний не удавалось. В итоге код стал переполнен «кладбищами с привидениями»2, и страх прикасаться к нему подавлял любые попытки упростить существующие системы (особенно те, которые не сулили достойного вознаграждения). Бизнес-правила, описывающие внутренние механизмы обработки каждого вида заказа, были определены теми, кто уже давно уволился. Иногда описание этих правил можно было отыскать в безнадёжно устаревшем файле с гордым именем «living document», но зачастую они даже не были задокументированы. Да и самостоятельно проследить поведение программы было не легче, так как значительная часть системы находилась в ведении других команд, и прямого доступа к её коду у нас не было.
Когда в каком-то туманном процессе обработки заказа происходил сбой и что-то шло не так, дежурные пейджеры яростно сигнализировали о том, что в нашей непролазной паутине зависимых сервисов кто-то сильно негодует. Благодаря такому механизму обратной связи система всё ещё держалась на плаву, но менять её было невероятно тяжело, а производительность оставалась катастрофически низкой.3 Но несмотря на это, для поддержки новых продуктов и функций Amazon поверх старого кода постоянно нанизывались новые уровни абстракции. Всё это казалось абсолютно неустойчивым путём развития. Собственно, поэтому для описания организации, которая не закрывает свой технический долг, мы с коллегами используем метафору «тонущего корабля».
Хотя всё же стоит отдать должное тем отважным сотрудникам, которые не оставляли попыток исправить архитектуру.4 Обычно это начинается с того, что новый менеджер или старший разработчик, приходя в компанию, видит, насколько всё паршиво. Руководство согласно и вроде бы желает всё наладить, вот только для этого вечно нет свободных разработчиков, поэтому каждая такая попытка включает расширение штата и формирование новых команд.5
Переделки архитектуры всегда приводили к провалу. Чтобы как следует понять систему, которая ещё и постоянно менялась, приходилось годами её изучать. Естественно, даже чисто с карьерной точки зрения, тратить столько времени на исправление системы было нецелесообразно, поэтому всем, кто за это брался, приходилось работать с неполной информацией. В некоторой степени эта поспешность исходила от самого инициатора — ведь если ты пытаешься разработать мега-лекарство для столь глубоко больной архитектуры, то делаешь это отчасти ради повышения (которого не хочется ждать долго).
Каждый такой цикл заканчивался тем, что остатки очередной попытки намертво встраивались в нашу архитектуру, а руководивший проектом разработчик благополучно умывал руки, забрав своё «заслуженное» повышение. При этом раздутый штат сотрудников никуда не девался, поскольку задачи по миграции на новую систему были слишком мучительны и неблагодарны, чтобы разработчики с готовностью бились над ними до конца. И каждый раз эта круговерть, начавшаяся задолго до моего прихода, повторялась по новой.6 Казалось, что этот тонущий корабль никогда не достигнет своего дна.
2. Где же реально конец?
Где-то через три года после ухода я однажды общался по телефону с бывшим коллегой по команде. На тот момент он только уволился после внушительных шести лет работы и перед тем как раз застал очередной виток этого замкнутого круга. Мы единодушно выразили негодование и оба использовали метафору тонущего корабля несмотря на то, что ушли из компании с разницей в несколько лет.
«Когда это, наконец, закончится и как?» — спросил он, желая услышать моё мнение о будущем этой организации.
Этот его вопрос и сама метафора тонущего корабля заставили меня задуматься. Немного поразмыслив, я понял, что здесь нужно провести разделение между кодом и компанией.
Бизнес может потонуть, и плохое ПО становится для него реальной обузой. Но степень, до которой эта обуза тянет на дно, зависит от многих факторов. Корпорации с крупными доходами вроде Amazon могут спокойно закрывать глаза на точечные очаги внутреннего загнивания до тех пор, пока это не начнёт ощутимо бить по их прибыли. Для других же компаний, чья бизнес-модель более чувствительна к качеству ПО, ошибки в его создании могут стать скрытым сигналом конкурентам об удачной возможности нанести уязвимому борту критическую пробоину (и LLM тут не спасут7).
Если же смотреть с позиции кода, то он может тонуть бесконечно, так как всегда можно сделать ещё хуже. Здесь вы не можете выбежать из здания, которое вот-вот рухнет. Оно находится в перманентном стоянии обрушения. Так что тут не совсем корректно использовать термины, подразумевающие завершённость процесса.
Да, придирчивый читатель будет прав, если скажет, что в определённый момент ПО может сломаться окончательно. Вот только на практике такие поломки быстро откатываются, чего не скажешь о тысячах губительных изменений, которые им предшествовали. ПО продолжает «работать».8 Бывают и другие случаи, когда нельзя найти какой-то один проблемный коммит для отката. В таких сценариях раздутые расходы на обслуживание хромого ПО начинают банально перевешивать его пользу, или же сама разработка встаёт колом, так как уже просто невозможно запустить новую фичу без поломки чего-то рабочего. Во всех этих случаях именно бизнес умирает задолго до того, как код достигнет своего дна (так что не нужно прикидываться, будто это дно есть).
3. Технический долг не сведёшь к банкротству
Кривое ПО является реальной угрозой для бизнеса, и поэтому в предусмотрительных компаниях его качеству уделяют особое внимание. Поскольку нельзя зафиксировать некий порог неудачных решений, после которого система внезапно откажет, зачастую этот феномен называется просто «технический долг». Такое сравнение тоже не идеально, но уже больше подходит в качестве метафоры, так как долги могут копиться бесконечно.
У долга есть своя «конечная» точка, так как итоговое банкротство ведёт к перезапуску с нуля. В программном обеспечении эквивалентом этому будет полное переписывание кода, что редко оказывается приемлемым решением.
Самым близким к этому выходом из положения для таких мегакорпораций, как Amazon будет ответвление, а именно создание специальной команды для построения новой, полностью обособленной системы с минимальным набором функций, необходимых для нового сценария использования. В перспективе по мере продвижения эта команда сможет привязывать к своей упрощённой системе и другие новые фичи. И здесь важно продолжать обслуживать старую систему (это далеко не «конец»), так как прошлые сценарии использования никуда не делись. В итоге для организации возникает новая головная боль всякий раз, когда нужно решить, какую из этих систем использовать под очередную задачу.9 Так что это всё ещё не обнуление, которое мы представляем себе при банкротстве.
Ошибочные представления о программном обеспечении ведут к неудачным решениям. Когда ты веришь, что у тебя есть спасательный круг в виде возможности «жёсткого сброса», то накопление технического долга не кажется чем-то страшным. Вера в то, что в будущем можно просто переписать проблемные места, приводит к принятию плохих решений сегодня, ведь ответственный за эти решения не понимает, что никакого спасательного круга нет.
Метафоры вроде «рушащегося здания» или «тонущего корабля» не подходят для описания ПО. Но мы всё же можем использовать их, чтобы подчеркнуть его отличительные особенности. В таком случае вернее сказать, что здание обрушается бесконечно, а корабль бесконечно тонет. В цифровом мире нет каких-то жёстких пределов, которые бы заставили вашего проджект-менеджера очнуться и начать разбираться с техническим долгом. Сохранить высокое качество ПО получится, только если активно бороться с причинами его потопления. Так что хватайте вёдра, комрады.
Сноски
-
Я намеренно не погружаюсь во многие детали этой истории. У меня нет цели повесить вину на отдельных людей или организацию (мы искренне старались исправить ту ситуацию, в которой оказались). Поэтому мой пересказ неполон и служит чисто для общей демонстрации. ↩
-
Насколько я знаю, этот термин зародился в инженерной среде Google. Им описывают очень сложные для понимания разделы кода, в которые люди предпочитают даже не заглядывать. ↩
-
Для компании было дешевле перекрыть проблему дополнительными серверами, чем серьёзно вкладываться в оптимизацию производительности. Помню в какой-то момент даже довольно мощные машины могли обрабатывать лишь по 1–2 заказа в секунду. Вот только аналогично раздутому штату компании это никак не вязалось с нашей интуицией, которая подсказывала, что мы должны обрабатывать как минимум на два порядка больше. ↩
-
Мы с коллегами начали воспринимать эти амбициозные архитектурные цели как какой-то анекдот. Мы иронично называли их «блестящим будущим», наполняя эту фразу сарказмом: «Как только эта $NEXT_ARCHITECTURE приведёт нас в блестящее будущее, проблема исчезнет!» ↩
-
В свете обсуждения чрезмерного раздувания компании и её внутренних трений не могу не упомянуть моё любимое выступление Брайана Кантрила — посмотрите, если хотите поржать. ↩
-
Если бы я тогда не ушёл, то взял бы под свою ответственность как минимум часть этой новой архитектуры — просто ради дальнейшего повышения. Но вряд ли у меня бы получилось «исправить» ситуацию сильно лучше, чем у остальных. Вся суть в том, что само устройство организации и применяемые в ней механизмы мотивации априори не позволяют создать что-то реально толковое. ↩
-
В этой статье я сознательно не развивал тему использования ИИ, так как она устареет быстрее того, о чём я пишу. Но всё же я считаю необходимым затронуть её хотя бы поверхностно. Моё мнение таково: если культура и системы мотивации в вашей компании являются причиной падения качества ПО, то LLM тут уже не помогут. Они только ускорят ваше движение по этой проложенной траектории. Я бы мог развить эту тему, но не хочу отклоняться от основного посыла статьи. Лучше потом напишу отдельную для тех, кому это интересно. ↩
-
Проект FizzBuzz Enterprise Edition является своего рода художественным манифестом, в котором этот аспект ПО намеренно доведён до абсурда. ↩
В Amazon «ответвление» тоже неоднократно происходило, хотя и не с такими темпами, как переделки архитектуры, о которых я поведал в своём рассказе. В мегакорпорациях такое «мягкое выведение из эксплуатации» становится самой вероятной формой отпевания для замучившей всех легаси-системы. В отличие от паттерна «фикус-душитель» (strangler fig), который подразумевает налаживание промежуточного слоя и постепенную замену существующей системы, ответвления намеренно создаются без какого-либо взаимодействия со старой платформой. ↩
Комментарии (30)
apcs660
11.09.2026 13:33все похоже на Яндекс.
aabzel
11.09.2026 13:33Да.
Вот буквально несколько фактов про то как пишут код в яндекс драйве:–Прошивка телематики каршеринга для PCB MT-32K LTE V2 состоит из 5-7 функции-богов по 5000-7000 строк каждая.
–Они программирую электронную плату с STM32F413ZGJ6, а в настройках IDE у них прописан вообще другой микроконтроллер STM32F205VC. Поправить нельзя так как “итак как-то дышит”
–Пишут прошивку, которая просто перекладывает байты из CAN в UART на С++ 17 года вместе классического Embedded С. Вместо указателей классы std optionals.
–Не умеют пользоваться скриптами сборки (Make, Cmake и пр). Проекты собирают из-под игрушечной GUI-IDE IAR. Там надо ключи компилятора проклевываться мышкой. В результате огромные накладные расходы на создание новой сборки.
–В прошивке нет отладочной UART консоли, при этом на плате MT-32K_LTE_V2 3 отдельных UARTа выходит на разъёмы
–в яндекс драйв в код телематики каршеринга собирался с 80+ предупреждениями компилятора и исправление их было строго запрещено под предлогом “и так как-то дышит” .
–Нет ни одного модульного теста. Оно и понятно, ибо невозможно модульно тестировать функции-боги типа
void xxx_init(void)
void xxx_invoke(void).
--магические циферки в коде
--транслит в названиях функций
–в яндекс торжествует Blame Driven Development.
Ну и куча других моментов...
Всё это явственно показывает истинный уровень этих хипстеров.
Не верите?
Можете посмотреть сами их сорцы на rutacker
Утечка исходных кодов сервисов Яндекс
https://habr.com/ru/news/712888/
На сайте https://rutracker.org
Ключевое слово: "Исходники Яндекс-приложений (x86, x64)"
Dhwtj
11.09.2026 13:33Да, хреново.
"Веб гибкий, embedded консервативен". Но тут то как раз домен, который должен быть стабильный
aabzel
11.09.2026 13:33Там еще чтобы обновить прошивку на плате MT-32K_LTE_V2 что у тебя на столе в Москве надо было использовать LTE загрузчик. Передавать прошивку через сервера в Финляндии.
При этом на самой плате есть SWD интерфейс для загрузки и пошаговой отладки кода, которым тоже было пользоваться запрещено.Dhwtj
11.09.2026 13:33В стабильном домене отсутствие архитектуры означает, что каждое редкое, но предсказуемое изменение (новая ревизия платы, новая машина) оплачивается полной ценой археологии по функциям-богам. Что в Драйве, судя по описанию, и происходит.
Причём , это должно развиваться. Железо уже менялось и будет меняться. Парк растёт, добавляются новые модели машин с другими CAN-матрицами, операторы глушат старые сети, появляются новые требования к телеметрии.
Бизнес и рад бы поменять уже железо на более дешёвое или по другим мотивам, но кривое ИТ не даёт такой возможности.
aabzel
11.09.2026 13:33Вот к слову, сама схема платы телематики яндекса MT-32K_LTE_V2
https://habr.com/ru/articles/667030/comments/#comment_29996976
apcs660
11.09.2026 13:33я там немного поработал - недолго. Про косяки можно книгу написать.
Не зря NDA злобный.
После нормальной работы в ламповой компании Яндекс мне показался очень суетливым местом с большим количеством бестолковой активности - все для студентов сделано у которым гормоны и много сил и свободного времени. Жрут энергетики и бегут к успешному успеху. Перед полугодовым ревью работа на месяц встает - у всех пригорает. Средний менеджмент - в основном недоросли с большим самомнением. Таких напыщеных и хамовитых как там не встречал - думаю на курсах успешного успеха их наставляют что еще немного и морковка ваша. Еще на интервью переход на ты был прям в фокусе - это подбешивало но терпел. Каргокульт американской компании с кривой адаптацией увольнения at will к российскому трудовому кодексу.
aabzel
11.09.2026 13:33Средний менеджмент - в основном недоросли с большим самомнением. Таких напыщеных и хамовитых как там не встречал - думаю на курсах успешного успеха их наставляют что еще немного и морковка ваша.
Да. Именно так.
https://habr.com/ru/articles/704516/
Офисные джунгли (или особенности западной культуры общения на работе)apcs660
11.09.2026 13:33Плохому научились - соковыжиманию и "разделяй и властвуй" - когда все конкуренты, коллектива нет, общей цели нет - есть бег от медведя и последний которого сжирают.
Короче почувствуй себя "таксистом программистом".
Dhwtj
11.09.2026 13:33О, это я писал где-то. Практика Майкрософт децимации коллектива, убрать не успешных. Стек-рейкинг. В результате токсичность и подсиживание в команде
Ну вот хотя бы https://www.businessinsider.com/matt-wallaert-stack-ranking-flawed-damaging-review-system-2021-7
morez
11.09.2026 13:33Прочитал статью про западную культуру общения и только потом в комментариях увидел что вы никогда не работали и не жили в западных странах.
Западные компании и российские отделения некоторых западных компаний это совершенно разные вещи. Даже отделения американских компаний в Европе работают совершенно иначе чем в штатах, особенно если ваш менеджер живет в Европе. То есть нет какой-то обобщенной "западной культуры общения на работе", обобщить американскую и европейскую культуры работы невозможно, они во многом зеркальны друг другу.
Исходя из моего опыта работы в разных странах, по большинству пунктов ситуация противоположная описанной вами, как и в российских филиалах европейских компаний, с которыми у меня был опыт.
aabzel
11.09.2026 13:33Яндекс мне показался очень суетливым местом с большим количеством бестолковой активности - все для студентов сделано у которым гормоны и много сил и свободного времени. Жрут энергетики и бегут к успешному успеху. Перед полугодовым ревью работа на месяц встает - у всех пригорает.
Средний менеджмент - в основном недоросли с большим самомнением. Таких напыщеных и хамовитых как там не встречал - думаю на курсах успешного успеха их наставляют что еще немного и морковка ваша.
Еще на интервью переход на ты был прям в фокусе - это подбешивало но терпел. Каргокульт американской компании с кривой адаптацией увольнения at will к российскому трудовому кодексу.Надо же.
Я думал они только со мной так.
А они оказыватся со всеми так.
aabzel
11.09.2026 13:33Еще на интервью переход на ты был прям в фокусе - это подбешивало но терпел.
Как то 4 или 6 лет назад в проходил собеседование в компанию Axel
(ООО Аксель Телеметрия).
https://axelmwd.com/
В начале видео звонка на той стороне дама сразу предложила перейти на ты. Я сказал, что предпочел бы перейти на ты позже в случае предложения работы. В результате они сразу прекратили собеседование и попрощались.
Это мой рекорд самого короткого собеседования - 4 минуты.
u007
11.09.2026 13:33После нормальной работы в ламповой компании
А какие компании можно назвать ламповыми? Небольшое число сотрудников - обязательное требование?
danilovmy
11.09.2026 13:33Народ, удивляющийся хренокоду в bigtech. Вы реально верите в розовых пони что ли? Многоголовый бизнес монстр с отростками проектов на разных местах по умолчанию не может быть поворотливым, идеально выстроенным и прекрасно запрограммированным. Но он может солидно так всосать проглотить и подзатрахать любого встретившегося у него на пути, как это отлично показано в хентайных "документалках".
Я в vitalera такое видел, что глаза кровоточили уже от структуры проекта, а это я ещё код не открыл.
В ALDI SÜD, это только отросток всего Aldi там такая смесь технологий, что если произнести вслух все - вызовешь дьявола.
Нужно это все? Нет!
Убрать можно? Нет!
Если что то особо мешает бизнесу - появляется что то новое, без отмены старого. Но в примере статьи все работало и бизнесу особо не мешало. А то что техперсоналу сложно - ну так им за это платят. В Aldi, кстати, так себе платили.
OlegZH
11.09.2026 13:33Метафоры вроде «рушащегося здания» или «тонущего корабля» не подходят для описания ПО.
Почему же? Так, ведь, и не объяснили. (Можно было бы пригласить автора к разговору. Использовать ИИ для перевода обсуждения и перевода ответа.))))
Человек начинает стареть прямо с момента рождения. Только, некоторые находят в себе силы немного задержать это старение и сохранить живость восприятия.
А если, всё-таки, использовать корабельную метафору, то что нужно для сохранения плавучести? Постоянная и каждодневная рутина, вроде покраски/починки. То есть — каждый должен делать своё собственное изначально определённое дело. Это значит, не создавать "фичи", превращая всё в бесконечный круговорот "фич", а работать в определённой области, в соответствии с собственным планом и руководствуясь своими профессиональными принципами и правилами.
Хорошее программное обеспечение подобно птице-Фениксу: сгорая, оно даёт основу новой версии. С точки зрения ООП, мы должны построить ПО таким образом, чтобы каждый объект постоянно проходил фазы конструирования, выполнения некой уникальной (здесь и сейчас операции) и уничтожения. По своей сути, конструктор осуществляет процесс компиляции из исходного кода, а деструктор — процесс генерации программного кода. Вот такие постоянные смены компиляции и генерации ("вечное движение") и есть основа для "непотопляемости" ПО.
Bright_Translate Автор
11.09.2026 13:33Отчего же не объяснили - очень даже развёрнуто всё объяснил автор и не один раз. Если вкратце, то у потопления корабля есть предел - дно. А у ПО предела деградации нет, его можно портить бесконечно.
Gradiens
11.09.2026 13:33А у ПО предела деградации нет, его можно портить бесконечно.
Более того, испорченное раздутое легаси, сменившее десяток команд, включающее 10 разных архитектур - норма жизни.
Как-то работает и приносит прибыль. Да, люди выгорают. А корпорации что до этого?
Да, развивать дорого, поддерживать дорого. Но пока прибыли это покрывают (а в гигантских компаниях из-за эффекта масштаба - покрывают) - менеджменту ОК.
Dhwtj
11.09.2026 13:33люди выгорают
Зачем выгорать? Опытные люди знают что такое легаси и что от него ждать. Не забывают прибираться в чулане. Пока чулан нужен он будет стоять
Yuriy_75
11.09.2026 13:33Ну все же не бесконечно - есть же какое-то среднее время отказа ПО, при котором клиент начнет сбегать. Вероятно, несколько дней простоя подряд при наличии хоть каких-то аналогов и конкурентов - это и будет дно.
Yuriy_75
11.09.2026 13:33Ремонт корабля - это возврат его к исходному состоянию. Поскольку именно в исходном состоянии корабль обладал оптимальной для его модели плавучестью, скоростью, маневренностью и т.п.
Современный подход к ПО - каждый квартал нужно больше чего-то. В рамках "корабельной" метафоры, это дикая ересь. Как если бы сначала к кораблю приделали пару барж, чтобы было больше места, а потом озаботились на эти баржи навесить двигатели, чтобы сохранить скорость. А потом шторм, и новая конструкция начинает вести себя неожиданным образом.
CrashLogger
11.09.2026 13:33Зато в такой компании можно спокойно сидеть до пенсии и не опасаться, что тебя заменят, ведь только ты знаешь, куда надо вставить очередной костыль, чтобы оно продолжало как-то пыхтеть. Главное, не пытаться вкладывать в это душу. Отсидел с восьми до пяти, и домой, заниматься тем, что действительно интересно.
Gradiens
11.09.2026 13:33Зато в такой компании можно спокойно сидеть до пенсии и не опасаться, что тебя заменят
Вы действительно верите, что есть компании, где у айтишника есть шанс досидеть до пенсии?
panzerfaust
Каждый раз, когда читаю эти "инсайды" из фаанга, поражаюсь. 9000 этапов собесов с вращением деревьев ради поиска х100 инженеров - и всё равно фуфло на выходе.
quixoticaxis
Ну, тут автор почти сразу и отвечает на вопрос по существу: контора может позволить закрыть болото ширмочкой, а организация разрослась до таких масштабов, когда только ответственных за производство ширм уже без бунта разогнать нельзя.
На тему x100. Ну, не совсем, наверное. 9000 этапов собесов с вращением деревьев ради возможности приговаривать, что ищут инженеров x100, как в былые времена.
Если посмотреть на различия былых времён и сейчас, (Да и десять лет назад уже относились к сейчас, а не к былым временам. ) сразу можно сделать несколько наблюдений:
Инженерам в FAANG/MANGO на многих направлениях уже давно не платят, как в былые времена. Был момент, (Ещё на пятнадцать лет назад. ) когда инженер или управленец продукта X, который для компании был краеугольным камнем в контексте «Либо сделаем, либо сдохнем», и даже инженер продукта Y, стоящего рядом с X, мог за два года заработать себе на всю жизнь и/или превращение программистского хобби в отдельный от компании бизнес.
Многие из контор уже совсем не вчера отрезали по куче причин (Из-за социальных, если их так можно назвать, трений, невозможности униварсально уровни маркировать и прочего. ) R&D от чистого Research и их обоих от продуктовой разработки, проводимой силами штатных сотрудников.
Наверняка наблюдений можно сделать больше, но навскидку вот два, и кажется мне, что всё вполне закономерно: какой-нибудь Google или Microsoft не сдохнут быстро, даже если gmail ляжет на неделю или половина регионов Azure будет полыхать несколько дней, отделавшись своими типичными: «У нас пять девяток, поэтому извините. Вот вам, собственно, извинения и купон на скидку в нашей шаурмичной». При таком раскладе НИОКР и даже продуктовый x100 — действительно от лукавого!
Dhwtj
Ну, судя по тому что эйджизм появился именно в faang, то массово там всегда работали молодые и не очень умные задроты тушканчики на износ, пока молодость позволяла затыкать дыры переработками и штурмовщиной
И вопрос про вращение деревьев именно что задротский
apcs660
Соглашусь
aabzel
Да. Именно так. Сам работал в яндексе. Такие Авгиевы конюшни в коде каршеринга ещё поискать надо.
Dhwtj
Чтобы расчистить Авгиевы конюшни нужно лет 5 судя моему опыту. Первые 2 года просто въехать в тему.
Видимо, у Яндекса нет 5 спокойных лет чтобы такое планировать. Вот и получается этакий СДВГ в бизнесе