Давайте сразу проясним один момент: я не старый. В свои тридцать восемь я ощущаю себя таким же молодым и полным сил, как и прежде – и в физическом плане, и в интеллектуальном, и в любом другом. Пусть мои дети и заявляют, что я уже дряхлый старик, по двадцать раз на дню, в своих собственных глазах я всё тот же двадцатитрехлетний разработчик, каким был когда-то. Я по-прежнему с огромным интересом слежу за появлением новых технологий и развитием веба в целом, но в своей индустрии уже считаюсь специалистом не первой молодости.
Мне повезло: у меня хорошая должность сениора в компании, которая меня ценит, и местную кодовую базу я знаю вдоль и поперёк. Для меня не составляет труда внедрять новую функциональность, диагностировать проблемы и оперативно реагировать на новые требования. Но при этом и сама кодовая база – порождение ушедшей эпохи PHP/MySQL/JavaScript.
С точки зрения моей компании в этом нет ничего страшного. По правде сказать, для наших задач и не нужен ультрасовременный фронтенд, подвязанный к документоориентированной базе данных NoSQL. PHP/MySQL отлично справляются со всеми операциями, которые мы производим изо дня в день, и при этом без проблем уживаются со всеми старыми приложениями, которые появились на свет ещё до моего прихода в компанию. Я всегда отдавал предпочтение не тому, что в тренде, а тому, что работает, и здесь на меня не давят, чтобы я что-то модернизировал просто ради модернизации.
Я работаю на предприятии из сферы промышленного производства. Наша деятельность считается жизненно необходимой, поэтому, к счастью для меня, эпидемия COVID-19 не разорила компанию и моей работе ничего не угрожает. Но никто не застрахован. У меня четверо детей и ипотека, и мне вдруг пришло в голову, что нужно хотя бы просматривать вакансии, чтобы представлять себе ситуацию на рынке, на случай если что-то изменится. Честно говоря, от открывшейся перспективы мне стало не по себе. Вот несколько выводов о положении «старого программиста», которые я для себя сделал.
Нужно тратить больше времени на обновление навыков
Я никоим образом не пренебрегал ознакомлением с новыми технологиями. Я игрался с многими фреймворками последних лет, и некоторые из них мне честно очень нравятся. В особенности я оценил Vue и React – отличные веб-решения, которые полностью заслуживают своей популярности. Но в моём случае проблема заключается в том, что для работы они мне не нужны. А свободного времени у меня не так много, как было в молодости – уже не посидишь ночами над личными проектами, чтобы освоить новый инструмент.
Многие разработчики, которые отпраздновали тридцатилетие и обзавелись семьёй, меня здесь поймут. Но нужно смотреть правде в глаза: мы остаёмся в стороне от новых технологий на собственный страх и риск. Нужно бросать как можно больше сил на то, чтобы идти в ногу со временем. Ведь если случится худшее и вы останетесь без работы, рынок будет, прежде всего, ждать от вас умения работать именно со свежими технологиями.
Зону компетентности тоже пора расширять
Времена, когда функции программиста сводились к тому, чтобы писать код, стремительно отходят в прошлое – а может, и уже отошли. Деплой, работа со средой сборки, контроль версий – всё это (и многое другое) чаще и чаще мелькает в списках обязанностей разработчика.
При этом поверхностного знакомства с соответствующими инструментами может оказаться недостаточно. Лично я много читал про Docker, AWS, Azure, Netlify и так далее, но практический опыт работы с ними у меня весьма и весьма ограничен – просто не возникает особой необходимости. Но если меня снова выбросит на рынок труда, не сомневаюсь, что наслушаюсь от молодых да ранних двадцатилетних категоричных заявлений о том, что Docker – венец веб-технологий и без него не видать мне никакой работы как своих ушей.
Развивайте в себе и те умения, которые не связаны напрямую с написанием кода. Чем более разносторонним специалистом вы становитесь, тем выше будут вас ценить работодатели в будущем и тем меньше вероятность, что вы покажетесь им каким-то динозавром.
Не отчаивайтесь: всегда остаётся legacy-код
В другой жизни я был одним из маленькой, но гордой горстки разработчиков на ColdFusion. Прямо скажем, ColdFusion был скорее мёртв, чем жив даже в те времена, когда я только-только начинал на нём писать. Тем не менее, он лежал в основе многих технологий, с которыми я тогда работал. Так что пришлось его постигать стремительными темпами.
В то время я подписался на целую кучу групп, рассылок и форумов, связанных с этой темой, и через них мне до сих пор приходят письма от людей, которые ищут разработчиков на ColdFusion – многие компании наследуют кодовые базы, написанные именно на этом языке. Рано или поздно наступит момент, когда они перепишут весь код на что-то более современное. Но для крупных предприятий это задача громадных масштабов, и они будут тянуть время по максимуму. Таким образом, талантливый разработчик на ColdFusion по-прежнему может весьма неплохо зарабатывать как приглашённый специалист. В мире нативной разработки подобные же вещи я слышал о COBOL и даже PASCAL.
Не стоит забывать и о том, что PHP укоренился в коде в значительно большей степени, чем ColdFusion. В общем, я веду к тому, что в мире, вероятно, всегда будет сколько-то кодовых баз с legacy-кодом, которые кто-то должен поддерживать, а то и расширять. Такие возможности сложнее будет найти, но это не значит, что их не существует.
В заключение
Превращение в старейшину программирования (мне такой титул нравится больше, чем «старый программист») иногда немного пугает. Но, по правде сказать, мудрость в какой-то мере действительно приходит с возрастом. Программисты не первой молодости, возможно, не всегда «на ты» с новейшими технологиями, но зато имеют богатый опыт решения практических задач, который идёт на вес золота.
Всегда старайтесь шагать в ногу со временем, но не допускайте, чтобы страх перед будущим вводил вас в ступор. Нет никакой необходимости пытаться выучить всё на свете к завтрашнему утру, а то, что вы уже умеете, по-прежнему имеет свою ценность. Найдите баланс, который подходит лично вам, и гордитесь тем, что провели столько времени в IT-индустрии и повидали рассветы и закаты такого количества технологий.
oleggromov
Кажется, случись вам менять работу, будет очень сложно. Дело не столько к докере или NoSQL, сколько в том, что современные компании ценят умение тащить в постоянно изменяющейся среде и софт-скиллы, которые приходят, по моему опыту, от взятия на себя ответственности и работы с разными людьми в разных проектах. Вы об этом упоминаете совсем мало.
Поиск работы и прохождение собеседований — это тоже совершенно отличный от обычной работы навык. Советую начать тренироваться и собеседоваться, если вы всерьёз настроены когда-то поменять работу.
В любом случае удачи!
oleggromov
Очень забавно: опубликовал комент и понял, что обратился фактически к переводчику
bak
Качественный перевод — сегодня редкость на хабре ) Тоже думал что автор от себя пишет.
t13s
Возможно, я в чем-то не прав, но «постоянно изменяющаяся среда» — немного переоцененное понятие. Фундаментальным основам, на которых строится современная CS, где-то полвека (к счастью или к сожалению). Поэтому, если есть понимание этих основ, то никакие NoSQL с докерами пугать не должны. По крайней мере вас — как соискателя на проект, в котором количество кода, в котором предостоит разбираться, априори на порядки больше API (контрактов, [недокументированных] особенностей, и т.д.) сторонних сервисов. А если это пугает потенциального работодателя, то, возможно, вам просто с ним не по пути.
Что касается софт-скиллов, то <тут нецензурно>. В общем, эмулировать их на собеседовании не очень сложно. А дальше, если умеете работать, они не очень нужны.
vics001
Почему это софт-скиллы нецензурно? Похожий каждый хороший программист мнит, что он в одиночку может построить Эйфелову башню, только на это у него уйдет 40 лет, а ждать некогда. И вдруг неожиданно оказывается, что надо делить работу, работать в команде, оценивать сильные и слабые стороны своих напарников и почему-то «софт-скиллы» — нецензурное слово.
Объясните, пожалуйста.
t13s
Видимо, у нас с вами разное понимание вот этого вот термина.
Я глубоко убежден, что по сугубо рабочим моментам, как то: высказать свою гипотезу, задать технический вопрос или ответить на него — может коммуницировать любой человек, не отягощённый грузом серьезных психических заболеваний.
Поэтому поделить работу не проблема, алгоритмов много: «я такое уже пилил, так что давайте», «кто первый встал, того и тапки», «мне всё равно делать нефиг / я перегружен». В случае дедлока (в реальности — редкого) проблема эскалируется на уровень выше в виде тим-лида. Который, кстати, и принимает решение, опираясь на сильные и слабые стороны работников и прочие методы научного тыка. То есть какого-то экстраординарного опыта общения от технических сотрудников это не требует.
Теперь о работе в команде. Тоже очень спорный термин. Кто-то видит в этом механизм манипуляции вида
«часть корабля, часть команды»«мы команда, мы пашем до победного без перерыва на обед и выходных, кто против — враг», «в слове команда нет буквы Я, поэтому все молодцы, а премия, чтобы никого не обидеть — менеджеру».Но, как мне кажется, успешной команда становится тогда, когда в ней четко кристаллизуются роли, что помогает обрабатывать поступающие задачи на конвейере. Так что это, скорее, заслуга полученного опыта, а не каких-то абстрактных софт-скиллов.
Это был ответ к первой части вашего сообщения. Теперь о «нецензурщине».
Тут всё просто: шильдик «да он троглодит какой-то без софт-скиллов» вешают всякие феечки, которые рациональные аргументы не понимают, поэтому они взамен ищут повод оскорбиться на наименования переменных. Поэтому вместо конструктивного диалога вида: «код — г@вно, причины: вот, вот и вот, поправь плиз», — приходится пороть чушь вида «привет-какдила? ты проделал замечательную работу, просто прекрасную! а как ты думаешь, нельзя ли сделать её еще лучше, например тут? И там, смотри, какое у тебя вот здеееееесь интересненькое решеньице».
А это выливается не только в исключительное словоблудие и потерю времени, но и в то, что исчезает любая действенная обратная связь: действительно ли всё у меня хорошо, или надо копаться глубже в этом словесном поносе, додумывать и искать скрытый смысл?
Поэтому, резюмируя: общаться конструктивно по делу ни для кого не проблема, не надо для этого выдумывать отдельные «скиллы». Advanced-уровень словоблудия, называемый «софт-скиллами», мешает по-настоящему эффективной технической коммуникации.
nikolayv81
"общаться конструктивно по делу ни для кого не проблема"
Вам наверное повезло но бывают и другие контрагенты(а они могут точно также думать о другой стороне).
t13s
А не расскажете пару историй про таких вот… контрагентов? :)