После трех лет в IT меня меньше всего бесит код. Код хотя бы честная сущность. Если он сломан, он обычно не делает вид, что это часть командной культуры.

Гораздо сильнее меня начали бесить вещи вокруг разработки. Не самые красивые слова, знаю. Но после какого-то момента романтика про “интересные задачи”, “сильные команды” и “рост в профессии” сталкивается с довольно приземленной реальностью: люди, процессы, ответственность, созвоны и куча шума вокруг работы, который почему-то очень часто выдают за саму работу.

Я пишу это не как человек с двадцатью годами опыта и спокойствием Будды. Я пишу это как человек, который всего три года в профессии, но уже достаточно насмотрелся, чтобы понять простую вещь: чаще всего выматывает не сложность. Выматывает хаос, который взрослые люди почему-то считают нормой.

Меня бесит безответственность

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

Меня правда раздражают компании и руководители, которые хотят играть в “мы строим серьезный продукт”, но при этом живут в режиме бесконечной импровизации. Сегодня у задачи один приоритет, завтра другой. Сегодня “это срочно”, через два дня про это уже никто не помнит. Сегодня наняли человека под одну роль, через неделю внезапно выясняется, что вообще-то от него ждали совсем другого, просто никто нормально это не сформулировал.

И вот это для меня одна из самых неприятных вещей. Потому что это не сложность рынка. Это не форс-мажор. Это не “ну всякое бывает”. Это обычная взрослая безответственность, за которую почему-то расплачиваются все вокруг, кроме тех, кто ее производит.

Особенно странно это выглядит в моменте найма. Если ты не умеешь строить процессы, не понимаешь, как ставить задачи, не можешь держать слово и вообще не очень представляешь, зачем тебе команда, может, не надо пока делать вид, что ты строишь компанию. Бизнес - это не ролевка в стиле “давайте попробуем побыть взрослыми”. Когда ты берешь человека на работу, ты берешь на себя вполне реальную ответственность за его время, деньги, нервы и кусок жизни.

И да, я понимаю, что идеальных мест не бывает. Но между “в любой работе есть шероховатости” и “вся система держится на авось” разница все-таки огромная.

Меня бесит эмоциональная незрелость в команде

Есть отдельный тип боли, который вообще не связан с кодом. Это люди, которым почему-то очень хочется работать в коллективе, хотя само существование других людей их буквально раздражает.

Я сейчас не про интроверсию. Не про усталость. Не про плохой день. Я про эмоциональную незрелость, которая потом маскируется под “я просто прямой человек”, “я такой требовательный”, “я не люблю тупые вопросы”, “ну я же сказал по фактам”.

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

И вот это для меня одна из самых утомительных вещей в IT. Потому что техническую проблему еще можно разобрать. Можно открыть код, документацию, логи, diff, найти причину, переделать. А когда взрослый человек не умеет не раздражаться от чужого вопроса, чужой формулировки или просто самого факта диалога, это уже совсем другая категория проблемы.

Самое ироничное, что в профессии, где все любят говорить про командную работу, коммуникацию и engineering culture, огромное количество энергии все еще тратится на очень базовую вещь: научиться разговаривать так, чтобы после созвона никому не хотелось закрыть ноутбук и исчезнуть в лесу.

Да, я не люблю писать тесты

Сейчас будет социально опасный момент.

Я не люблю писать тесты.

Сразу уточню, чтобы меня мысленно не вынесли из профессии: я понимаю, зачем они нужны. Я радуюсь, когда хороший тест ловит регресс до продакшена. Я понимаю ценность проверок на критических сценариях. Я вижу, как нормальный test suite делает систему спокойнее и предсказуемее. Все это правда.

Но любить сам процесс написания тестов я пока так и не научилась.

Особенно когда тесты пишутся не потому, что это правда снижает риск, а потому что “ну у нас должно быть 80% coverage”. Особенно когда unit-тест знает о внутренностях реализации больше, чем стоило бы, и падает не потому, что сломалось поведение, а потому что кто-то слегка переставил мебель в коде. Особенно когда e2e превращается в ритуал вызова дождя: локально зелено, в CI красно, потом наоборот, потом все делают вид, что проблема временная.

Наверное, меня раздражают не сами тесты, а имитация инженерной зрелости через тесты. Когда вместо реального вопроса “что здесь действительно опасно сломать?” включается механика “давайте просто обложим все проверками и будем надеяться на лучшее”.

Я люблю надежные системы. Я люблю, когда после релиза не страшно. Я люблю, когда критичные сценарии защищены. Но сам процесс написания тестов до сих пор не вызывает у меня никакой романтики. И, если честно, мне даже нравится иногда говорить это вслух. Хотя бы потому, что в IT слишком много вещей принято обсуждать как догму, а не как живую практику со всеми ее компромиссами.

Меня бесит не медленное мышление, а вязкость

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

Меня бесит именно вязкость.

Это тот режим, в котором один merge request можно обсуждать пять часов на созвоне. Когда вместо комментариев в diff собирают отдельную встречу, потом еще одну встречу, потом “давайте синкнемся после обеда”, а потом внезапно выясняется, что все это время спорили о вещи, которая вообще должна была быть зафиксирована в правилах команды еще полгода назад.

Вот это меня бесит.

Не потому, что я за бездумный speedrun разработки. А потому, что очень часто за такой медлительностью нет глубины. Там нет исследования, нет особой аккуратности, нет сложности задачи. Там просто нет структуры. Нет договоренностей. Нет умения заранее определить, что именно мы считаем good enough и где вообще заканчивается обсуждение.

В такие моменты особенно хорошо видно, что выгорание в IT рождается не только от нагрузки. Оно прекрасно рождается от ощущения вязкого бессилия, когда огромный объем времени уходит не на работу, а на процесс вокруг работы.

Чтобы это не выглядело как чистый эмоциональный монолог, коротко та же картина в таблице.

Теперь про техническую часть, которая правда выматывает

Если убрать эмоции и оставить только инженерную суть, то меня сильнее всего выматывают четыре вещи.

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

Вторая - хаос, который выдают за гибкость. Мне вообще кажется, что в IT слово “гибкость” иногда используют как очень вежливый синоним фразы “мы пока ничего нормально не договорили”. Гибкость хороша там, где есть сильная база. А когда базы нет, гибкость очень быстро превращается в ситуацию, где каждый пишет как чувствует, каждый понимает архитектуру по-своему, а общий проект потом каким-то чудом должен собраться в единое целое.

Третья - культ бесконечных обсуждений вместо инженерных решений. Есть вещи, которые реально надо обсуждать: архитектурные развилки, риски, миграции, публичные контракты, критичные продуктовые сценарии. Но очень много того, что у нас принято тащить в часовые созвоны, можно было бы решить нормальным описанием правил, коротким RFC, адекватным code review или просто способностью формулировать мысль письменно.

И четвертая - технический долг, на который все смотрят как на погоду. Как будто это стихийное бедствие, а не результат вполне конкретных решений. Когда в проекте копятся хрупкие абстракции, дублирование, полумертвые слои, костыли поверх костылей, нестабильные тесты и странные временные решения, это не просто делает код некрасивым. Это делает любую будущую работу дороже. В какой-то момент ты уже не разрабатываешь, а все время платишь проценты по чужим вчерашним компромиссам.

Если разложить это по слоям, картина обычно выглядит так:

И все-таки меня бесит не профессия

Самое смешное, что после всего этого я не разлюбила саму разработку.

Мне по-прежнему нравится собирать интерфейсы, разбираться в логике, упрощать сложное, находить слабые места в системе, превращать хаос в более понятную структуру. Мне нравится момент, когда задача из расплывчатого “что-то не так” превращается во вполне конкретное инженерное решение. Мне нравится, когда код становится яснее, а продукт - внятнее.

Меня бесит не IT как профессия. Меня бесит количество лишнего шума вокруг нее.

Меня бесит, когда взрослые люди не хотят быть взрослыми. Когда ответственность подменяют энтузиазмом. Когда зрелость подменяют резкостью. Когда инженерную работу подменяют бесконечными разговорами о работе. Когда надежность подменяют цифрой coverage. Когда темп подменяют пятичасовым обсуждением одного MR.

И, наверное, это даже не самый плохой симптом после трех лет в профессии.

Потому что, если честно, гораздо хуже было бы привыкнуть к этому и начать считать нормой.

Код хотя бы можно открыть, прочитать и поправить. С некоторыми процессами и людьми такой роскоши пока не завезли.