Комментарии 60
Взять к примеру, мир фронтенда.
Возьмите любой другой мир :) В остальных отраслях разработки всё намного стабильнее. Да и первичный суп из технологий во фронтэнде — тоже явление сугубо временное, через несколько лет стабилизируется, и начнёт укрупняться, как это ранее произошло в других сферах.
Типичный бухгалтер знает несколько типичных (для своего софта) горячих клавиш и работает только с ними. И это, скорее, уникальный случай, когда сынок рассказал про Ctrl+C и Ctrl+V (но забыл/не знал про Ctrl+X).
Поэтому нет, революций там не произошло никаких, тем паче не произошло никаких метаморфоз уровня того же JS)
Как вариант — уйти в серьезное эмбеддерство. Там все варятся уже не один десяток лет на C и C++ и не думают с них слезать и хорошего программиста со знанием С(++), да еще и какой-нибудь ОСРВ типа VxWorks, нужно хорошо поискать, а потом еще долго учить.
Я думаю это суть про пункт "ядро Линукса". Потому что от эмбеддера обычно требуют умение обращаться с паяльником, осциллоскопом и базовое понимание электроники (рассчет резисторных делителей, фильтров и так далее).
А программировать мб нужно даже не каждый день)
Сейчас история такая же: во фронтенде надо знать react или vue или angular. Можно наверно и без этого обойтись, но просто условия будут хуже.
Ну и если вдруг стабильная компания внезапно умирает, а так тоже бывает, то на рынке труда с java 7 будет сложновато.
Мне кажется, здесь вы преувеличиваете. Java 8 (которая сейчас LTS) не сильно отличается от Java 7. Streams API, Optional, лямбды — осиливаются за вечер-два. И вряд ли для потенциального работодателя отсутствие опыта работы с Java8+ будет принципиальным.
Java фреймворки тоже не то, чтобы должны были сильно поменяться между Java 7 и 8.
В общем, для Java разработчиков даже близко нет такой сильной проблемой с устареванием инструментов, как для JavaScript девелоперов.
И вот оба оказались на рынке труда. Кого выберет работодатель? Чья з/п будет больше?
переехать с Grunt+RequireJS на Webpack+ES Imports — дело одного дня
Посмешил. Простой апгрейд Webpack'a с одной версии на другую, не бывает без кучи ошибок и танцов сам знаешь с чем. А тут полная замена build системы за один день… Ну только если проект 'Hello world' какой-нибудь.
Это зависит от проекта.
Если в нем используются только стандартные CommonJS/AMD модули и минимум плагинов, то переезжается легко.
А если есть особые плагины, несовместимые с новыми версиями, то это боль. А еще хороший способ подумать, а точно ли нужно было ставить super-duper-loader, если потом из-за него сложно обновляться.
Со знанием JavaScript пятилетней давности сейчас хорошую работу не найдешь.
Зато вот «фронтэндщики» в кавычках, JS не знающие — мне уже попадались, а дальше их только больше будет. Когда в эти ваши фреймворки с TS и прочей пакетной экосистемой он может, а вот когда её нет, а есть только обычный кондовый JS лохматого года написания — и всё, ступор, растерянность, и непонимание, как это вообще так может быть.
Так тоже не надо, на самом деле.
Основа этого всего не меняется уже очень много лет — стэк из HTML+CSS+JS был и остаётся тем самым, что нужно всегда, везде, и не очень-то оно меняется. Дополнительные слои, навешиваемые сверху — новые языковые фичи (которые всего лишь «сахар»), типичная экосистема нынешних фронтэнд-проектов, модульность, транспайлеры, фреймворки, итд — это с одной стороны выглядит страшно, а с другой — всего лишь надстройка над базисом. Осваивается это за куда меньшие промежутки времени, чем базовые вещи.
И просто так «чтоб было» за это всё даже и не стоит хвататься — в силу изменчивости мира фронтэнда это всё может спокойно успеть стать неактуальным еще до того, как где-либо вам понадобится. А вещей, за которыми действительно стоит всегда пристально следить — гораздо меньше: браузеры (никогда не стоит упускать из виду, как развивается то, на чем собственно вся ваша работа отображается, даже если разработка нынче идёт по пути browser-agnostic), да стандарты w3c.
Поэтому такие вещи, которые уже в стандарте и в мейнстриме надо знать обязательно.
Освоился с async\await, подзабыл, за отсутствием практики, промисы, приходишь на собеседование, а у них… и так далее.
Изменение мышления работодателя
Это правда что-то из области фантастики. Да и мало кто будет из опытных предпринимателей менять работающую схему, особенно если компания какой нибудь 20ти летний мамонт. И вдогонку главное правило программиста: работает не трогай (:
то на рынке труда с java 7 будет сложновато.
Да нормально будет. Между java 7 и java 8 не такая большая пропасть. Можно же ведь
мануал полистать
А java 9 и java 10, по моему опыту мало кто использует на проде, все ждут 11. Ну и вообще, backend в целом намного консервативнее в настоящее время.
А не надо постоянно учить текущие тренды. Я когда так для себя учил ангулар он был второй версии. Сейчас уже шестой вроде.
Если нужен ангулар, ставится таска на изучение. Три дня и вы уже пишите нп последнем ангуляре.
Ну есть фундаментальные фреймворки которые не так сильно меняются о релиза к релизу. А есть сумасшедшие коттрые каждые пол года ломают обратную совместимость. Такие я ппедлагаю учить по ходу разработки.
В итоге работу получает тот, кому просто повезло, или у кого язык подвешен.
Проблема ( как минимум с вебом ) это то что он еще не готов к такому бурному росту/изменению. Берешь какой-нибудь проект, который начинался в 2010, когда еще не было всяких es6
, когда стандарты не выпускались каждый год и там дремучий древний лес. Как-то обновлять это — легче переписать с самого начала. Возможно, со временем, если скорость изменений языка/стандартов будет сохранятся, будут придуманы инструменты, для более безболезненного перехода на новые фичи языка.
Ну и да, какие-то монструозные проекты по определению столкнутся с тем, что в какой-то момент масштабировать их будет невозможно, просто из-за количества кода. И тут тоже нужно думать и искать новые подходы/архитектуру. Модульность — как хорошее начало, когда ты можешь взять и переписать один конкретный модуль и в идеале остальной проект даже не заметит это.
Как-то обновлять это — легче переписать с самого начала.
Я по долгу службы работаю с проектом, который начинался в 2002 году.
Нормально там всё обновляется. Можно даже (если б это было реально надо) поэтапно перетащить в современную среду и разбить на модули, несмотря на то, что проект сильно большой.
Тут конечно 1) не всем программистам интересен налоговый учёт; и 2) в этом случае вы ограничите себе выбор работодателя только теми фирмами, которые занимаются налоговым учётом. Но можно утешать себя тем, что специалисту с дипломом что-нибудь вроде «кадровый учёт в бюджетных учереждениях», скорее всего, вообще никогда не придёт в голову собеседоваться на должность «специалист по складскому учёту в международной корпорации» (утрирую).
Т.е. профессия «писатель кода» хороша тем, что код нужен во всех отраслях народного хозяйства. Но плата за это — большое разнообразие используемых технологий (и в некоторых отраслях — очень быстрая их смена).
Если же еду на машине, то стараюсь слушать тематические подкасты для расширения кругозора.лучше уж за дорогой следить. За статью спасибо.
В течение года в добровольно-принудительном порядке стал руководителем отдела тестирования.
Но в кодовую базу свой вклад вносил.
Года через 1.5 в том же порядке возглавил проект. Продолжая отвечать за QA и всё ещё пописывая, но больше для БД.
Потом компания закончилась и устроился в новую, продавая себя в двух ипостасях — могу в код, могу в управление. Пол года пописал активно на шарпе и опять перешёл руководить проектами, периодически пописывая что-то.
В итоге семь лет отпахал в двойном (на самом деле больше) режиме — разработчик и PM.
Что всегда спасало — это наличие сильных программистов в командах и возможность влиять на стек технологий. Основные проблемы разгребали ребята, сам больше подтягивался за ними. Ну и с БД нормально помогал, потому что получалось (образ мышления видать хорошо ложился на концепцию).
В 2015 закончилась вторая моя компания. Решил, что нужно обновить (на самом деле, написать с нуля) резюме. Не вышло. Из-за постоянных контактов в .NET, и не только, комьюнити, вышел на тропу фриланса.
То один знакомый позовёт, то другой предложит заказчику. И тут хорошо сыграло то, что сам до этого пас котов, то есть, знал что требуется от программистов и как эти знания продавать за нормальные деньги.
В итоге за последние три года:
— Разобрался с WPF (раньше как-то всё веб решения были).
— Поработал с OpenCart, WordPress и PHP в целом — какая нафиг разница на чём писать.
— Поработал на 1С — агрррр, вот тут есть разница на чём писать, хреновая экосистема.
— Освоил* немного PhaserJS для написания игр в вебе.
— Освоил Windows IoT и разработку на .NET под Raspberry PI.
— Освоил Ангуляр (текущий проект на 6й версии) со странным, но в итоге интересным RXJS.
— Ну и .NET Core в полной мере, как бекенд.
*Освоил — означает, что реализовывал коммерческие проекты на этих технологиях.
Впереди своей очереди ждёт Xamarin.
Ну а теперь о том, как выживать? Сейчас будет поток банальщины:
— Быть любопытным. Читать Release Notes и прикидывать, что дают новые версии используемых платформ. В моём случае всегда читаю обновления Ангуляр, C#, .NET Core, T-SQL.
— Подчистую убрать предвзятость. В 1С пишут на русском языке — говно? Та нет, проблемы там не из-за этого, а саму платформу стоит изучить. WPF только для винды и тяжёлый — да, но архитектура некоторых решений достойна того, чтобы знать, что так бывает. И так далее.
— Умение выхватывать суть технологии/фреймворка/языка. То есть, попробовать понять, почему он именно такой, каким его сделали? Какие ранее существующие проблемы он решает.
— Общаться с единомышленниками. Обсуждать технологии, спорить, бить морды, но общаться.
Как выживать в изменяющемся мире разработки