Я начал работать разработчиком программного обеспечения около 7 лет назад. С тех пор у меня было несколько разных должностей в разных компаниях.
Я начинал в отделе программного обеспечения инжиниринговой компании, где программное обеспечение либо является крошечной частью производимого продукта, либо просто поддерживает процесс его производства. Первым проектом, над которым я работал, была большая программа для одного человека, которая превратилась в огромный программный беспорядок. Мой начальник в то время и бывший «один человек» не были заинтересованы в том, чтобы что-то менять, и мой начальник не позволял мне делать что-то по-другому. Это очень расстраивало.
Как новичок, я пытался принять тот факт, что так обстоят дела, и какое-то время жил с этим. Позже я связался с боссом моего босса (назовем его Том) по поводу ситуации, в которой я оказался, и сказал ему, что она не соответствует ожиданиям относительно того, как я хочу писать программы.
В течение года у меня было несколько встреч с Томом, на которых я и мой коллега (который тем временем присоединился к команде) обсуждали ситуацию и то, что можно сделать, чтобы ее улучшить. Я на самом деле надеялся, что Том в какой-то момент вытащит моего босса и переоценит, кто будет руководить кораблем.
К сожалению, этого так и не произошло (по крайней мере, пока я был там — не так много времени прошло после того, как упомянутый коллега и я уволились).
На самом деле произошло не так уж и много. Я никогда не говорил Тому, что жду радикальных изменений. Что в обзоре я абсолютно должен был сделать.
В какой-то момент в разговоре с Томом он сказал мне, что я должен просто делать это так, как я думаю, не обсуждая это с моим боссом, и если будут какие-то проблемы, я должен просто сказать своему боссу, что именно так это было обсуждено с ним. . В этот момент я понял, что Том не выполняет свои обязанности лидера, заставляя меня обходить моего босса. Поэтому я ушел.
Теперь, спустя несколько лет и несколько очень похожих разочаровывающих ситуаций, я снова застрял в проекте, который вырос за многие годы, где у меня есть ощущение, что я единственный, кто заинтересован в том, чтобы шаг за шагом наводить порядок. в то время как мой новый босс снова не заинтересован в том, чтобы двигаться в этом направлении.
И снова встречи, на которых я пытаюсь указать, что нужно начинать создавать чистый софт, никогда не сопровождаются никакими действиями. И снова встречи нужно проводить с «Томью», потому что при непосредственном общении с начальником у меня не получается вести конструктивную дискуссию.
Теперь я начинаю сомневаться в выборе профессии. Может быть, я не создан для того, чтобы быть разработчиком программного обеспечения. Я просто не могу принять широко распространенное (как я понял) решение писать плохое программное обеспечение и исправлять его позже (чего, конечно же, никогда не происходит).
То ли мне просто не повезло с компаниями, к которым я присоединился, то ли я недостаточно ясно дал понять, что я не хочу этого делать. Или у них все хорошо, и мне нужно изменить свой домен на что-то другое (дизайн, управление проектами, что угодно).
Поздравляем, вы только что узнали, как выглядит более 90 % программного обеспечения для бизнеса.
Вы были не в том месте, чтобы применить свои навыки. Эти предприятия (которые составляют большинство предприятий, которые, в свою очередь, составляют большую часть программного обеспечения в производстве) не заботятся о техническом долге, потому что он не увеличивает их чистую прибыль — или, по крайней мере, они не видят этого. способ.
Вы можете попытаться убедить начальство в обратном, но это неблагодарное предприятие, потому что они, вероятно, приучены так думать. Кроме того, у вас есть парень из One Man Software , который работает там уже много лет, а теперь вы возитесь с его игрушкой. Не связывайтесь с чужими игрушками.
Я был в аналогичной ситуации, когда мы продали программный продукт, страдающий от технического долга, эквивалентного фискальному долгу Греции, и очень мало признаков того, что дела пойдут наоборот*. Стабильная среда с низким уровнем стресса сделала его идеальным местом для выхода на пенсию, но для молодого разработчика, только начинающего, это было не для меня.
Я уволился с этой работы и присоединился к консалтинговой компании, где мне приходится работать над новыми проектами каждый год или около того, и мы используем новейшие и лучшие технологии, когда можем.
Так что нет, вы не в той профессии, просто в неправильной компании.
* Они привлекли венчурное финансирование, пока я уходил, и новый приток наличных в сочетании с постоянным стенанием большинства разработчиков убедил руководство создавать свои основные продукты с нуля и перевести текущие продукты в режим обслуживания с ограниченным развитием. Я был очень рад услышать это и хотел, чтобы процесс начался, пока я был там, чтобы я мог над ним поработать, но я не хотел бы возвращаться назад.
tl;dr Напротив, вы должны начать спрашивать себя, является ли быть инженером-программистом правильным карьерным путем, когда вы перестанете заботиться о качестве.
Есть хорошие книги о работе с унаследованным программным обеспечением (например, вечнозеленая работа Working Effectively With Legacy Code ); дело в том, что вам не нужно ПРОСИТЬ, чтобы написать хорошее программное обеспечение , как вам не нужно просить протестировать код, который вы пишете. Рефакторинг и улучшение качества существующего кода почти всегда являются частью процесса обслуживания, поскольку написание тестов также является частью предоставления новой функции. Связанные и интересные: Как разработчик; Отсутствие времени на тестирование, крайние сроки и отсутствие слушаний со стороны менеджера .
Вы можете убегать каждый раз, преследуя химеру идеальной компании с идеальной кодовой базой (или всегда новые проекты без какого-либо наследия). В качестве альтернативы вы можете принять этот вызов и добавить свою профессиональную ценность компании, в которой вы работаете.
Работа над старыми проектами также преподаст вам чрезвычайно важные уроки масштабируемости, надежности и ремонтопригодности, которые вы никогда не усвоите, если будете переключаться на новые проекты каждый год или около того.
Что вы можете улучшить, так это ваш подход к проблеме. Прежде всего, вы должны понимать, что технический долг присутствует почти в каждом программном проекте, это фундаментальный момент, и вы не можете его изменить. Как вы уже знаете, технический долг может быть высоким по многим причинам:
После того, как вы приняли это откровение , вы должны понять, как с ним справиться . Иногда возможен вариант полного переписывания, но обычно вам нужно объяснить своим менеджерам, какую ценность принесут компании эти крупные инвестиции. Это широко обсуждалось, и я не буду повторяться здесь, правильная стратегия немного отличается для каждого из вышеупомянутых случаев. Это главное: нетехнический (но и технический, потому что со своей должности она будет смотреть на вещи с другой точки зрения) менеджер не против качества, но ему нужно обосновать вложение , учтите:
Что делать? Начните с общения: сначала объясните ситуацию , но не разглагольствуйте о качестве кода, иначе вас не услышат:
Если они не согласны с таким переписыванием (это вполне может быть), тогда вам придется применять пошаговый подход в рамках ваших повседневных обязанностей.
Что вы можете сделать, так это понять, что это ВАШ ОБЯЗАН писать хороший код со всеми ограничениями, установленными вашим руководством (время, бюджет, ресурсы). Это означает, что вы ДОЛЖНЫ:
Повторите достаточное количество раз, и теперь ваша кодовая база будет достаточно хорошей . Иногда некоторые большие архитектурные изменения могут нуждаться в утверждении, потому что они слишком длинные или сложные, но когда вы находитесь на этом этапе, у вас, вероятно, уже есть прочная основа.
Это невидимый процесс, качество постоянно развивается, но это не обязательно видно снаружи. Я думаю, это то, что Том (начальник первого босса) пытался сказать вам: «Делай свою работу (шаг за шагом!), не беспокоя своего босса, это твоя обязанность, и я верю, что ты знаешь, как это сделать (отправь его ко мне). если, вдруг, он этого не понимает)». Должен ли он был говорить об этом с вашим боссом? Я не могу сказать, но если вы выполняете свою работу неразрушающим образом, то процесс становится незаметным и эффективным.
Иногда они [руководство/босс] виноваты, но часто это проблема коммуникации , вы можете прочитать Представление и искажение фактов: инженеры Тафте и Мортон Тиокол на Челленджере и оригинальный текст Тафте в Визуальных пояснениях: изображения и количества, доказательства и повествование .
Да, во многих крупных компаниях есть группы «неприкасаемых», куда приходят новые люди, и они не хотят, чтобы вы ломали «работающий» продукт. Я видел это в моей последней компании. Небольшая группа людей разрабатывала основное программное обеспечение компании. Все они заняли руководящие должности и пользовались хорошей репутацией у высшего руководства. Они нанимают новых разработчиков, так как оправдывают, что им нужны новые разработчики для продолжения развития продукта. Приходят новые люди, и первоначальная группа просто ожидает, что новые разработчики будут работать над продуктом так, как они хотят.
Это довольно распространено в компаниях, которые вошли в какую-то нишу рынка. В моей последней компании у них никогда не было программного обеспечения или продуктов, связанных с ИТ, и как только они вышли на этот рынок, люди, которые были первоначально наняты, добились успеха, поскольку они стали группой «идут к» после того, как программное обеспечение созрело. Никто из высшего руководства не понимает, как работает ИТ-разработка, и полагается на первоначальную группу разработчиков. Они заботятся только о доходах и о том, будут ли они поступать. Они быстро увольняют любого нового нанятого менеджера, который не соответствует этим ожиданиям.
Вам придется найти компанию, которая либо не занимается только прибылью, либо найти хорошо зарекомендовавшую себя компанию, которая всегда работала в сфере ИТ с ИТ-руководителями и высшим руководством.
Обычно вы можете понять это, не спрашивая напрямую. Просто спросите главного менеджера, как он попал на свою должность в компании. Если он расскажет вам историю, как описано выше, то вы знаете, чего ожидать.
Темная материя
скоро