Или почему код — не единственное, что нужно дебажить
Если вы хотя бы раз теряли данные из-за забытого git commit, слышали от заказчика «хочу нейросеть, но на Excel» или тушили прод в 3 часа ночи — вы уже знаете, что хаос неизбежен. Но что, если философия древних стоиков поможет вам не просто выживать, а прокачать свою mental CI/CD? Добро пожаловать в стоицизм для айтишников: без фатализма, зато с метафорами, которые поймут даже бэкендеры.
1. «Дихотомия контроля», или Как перестать душнить из-за кривых ТЗ
Эпиктет говорил: «Наше мнение о событиях, а не сами события, вызывают страдания». В переводе на IT:
- Ваш контроль: архитектура кода, тесты, выбор фреймворка.
- Не ваш контроль: бесконечные правки ТЗ, внезапные «хотелки» клиента, ошибки в чужом API.
Как применить (и при чём тут РЭПТ):
- Когда заказчик просит «сделать ИИ для тостера», вместо внутреннего взрыва спросите: «Что я могу сделать в рамках своих полномочий?».
- Это основа рационально-эмотивной терапии (РЭПТ): разделяйте факты («клиент неадекватен») и вашу реакцию («я не обязан это терпеть»).
2. Негативная визуализация: Прокачиваем resilience через «представь, что прод упал»
Сенека практиковал premeditatio malorum — мысленную подготовку к провалам. Для разработчика это:
- Перед деплоем спросите: «Что, если всё сломается?».
- Заранее продумайте rollback-план, бэкапы и шаблон сообщения для тимлида в стиле «Мы всё починим, кофе уже в пути».
Почему это работает:
Техника похожа на CBT-экспозицию: вы снижаете тревогу, сталкиваясь со страхом в воображении. А если прод не упадёт — станете героем спринта.
3. «Баг — это не фича, а таск для следующего релиза»
Марк Аврелий писал: «Препятствие становится путём». В мире разработки это:
- Ошибка в коде — не конец света, а повод улучшить тестирование.
- Злиться на себя за косяк — всё равно что ругать компилятор за синтаксическую ошибку.
Как перестать корить себя (спойлер: через ACT):
- Вместо «Я лузер, этот баг всё испортил!» скажите: «Этот баг показал слабое место в архитектуре».
- Это основа терапии принятия и ответственности (ACT): проблемы — часть пути, а не повод для самобичевания.
4. «Стоический спринт»: Замените перфекционизм на итеративность
Стоики не стремились к идеалу — они стремились к прогрессу. Ваш код тоже не обязан быть perfect с первого коммита:
- Сдайте фичу в срок, даже если coverage 85%, а не 100%.
- Помните: рефакторинг существует не просто так, а техдолг — это legacy, а не провал.
Практика из DBT:
Разбейте задачу на подпункты (как в Jira). Тревога любит абстрактное «всё плохо», но теряет силу перед конкретными тасками вроде «написать функцию X».
5. Настройте «триггеры» для эмоций, как обработчики событий в коде
Ваш мозг — не legacy-система. Его можно «рефакторить»:
- Шаг 1: Поймали мысль «Мы ничего не успеем!».
- Шаг 2: Включите режим «декомпозиции»: разбейте задачу на подпункты.
- Шаг 3: Сфокусируйтесь на первом пункте.
Почему это CFT (сострадательная терапия):
Относитесь к себе как к джуну, который учится. Вместо: «Ты что, не мог проверить код?!» — скажите: «Следующий релиз будет лучше».
Итог: Зачем вам стоицизм?
Он не сделает клиентов адекватными, а код — безупречным. Но научит:
- Тратить силы только на то, что в вашей зоне контроля (например, настройку линтеров).
- Видеть в провалах задачи для роста, а не поводы для паники.
- Сохранять face control даже при краше тестовой среды.
Как говаривал Марк Аврелий: «Делай своё дело хорошо. Остальное не важно». Или, если перевести на язык Scrum: «Keep calm и завершай спринт».
P.S. Важное уточнение: стоицизм — не про игнорирование эмоций, а про их распознавание. Как логгирование ошибок: если «падение прода» вызывает панику — это сигнал, а не слабость. И да, если стресс превращается в перманентный 500-й статус — пора к специалисту.
P.P.S. Цезарь, конечно, не деплоил завоевания через Git, но его главный секрет — «ничего личного, просто бизнес-логика».