Чем не хочешь заниматься на новом проекте?

Чем я не хочу заниматься на новом проекте

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

1. Legacy code без возможности улучшения

Я готов работать с legacy code. Это часть профессии. Но я не готов работать с legacy code, который невозможно трогать из-за организационных причин.

Если код технически долго, но есть freedom его улучшать — это интересно. Если code freeze + political constraints — это kill motivation.

Что я буду делать: если начну видеть такую ситуацию, буду говорить об этом честно и ранго. Предложу small refactoring wins, которые докажут value.

2. Микроменеджмент и отсутствие доверия

Я работаю лучше всего, когда мне доверяют. Микроменеджмент — это signal, что либо я не подходу, либо менеджер не уверен в себе.

Не жду полной свободы. Жду честного диалога: вот goal, вот constraints, вот как мы измеряем успех. Затем trust мне найти путь.

3. Технический долг, который игнорируют

Я понимаю, что баланс между features и tech debt нужен. Но если tech debt растёт экспоненциально и никто не берёт ответственность — это тревожный флаг.

Это не значит, что нужно refactor всё сразу. Но нужна стратегия: мы платим tech debt в спринте 2 из каждых 5, или мы выделяем 20% времени на улучшения.

4. Zero testing culture

Не нужны 100% coverage. Но если вообще нет культуры тестирования и люди думают, что тесты — это пустая трата времени — я буду feel uncomfortable.

Тесты спасают жизнь проектов. Если team это не видит, это проблема education, не моей вины.

5. Постоянный crunch mode

Иногда crunch нужен. Дедлайн, и нужно deliver. Но если это lifestyle проекта — это unsustainable.

Я буду push back на unrealistic дедлайны. Я буду предлагать альтернативы: MVP версия фичи, или delay release.

6. Политика и бюрократия вместо логики

Если решения принимаются не на основе data/logic, а на основе того, кто более влиятельный — это не моя среда.

Особенно в техничских вопросах. "Это требует architect approval" — ok. "Это требует approval от director, который не понимает код" — нет.

7. Невозможность повлиять на technical direction

Хороший разработчик не просто пишет код, он помогает team принимать лучше решения. Если мой голос не слышен в техничских дискуссиях — зачем я здесь?

Как я это буду коммуницировать

Я не буду делать ultimatum. Я буду честным: "Я вижу, что technical debt растёт. Мне нужно понять, есть ли план это адресировать".

И если ответ "нет» — тогда я подумаю, подходит ли мне эта роль.

Итог

Это не о том, что я привередлив. Это о том, что я хочу работать в environment, где я могу быть лучшим разработчиком, которым я могу быть. И это требует определённых условий.