Вечер. Сложный тикет закрыт, тесты зеленые. Заказчик доволен, ПМ ставит 🔥 в чат, на карту упала зарплата, которая в Nx раз выше средней по региону.
Внешний мониторинг (Grafana вашей жизни) показывает стабильное плато и Status 200 OK. А внутри, на уровне ядра, возвращается 500 Internal Server Error.
Ощущение, будто ты Mock-объект. Фейковая заглушка, которая только имитирует полезную деятельность и возвращает захардкоженные ответы. Кажется, что внутри спагетти-код, TODO-комментарии пятилетней давности и костыли на изоленте. И фоном крутится демон с приоритетом Critical:
"Рано или поздно они запросят
git blame, заглянут в исходники и поймут, что я ничего не умею. Все узнают, что я джун, который просто удачно притворяется сеньором".
Это баг в модуле самооценки, известный как "Синдром Самозванца". В нашей инженерной реальности - это критический рассинхрон между показателями Внешнего Мониторинга (карьера, деньги, фидбек) и Unit-тестами (внутреннее ощущение компетентности).
Давайте проведем Post-Mortem анализ этого инцидента. Почему инженеры с 10-летним опытом боятся, что их раскроют?
Баг 1. Сравнение своего Бэкенда с чужим Фронтендом
Мы часто попадаем в классическую ловушку некорректного сравнения архитектур. Что мы знаем о себе? Мы имеем root доступ к своему Бэкенду и базе данных. Мы видим:
Тот самый
if-elseкостыль, который пришлось вставить в 3 ночи, чтобы релиз не упал.Историю поиска: "как центрировать div" или "разворот списка Python" на десятом году карьеры.
Логи ошибок, паники при деплое и часы прокрастинации на Reddit.
А что мы видим у других (коллег, спикеров на HighLoad, авторов статей на Хабре)? Мы видим их отрендеренный Фронтенд:
Красивый UI успешных кейсов.
Уверенный голос на дейли.
Статьи "Как мы переписали монолит на микросервисы за выходные и сэкономили миллион".
Попытка сравнить свои сырые логи (stderr) с чужой главной страницей (index.html) неизбежно выдает TypeError: Incompatible Types.
Мы просто не видим, как этот "Гениальный Тимлид" пил валерьянку перед митингом, а "Крутой Архитектор" скопипастил кусок решения со StackOverflow и потом два часа не мог понять, почему оно не билдится. Нам виден только фасад. Из-за этого возникает иллюзия, что легаси и бардак под капотом только у нас. Спойлер: бардак, скорее всего, у всех. Просто у сеньоров он лучше документирован и обернут в Docker-контейнер, чтобы не воняло.
Баг 2. Deprecation Warning и гонка фреймворков
Второй источник ошибки - скорость обновления зависимостей в нашей индустрии. В медицине анатомия человека не меняется тысячелетиями. В юриспруденции законы живут десятилетиями. В IT твои знания устаревают быстрее, чем молоко в холодильнике.
Ты потратил 3 года на изучение крутого фреймворка, стал экспертом. А сегодня утром на HackerNews вышла статья: "Почему Х - это отстой, мы все переходим на Y". В консоли твоей головы постоянно висит предупреждение: Warning: Your skills are deprecated. Please update to v.2026.0
Из-за этого возникает ощущение, что ты вечный студент, который опаздывает на лекцию. Мы путаем Фундаментальные Алгоритмы (которые не меняются) с Синтаксическим Сахаром (который меняется каждый год). Тот факт, что мы не знаем, как работает новая фича в React 19 или финтифлюшка в AWS, не делает нас плохим инженером. Это просто проблема кэширования - мы еще не загрузили новые данные.
Баг 3. Flaky Tests (Мигающие тесты)
Похоже, что конфиг нашего внутреннего "QA-отдела" сломан. Внутренние тесты на профессионализм (Self-Tests) написаны криво и почти всегда возвращают False, независимо от качества инпута.
Давайте посмотрим на код этого внутреннего теста:
Python
def test_im_a_good_engineer(self):
# INPUT: Успешный релиз сложной фичи
result = self.deploy_to_prod()
if result == "SUCCESS":
# ОЖИДАЕМОЕ ПОВЕДЕНИЕ: self.pride += 10
# РЕАЛЬНОЕ ПОВЕДЕНИЕ:
raise ImposterError("Просто повезло, QA плохо смотрели")
# INPUT: Коллега спросил совета
if self.answer_question():
# РЕАЛЬНОЕ ПОВЕДЕНИЕ:
raise ImposterError("Я это нагуглил 5 минут назад, я обманщик")
# INPUT: Повышение зарплаты
if self.salary_increase():
# РЕАЛЬНОЕ ПОВЕДЕНИЕ:
raise ImposterError("Рынок перегрет, они просто не нашли никого лучше")
Это классические Flaky Tests. Тест падает не потому, что система (вы) работает плохо, а потому что сама процедура проверки (Я должен знать всё наизусть и никогда не ошибаться) некорректна. Мы требуем от себя быть Википедией, но в ТЗ к живому инженеру таких требований нет. В ТЗ написано: решать задачи бизнеса.
ПАТЧ: Как пофиксить баги восприятия?
Просто "поверить в себя" - совет сомнительный (это как сказать перегретому серверу "не грейся, братан"). Попробуем применить инженерные решения.
Фикс 1. Переход на External Monitoring (Логи не врут)
Внутренние ощущения - это Client-Side Validation. Она ненадежна, зависит от браузера (настроения), погоды и уровня выгорания. Опираться на неё для принятия решений рискованно. Единственный источник правды - Server-Side Logs (Внешний мир).
Вам платят деньги? (Лог транзакции подтвержден).
Вас не уволили за год? (
Uptime> 99%).Ваш код работает в проде и приносит деньги? (
Status 200).Коллеги просят помощи? (Значит, ваша API документация востребована).
Если внешняя система мониторинга (рынок, работодатель, команда) говорит, что вы Сеньор, а внутренняя система утверждает "Ты самозванец", то с вероятностью 99.9% ошибка на внутренней стороне. Рынок рискует своими деньгами, нанимая вас. А ваши страхи не рискуют ничем. Факты - единственная метрика, которая имеет значение в инженерии.
Фикс 2. Black Box и Кэширование
Нужно переписать интерфейс IEngineer. Сместить фокус с "я должен знать всё" (In-Memory DB) на "я умею находить решения" (High-Load Gateway). Сеньор - это не ходячая энциклопедия. Это интерфейс, который умеет эффективно маршрутизировать запросы.
Не так важно, как решена задача: написана по памяти, найдена в документации или адаптирована с индусского ютуба. Для бизнеса инженер - это Black Box.
Input: Задача.
Output: Работающее, поддерживаемое решение.
Performance: Приемлемое время (Latency).
Что происходит внутри коробки - магия нейросетей мозга, Google или StackOverflow - это детали реализации. Использование Google - это не читерство, это работа с распределенной базой знаний. Мы просто "выгрузили из RAM в Cloud", чтобы освободить память для решения текущей задачи.
Фикс 3. Brag Document (Логирование успехов)
Человеческая память работает как logrotate - старые логи удаляются. Мы отлично помним свои факапы трехлетней давности, но забываем, какую крутую фичу запилили месяц назад. Решение: Завести текстовый файл success_log.md (или Brag Document). Например, раз в две недели записываем туда списком:
Что я сделал?
Что я изучил?
Кому я помог?
Когда накатывает приступ "я ничего не умею", открываем этот лог. Это лучший способ борьбы с когнитивными искажениями с помощью хард-данных.
Итог
Эффект Даннинга-Крюгера работает в обе стороны. Настоящая некомпетентность редко сомневается в себе. Наличие сомнений, страха облажаться и ощущения "я недостаточно хорош" - это часто техническое доказательство компетентности.
Только специалист высокого уровня способен оценить объем того, чего он еще не знает. Наша область "Неизвестного" растет пропорционально области "Знаний". Так что этот страх - индикатор того, что наша база знаний расширилась и соприкоснулась с новыми сложными доменами.
Если код в мастере, а прод не лежит, значит, мы на своем месте. А то, что иногда страшно - так это просто шум кулера под нагрузкой. Процессор работает.
Самое время нажать Deploy.
P.S. Коллекционирую такие баги мышления и ищу к ним патчи в своем телеграмм-канале.
