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

Однако это полная ерунда.

Миф о «возрасте выхода на пенсию программистов в 35 лет» преследует технологическую индустрию, как призрак, который отказывается признать, что его развенчали тысячу раз. Это своего рода мифология, которая передаётся в сообщениях Slack и темах технического Твиттера, о которой шепчут на конференциях и которую поддерживают люди, которые никогда не занимались реальными расчётами. И всё же как-то он сохраняется — идея-зомби, которая продолжает шататься по нашей отрасли, даже когда доказательства против него накапливаются выше стопки неухоженных устаревших систем.

Миф, который не хочет умирать

Давайте сначала затронем очевидное: нет, у программистов не должно быть обязательного возраста выхода на пенсию. Ни в тридцать пять, ни в сорок пять, ни в шестьдесят пять. И дело не только в том, что обязательный выход на пенсию ethically questionable (хотя это абсолютна правда), но и в том, что это функционально абсурдно. Это противоречит всему, что мы знаем о том, как на самом деле работает программирование, как на самом деле развиваются карьеры и насколько на самом деле ценен человеческий опыт.

Происхождение этой теории о «выходе на пенсию в 35 лет» туманно, как и большинство интернет-слухов. Некоторые люди обвиняют в этом предполагаемую неспособность мозга приобретать новые технические знания после тридцати пяти. Теория гласит, что примерно в этом возрасте нейропластичность постепенно снижается, рефлексы замедляются (постойте, мы же разработчики, а не спортсмены), и вы просто не можете угнаться за неумолимым темпом технологических изменений. Каждый вторник появляются новые фреймворки. Языки эволюционируют. Парадигмы меняются. Конечно, теория предполагает, что только молодые и гибкие могут справиться с таким хаосом.

Проблема? Эта теория построена на ошибочной науке и ошибочных наблюдениях.

Наблюдательная часть особенно интересна. Люди смотрят на технические компании и думают: «Хм, я не вижу здесь много сорокалетних разработчиков. Следовательно, программисты должны выходить на пенсию в тридцать пять». Но это классическая логическая ошибка. Точное наблюдение должно быть таким: «В последние годы в отрасль было добавлено огромное количество младших программистов». Численность программистов растёт в геометрической прогрессии. Мы не теряем старших разработчиков; мы затоплены младшими. Соотношение смещается не потому, что старшие разработчики исчезают, а потому, что новые разработчики появляются с такой скоростью, что закон Мура кажется устаревшим.

Премия за опыт, о которой никто не говорит

Вот что на самом деле происходит, когда программист достигает середины тридцатых и старше: они становятся лучше. Не хуже. Лучше.

Я понимаю, что это может звучать так, будто я пытаюсь продать вам самоучитель, но подумайте, что накопил опытный программист к этому моменту. Они:

  • отлаживали системы в три часа ночи и узнали, что на самом деле важно, а что просто выглядит впечатляюще при просмотре кода;
  • потерпели неудачу в достаточном количестве проектов, чтобы рано распознавать паттерны неудач;
  • поработали с достаточным количеством разных кодовых баз, чтобы отличать «это действительно проблематично» от «это просто отличается от того, к чему я привык»;
  • разработали достаточное количество побочных проектов, профессиональных приложений и внутренних инструментов, чтобы выработать подлинную интуицию о том, что работает;
  • наставляли (или должны были наставлять) достаточное количество младших разработчиков, чтобы понять, как ясно объяснять сложные концепции;
  • пережили достаточно технологических волн, чтобы знать, что JavaScript-фреймворки на самом деле не бессмертны.

Настоящий поворот? Старшие разработчики могут выполнять работу целых команд. Это не гипербола — это просто математика. Разработчик с двадцатилетним опытом, работающий на полную мощность, принимающий разумные архитектурные решения и избегающий ошибок, которые потребовали бы недель переработки, может достичь того, на что команде из шести младших разработчиков потребуются месяцы. Они не пишут больше строк кода (они пишут меньше, и лучше). Они пишут код, который другие люди могут понять и поддерживать.

И вот неудобная часть, которую никто в Силиконовой долине не любит признавать: опыт накапливается.

Реальная проблема — не возраст, а экономика

Если обязательный выход на пенсию для программистов — такая ужасная идея, почему миф сохраняется? Почему старшие разработчики сообщают о трудностях с поиском работы? Почему эйджизм в сфере технологий ощущается таким реальным?

Ответ не в том, что программисты действительно становятся неспособными в тридцать пять. Ответ в том, что индустрия выстроила экономическую структуру, в которой менеджеры по найму оптимизируют определённые факторы, которые, как оказывается, коррелируют с молодостью — и мы перепутали корреляцию с причинно-следственной связью.

Рассмотрим рынок найма: младший разработчик может стоить 60 000 долларов в год. Разработчик среднего уровня может стоить 120 000 долларов. Старший разработчик с двадцатилетним опытом может стоить 180 000 долларов или больше. Они не могут извлечь столько относительной ценности из опыта старшего разработчика — или так гласит логика. Экономика, кажется, благоприятствует молодым работникам, особенно в компаниях, оптимизирующих рост, а не прибыльность.

Но вот где математика становится интересной. Младший разработчик стоит меньше за единицу времени, это верно. Но стоимость за продуктивную отдачу? Это совершенно другой расчёт. Старший разработчик, который выполняет проект за три недели, по сравнению с младшей командой, которая выполняет его за три месяца, на самом деле обходится дешевле в общей компенсации, даже при более высокой почасовой ставке. Добавьте сюда снижение технического долга, меньшее количество критических ошибок и лучшие архитектурные решения, и старший разработчик становится выгодной сделкой.

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

Навыки, которые имеют значение, никогда не устаревают

Позвольте мне кое-что уточнить: идея о том, что программисты не могут изучать новые технологии после тридцати пяти, явно ложна.

Человеческий мозг не перестаёт функционировать в тридцать пять. У нейропластичности нет жёсткой даты отключения. Что происходит, так это то, что обучение становится более осознанным и эффективным. Тридцатипятилетний, изучающий Rust, не запоминает синтаксис так, как это мог бы сделать двадцатипятилетний. Вместо этого они сопоставляют концепции Rust с существующими ментальными моделями из десятка других языков, которые они уже освоили. Они понимают управление памятью, компромиссы и принципы системного проектирования на более глубоком уровне, поэтому они изучают Rust быстрее и лучше, даже если процесс обучения выглядит иначе.

Технологии, которые вы используете, на самом деле наименее важная часть того, чтобы быть хорошим программистом. Они похожи на погоду — постоянно меняются, но фундаментальные правила физики не меняются. Важно понимание:

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

Эти навыки не имеют ничего общего с возрастом. И если что-то и становится проще с опытом.

Практическая структура: когда опыт действительно имеет значение

Позвольте мне привести вам конкретный пример, где опыт имеет абсолютное значение. Рассмотрим сценарий, где вы проектируете новую систему:

# Подход младшего разработчика (псевдокод)
class UserService:
    def get_user(self, user_id):
        return fetch_from_database(user_id)
    def update_user(self, user_id, data):
        validate_user_input(data)
        update_database(user_id, data)
        return fetch_from_database(user_id)
    def delete_user(self, user_id):
        delete_from_database(user_id)

Это работает. Всё нормально. Это также бомба замедленного действия.

# Подход старшего разработчика (с решениями, основанными на опыте)
class UserService:
    def __init__(self, db, cache, event_bus, audit_log):
        self.db = db
        self.cache = cache
        self.event_bus = event_bus
        self.audit_log = audit_log
    def get_user(self, user_id, bypass_cache=False):
        if not bypass_cache:
            cached = self.cache.get(f"user:{user_id}")
            if cached:
                return cached
        user = self.db.fetch_user(user_id)
        if user:
            self.cache.set(f"user:{user_id}", user, ttl=3600)
        return user
    def update_user(self, user_id, data, actor_id):
        existing_user = self.get_user(user