Ответ
- Нечеткие или постоянно меняющиеся требования (Scope Creep). Работа по уточнению «что нужно сделать» начинает занимать больше времени, чем сама разработка.
- Медленные или бюрократизированные процессы. Долгое ожидание code review, сборки (build), развертывания или согласований.
- Накопленный технический долг без возможности его рефакторинга. Приходится постоянно «костылять» и обходить проблемы в legacy-коде.
- Микроменеджмент. Отсутствие доверия и автономии, излишний контроль над каждым шагом.
-
Нарушение договоренностей в команде. Например, коллега меняет публичный API библиотеки, не уведомив об этом и не обновив версию.
// Было: стабильный контракт public void ProcessOrder(Order order) { ... } // Стало: ломающее изменение без коммуникации public void ProcessOrder(Order order, bool isPriority) { ... } - Перегруженный график встреч (meeting hell). Когда митинги не оставляют непрерывного времени для глубокой работы над кодом.
- Игнорирование лучших практик и стандартов. Отсутствие unit-тестов, проверки кода (code review), неправильное использование асинхронности (
async/await).
Как смягчить:
- Внедрять и соблюдать соглашения команды (conventions).
- Автоматизировать рутину: CI/CD, линтеры, форматтеры кода.
- Регулярно проводить ретроспективы, чтобы открыто обсуждать боли и находить решения.
Ответ 18+ 🔞
А, ну вот, классика жанра, блядь. Сидишь такой, кодишь, а тут на тебе — полный набор для выгорания, в рот меня чих-пых. Давай по пунктам, как есть.
1. Требования, которые пляшут хуй с горы. Только вчера заказчик орал «нужна синяя кнопка!», сегодня уже «ой, а давайте зелёную, и чтобы она мигала, и при нажатии играл гимн СССР». А завтра выяснится, что ему вообще не кнопка нужна, а слайдер. И вся твоя работа на день — на свалку. Работаешь не разработчиком, а экстрасенсом, ёпта.
2. Бюрократия и процессы, которые ползут, как улитка в асфальте. Ждёшь ревью кода три дня, а потом тебе пишут: «А тут, чувак, запятую лишнюю поставил». Сборка проекта запускается, можно сходить приготовить трёхразовое питание, вернуться — а она ещё идёт. Просто волнение ебать, когда деплой в прод — это квест на полдня с ритуалами и жертвоприношениями.
3. Технический долг, который уже не долг, а целая ипотека. Легаси-код, который выглядит, как будто его писал пьяный мартышлюшка с клавиатурой. Ты пытаешься новую фичу впилить, а он тебе: «Нет, браток, тут у нас в 2008 году костыль на костыле, и всё держится на скотче и молитвах». Рефакторить запрещают — «и так работает, не трогай». А потом удивляются, почему всё падает от чиха.
4. Микроменеджмент, доверия ебать ноль. Начальник-пиксельсчётчик. Каждые полчаса заглядывает через плечо: «Что там? А почему не так? А давай вот это переместим на два пикселя влево?». Чувствуешь себя не разработчиком, а марионеткой, у которой ни одной своей мозговой извилины не оставили. Сам от себя охуеешь.
5. Коллеги-распиздяи, которые ломают контракты, как хотят. Ты спокойно используешь библиотеку, а потом бац — и твой код не собирается. Смотришь, а какой-то гений взял и поменял публичный метод, даже мажорную версию не поднял.
// Было: всё стабильно, жизнь прекрасна.
public void ProcessOrder(Order order) { ... }
// Стало: сюрприз, ебанашка! Ломающее изменение из ниоткуда.
public void ProcessOrder(Order order, bool isPriority) { ... }И ищи потом, ветром сдуло, кто это сделал. Пидары налетели, короче.
6. Ад встреч (meeting hell). Весь день расписан по 30-минутным слотам. Только вник в задачу, погрузился — оп-па, пора на «еженедельный sync по синхронизации синков». Выходишь с митинга, а контекст в голове уже улетел, начинай сначала. Продуктивной работы — ноль ебать.
7. Игнорирование практик, как будто мы в 90-х пишем. Ни тестов, ни ревью, ни стайл-гайдов. Код выглядит, как свалка. Асинхронность используют по принципу «напихаем async/await — будет быстрее», а потом дебагят deadlock’и сутки напролёт. Пиздец, а не разработка.
Что делать, чтобы не сойти с ума?
- Договориться, блядь. Зафиксировать правила игры: как называем переменные, как ведём репозиторий, как меняем API. И держаться их, как святого писания.
- Автоматизировать всю эту рутину. Пусть машины проверяют код, собирают проект, разворачивают. Твоё дело — думать, а не кнопки тыкать.
- Говорить открыто. Ретроспективы — это не для галочки. Это чтобы высказать: «Мужики, вот это вот — пиздец, давайте больше так не делать». И вместе искать, как исправить.
А иначе так и будешь биться головой о клавиатуру, пока не накроешься медным тазом. Всё.