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

Если вам нужно уйти, уходите.

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

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

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

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

Я был там. Это более распространено, чем вы думаете.

Приоритетом бизнеса номер один является получение прибыли его владельцами (акционерами и т. д.). Если современные технологии удовлетворяют потребности бизнеса , то зачем им вкладывать средства во что-то модное и новое?

Что касается меня, я начал заниматься ИТ как программист на COBOL (тьфу) в 94-м. Фирма, в которой я работал, была очень успешной брокерской фирмой. Код был написан на языке COBOL68, а некоторым исходникам уже около 25 лет. Это было старо, но работало. Нас попросили обновить версию COBOL вместе с изменениями, необходимыми для Y2K.

Переход на более современную среду произошел из-за давления со стороны бизнеса, а не потому, что я (как разработчик, знающий C, C++ и т. д.) хотел использовать новейшие инструменты.

Так что же делать тем временем? Для меня мой первый проект VB6 заключался в замене перфоратора настольным приложением, которое могло создавать изображения карт (текст ASCII), совместимые с Y2K. Я могу пошутить, что создал перфоратор, совместимый с Y2K (в 1999 году!).

Что еще важнее, я смог использовать что-то «новое» (это было до .NET и более современных вещей), чтобы помочь решить бизнес-задачу. Лучше всего определить, как вы можете помочь бизнесу достичь своих целей, используя новейшие технологии. Говорите деловыми терминами.

В моей предыдущей компании определенно не все было замечательно (хей, поэтому я и уехал!), но мы использовали передовые технологии и инструменты, и мне этого не хватает. Я не ожидаю, что буду постоянно использовать передовые технологии. Но те, что здесь, действительно устарели.

Мне кажется, ты скучаешь по своей предыдущей работе. Вы уверены, что на самом деле это не сожаление о том, что вы уволились и упустили то, над чем работали?

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

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

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

Вы бы не акцентировали внимание на технических, а на мягких навыках. Как вы были постоянным защитником. Может быть, проводить семинары или презентации новых инструментов для персонала (или руководства). С анализом рентабельности.

И если у компании есть бюджет, тренируйтесь. Или если дадут время на следственную работу, расследовать.

Мягкие навыки. Процедуры. Протоколы. Если руководство в вашем углу. Это то, что вы хотели бы подчеркнуть потенциальным новым работодателям/клиентам.

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

Это зависит от того, хотя, и это чисто предположение с моей стороны. Почему бы вам не сообщить об этом своему руководителю и не попытаться разработать план (если его еще нет — спросите об этом!)?

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

Работая как над инженерной, так и над инженерной частью, ваш аргумент, что все «устарело», не является сильным. Звучит как разглагольствование и не подкреплено цифрами. Есть ли хорошее экономическое обоснование для разделения базы кода на несколько репозиториев? Или это просто требует дополнительного обслуживания из-за отсутствия непрерывной интеграции/непрерывного развертывания (CI/CD)? Насколько быстрее вы могли бы выполнить развертывание для клиентов, если бы у вас была CI/CD? Как можно свести к минимуму ошибки в процессе сборки и развертывания?

Например, если у вас нет CI/CD или он плохой, проведите проверку концепции и измерьте потенциальные выгоды. Представьте это своему менеджеру или тому, кто решит, над чем вы должны работать, и сделайте это своим проектом. Вы даже можете посетить конференции по DevOps/SRE и поучиться у других.