В багатьох технічно крутих програмістів є одна проблемка… Вони занадто тісно асоціюють себе з кодом, який пишуть для свого роботодавця. Це розуміло - крутий програміст тому і крутий, бо вкладає душу у свою роботу, живе проблемами проекту і всіляко намагається покращити код.
Шкода, але для менеджменту, в більшості випадків, такий порив не вартий уваги для відповідної оцінки та визнання: фіча працює - і добре. Або так: поки програміст оптимізує швидкість запиту на пару десятих секунди - CTO разом з CEO шукають де б закрити раунд на зарплати в наступному місяці.
В результаті, така ситуація призводить до різноманітних внутрішніх конфліктів і нормально так портить життя як програмісту так і менеджменту. Іноді ці конфлікти проявляються в таких дивних формах, що відразу не зрозуміло в чому його суть.
Вчитись треба у хірургів. Хто-хто, а вони вміють різати по живому. Треба - значить треба. Коли стоїть питання “життя чи смерті”, немає часу на душевні страждання - є задача і немає значення чий код потрібно видалити чи переписати. Може свій вчорашній, а може того колеги, який постійно підпирає баги костилями.
Це стосується не тільки коду, а в загальному будь-якої зробленої раніше роботи.
Якщо навчитись тримати дистанцію між собою і тим, що ви робите для роботодавця, вам відкриються нові горизонти в кар’єрі.
Несподівано, з вами почнуть радитись не тільки про те як назвати метод (дуже важливе питання, до речі) а й по більш практичних бізнес-питаннях. Чому? Бо ви зможете прийняти рішення холодно і прагматично, врахувати більше зовнішніх інваріант, ігноруючи свої емоції. І холоднокровно як хірург, викинути результат місячної роботи задля блага бізнесу.
З усією повагою та не зовсім погоджусь. Психологи це називають ментальним барєром який допомогає зменшити навантаження на психіку - абстрагування від проблеми. Але це не є вирішенням проблеми. Є 2 дві крайності - девелопер пише код відірвано від бізнес цілей. Бізнес пушить зміни інгоруючи технічні моменти. І це і це є призводить на довгій дистанції до поганих результатів.
Баланс між бізнесовими та технічними пріорітетами + профілактика технічного боргу - це якісне вирішення. Яке не потребує багато ресурсів. Добре побудована культура кодінгу - навпаки економить ресурси. Добре побудована культура кодінгу включає розуміння бізнес цілей та відображення цих цілей в архітекрурі, постійне досконалення та оновлення цієї архітектури у відповідності до зміни бізнес цілей.
З технічної сторони - якщо у вас часто рефакторінг, багато костилів, нові фічі викликають багато змін в існуючому коді, тоді ви можете не відповідати на питання чи є у вас дизайн тікети, якісні ревю на основі цих тікетів та дизайн принципів і паттернів, дизайн гайд вашої команди та TDD - бо якби були то цієї проблеми б просто не було.
З бізнесової сторони - ті самі проблеми можуть бути викликані тим що навантаження на команду не дозволяє доробляти проблеми до кінця, або команда не розуміє бізнесових задач і не робить прогнозів майбутніх челенджів. Найкраща метрика - еффективність команди - вона має постійно рости на протязі мінімум року від початку проекту, якщо це не так - то можливо ви занадто перевантажуєте команду - або в команди проблеми звязані з попереднім абзацом
Конфлікт між менеджером і девами це нормально - має бути на постійній основі - у вигляді обговорення. Тоді це не буде стрессом ні для кого, а рішеня стануть більш виваженими.