С некоторыми вещами бороться бесполезно

Наткнулся на классную статью о корпоративных культурах и ограничениях для разработчиков https://newsletter.pragmaticengineer.com/p/how-to-become-a-more-effective-engineer

В ней – много информации для размышления о том, как на самом деле во многих компаниях принимаются решения. Спойлер – принимаются они не исходя из инженерной логики и идей о красивой архитектуре. Хотя статья позиционируется для IC, я, помимо того, чтобы дать ее почитать всем разработчикам в команде, советую пролистать и лидам, тк многие из проблем или нереалистичных ожиданий, мешающих разработчикам, переезжают и в жизнь руководителей.

––

Несколько хайлайтов из статьи:

– Техдолг: значительных инвестиций в его разгребание, скорее всего, не будет, пока он не начнет понятным образом мешать бизнесу (если не сейчас – то в обозримом будущем). Приоритизировать его «потому что архитектурно правильно» ты почти наверняка не сможешь, и это нормально

– Помимо формальной иерархии часто есть неформальная – какие-то люди имеют бОльший вес в принятии решений, какие-то меньше, и это может быть не связано с должностями. Она нигде официально не отражена, но, не изучив её, ты постоянно «неожиданно» будешь натыкаться на преграды

– Помимо неформальной иерархии, обычно есть еще и неофициальный набор правил принятия решений. И он тоже может быть не-инженерно-обоснованным. Например «по умолчанию мы задачи типа А на стэке Б»; «в сервисах X и Y за баги у нас расстреливают, а в сервисе Z можно и забить»; «большинство фичей мы катим через А/Б, но если её принес воооот этот человек – то надо просто взять и релизнуть»; и тд. Покопавшись, под некоторыми из них ты обнаружишь логику, под некоторыми – ничего не обнаружишь, но..бороться с идеологией почти всегда бесполезно. Unless ты являешься руководителем, которого наняли её поменять. И, как и в случае с неформальной иерархией – эти правила нужно изучить и научиться решать проблемы, учитывая их, иначе ты, опять же, «неожиданно» будешь получать палки в колеса

– Самый ценный в современно IT скилл – умение работать в бардаке. Да, сервисы не документируют не только в твоей команде. И – да, тонна легаси закопана почти в любом успешном и выросшем бизнесе. И..да, неформальная иерархия и процессы очень часто не соответствуют формальным. Это не «тебе с текущим местом не повезло» – это почти везде так. Так что быстро изучать неформальные правила и проблемы, разгребать кучу недокументированного говнокода – это базовые навыки для успешной карьеры

В статье гораздо больше (вместе с полезными ссылками на другие материалы), советую прочесть полный вариант 🙂