Comments 60
Взять к примеру, мир фронтенда.
Возьмите любой другой мир :) В остальных отраслях разработки всё намного стабильнее. Да и первичный суп из технологий во фронтэнде — тоже явление сугубо временное, через несколько лет стабилизируется, и начнёт укрупняться, как это ранее произошло в других сферах.
UFO just landed and posted this here
Типичный кассир продолжает работать на том же калькулятора, только в профиль: добавили монитор, слегка расширили клавиатуру.
Типичный бухгалтер знает несколько типичных (для своего софта) горячих клавиш и работает только с ними. И это, скорее, уникальный случай, когда сынок рассказал про Ctrl+C и Ctrl+V (но забыл/не знал про Ctrl+X).
Поэтому нет, революций там не произошло никаких, тем паче не произошло никаких метаморфоз уровня того же JS)
Типичный бухгалтер знает несколько типичных (для своего софта) горячих клавиш и работает только с ними. И это, скорее, уникальный случай, когда сынок рассказал про Ctrl+C и Ctrl+V (но забыл/не знал про Ctrl+X).
Поэтому нет, революций там не произошло никаких, тем паче не произошло никаких метаморфоз уровня того же JS)
Думаю тут стоит еще учесть уровень гибкости мышления. Мне кажется у того же кассира он менее гибкий чем у программиста. Соответственно добавление монитора, клавиатуры, 1С и т.п. вместо привычного калькулятора, наверное можно соотнести с переходом на новый фреймворк на программиста. Вроде бы тот же JS/PHP/Python/Ruby(подставить нужное), но другое :)
Ты просто не в теме.
Я для себя вывел, что надо как бы пропускать некоторые волны. Т.е. не цепляться в любую новомодную, только что всплывшую на поверхность технологию, а, скажем, дать ей время доказать свою жизнеспособность. На это обычно уходит год-два. Вот, в общем, примерно раз в два года и имеет смысл на что-то устоявшееся переходить.
Как вариант — уйти в серьезное эмбеддерство. Там все варятся уже не один десяток лет на C и C++ и не думают с них слезать и хорошего программиста со знанием С(++), да еще и какой-нибудь ОСРВ типа VxWorks, нужно хорошо поискать, а потом еще долго учить.
Еще вариант — бэкэнд на каких-нибудь .net достаточно стабилен, а новые плюшки можно вкручивать не сразу везде, а пробовать интегрировать модульно, предварительно обкатав на pet-проекте, если есть конечно «власть» над архитектурой.
Никогда не понимал этой «боязни всего нового». Ну да, выходят новый фреймворки, языки и т.п, но это не означает, что нужно бежать их изучать.
Поясню. Когда-то давным давно, когда jquery только стал популярным, я менял работу. И с удивлением обнаружил, что все, кроме меня знают jquery. Работу я, правда, нашел и очень быстро, но со знанием jquery я мог бы претендовать на лучшую зп и тд.
Сейчас история такая же: во фронтенде надо знать react или vue или angular. Можно наверно и без этого обойтись, но просто условия будут хуже.
Сейчас история такая же: во фронтенде надо знать react или vue или angular. Можно наверно и без этого обойтись, но просто условия будут хуже.
Ну и если вдруг стабильная компания внезапно умирает, а так тоже бывает, то на рынке труда с java 7 будет сложновато.
Мне кажется, здесь вы преувеличиваете. Java 8 (которая сейчас LTS) не сильно отличается от Java 7. Streams API, Optional, лямбды — осиливаются за вечер-два. И вряд ли для потенциального работодателя отсутствие опыта работы с Java8+ будет принципиальным.
Java фреймворки тоже не то, чтобы должны были сильно поменяться между Java 7 и 8.
В общем, для Java разработчиков даже близко нет такой сильной проблемой с устареванием инструментов, как для JavaScript девелоперов.
Сравните: один программист пишет на jsp и java 7, javascript не знает. Другой умеет делать SPA на реакте через rest api, написанным на Spring, знает java 10.
И вот оба оказались на рынке труда. Кого выберет работодатель? Чья з/п будет больше?
И вот оба оказались на рынке труда. Кого выберет работодатель? Чья з/п будет больше?
Тот кто лучше себя продаст?
Сравнение у вас не совсем корректное. В первом варианте человек не знает javaScript, во втором знает, да еще и реакт. Это опять же фронтенд, к джаве отношения не имеет. Если это отбросить, то остается jsp и java7 против Spring и java 10. Java 10 сейчас мало кто использует (потому что не LTS), т.е. фактически java 10 превращается в java 8. Spring это конечно аргумент, но ему уже очень много лет, т.е. нельзя сказать, что это что-то новое. Дальше я бы на месте работодателя смотрел на все остальное: опыт работы, проекты, работа с БД и т.д.
UFO just landed and posted this here
UFO just landed and posted this here
90% программистов работают с существующим (по логике автора — устаревшим) софтом. Даже если пишут что-то с нуля, то разработка занимает месяцы, плюс потом годы на доработку и поддержку. Поэтому не настолько это уж и острая проблема.
переехать с 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.
Основа этого всего не меняется уже очень много лет — стэк из HTML+CSS+JS был и остаётся тем самым, что нужно всегда, везде, и не очень-то оно меняется. Дополнительные слои, навешиваемые сверху — новые языковые фичи (которые всего лишь «сахар»), типичная экосистема нынешних фронтэнд-проектов, модульность, транспайлеры, фреймворки, итд — это с одной стороны выглядит страшно, а с другой — всего лишь надстройка над базисом. Осваивается это за куда меньшие промежутки времени, чем базовые вещи.
И просто так «чтоб было» за это всё даже и не стоит хвататься — в силу изменчивости мира фронтэнда это всё может спокойно успеть стать неактуальным еще до того, как где-либо вам понадобится. А вещей, за которыми действительно стоит всегда пристально следить — гораздо меньше: браузеры (никогда не стоит упускать из виду, как развивается то, на чем собственно вся ваша работа отображается, даже если разработка нынче идёт по пути browser-agnostic), да стандарты w3c.
Представьте, что вы не знаете, что такое промис, и попали на собеседование. Вас тупо не возьмут на хорошую зп.
Поэтому такие вещи, которые уже в стандарте и в мейнстриме надо знать обязательно.
Поэтому такие вещи, которые уже в стандарте и в мейнстриме надо знать обязательно.
Освоиться с промисами, с теорией и практикой — вопрос даже не одного дня, а нескольких часов. О чем и речь, мелкие надстройки — это не та штука, в которую нужно долго и последовательно вникать.
Освоился с промисами, приходишь на собеседование, а у них async\await.
Освоился с async\await, подзабыл, за отсутствием практики, промисы, приходишь на собеседование, а у них… и так далее.
Освоился с async\await, подзабыл, за отсутствием практики, промисы, приходишь на собеседование, а у них… и так далее.
Ну так такова жизнь. В этом смысле никаких отличий от технологий бекэнда, где всей суммы фич вы скорее всего никогда в жизни не будете использовать, но на собеседовании может всегда попасться тот, кто считает фичу Х прекрасной и будет о ней дотошно спрашивать, а вы про фичу Х смутно читали что-то в книжке 10 лет назад, и всё.
С чего это «год-два» уже стал «летуном»? На Западе это сейчас стандартное время работы на одном месте работы и вопросов вообще не вызывает. У миллениалов с этим и еще хуже, кстати.
Изменение мышления работодателя
Это правда что-то из области фантастики. Да и мало кто будет из опытных предпринимателей менять работающую схему, особенно если компания какой нибудь 20ти летний мамонт. И вдогонку главное правило программиста: работает не трогай (:
то на рынке труда с java 7 будет сложновато.
Да нормально будет. Между java 7 и java 8 не такая большая пропасть. Можно же ведь
мануал полистать
А java 9 и java 10, по моему опыту мало кто использует на проде, все ждут 11. Ну и вообще, backend в целом намного консервативнее в настоящее время.
А не надо постоянно учить текущие тренды. Я когда так для себя учил ангулар он был второй версии. Сейчас уже шестой вроде.
Если нужен ангулар, ставится таска на изучение. Три дня и вы уже пишите нп последнем ангуляре.
В рабочее время?
Ага, еще 3 дни — и вы изучили Symfony, еще 3 дня — ASP.NET MVC. Через 2 месяца вы будете писать на 20 масштабных фреймворках… и не знать ни одного из них. Люди годами изучают одну библиотеку или фрэймворк, чтобы знать все тонкости — а вы: 3 дня…
Ну есть фундаментальные фреймворки которые не так сильно меняются о релиза к релизу. А есть сумасшедшие коттрые каждые пол года ломают обратную совместимость. Такие я ппедлагаю учить по ходу разработки.
Вот, собственно, и обе стороны знания — либо нахватался кучу всего по верхам за пару недель, либо корпишь над каждой страницей «Effective %TECH_NAME%» по нескольку дней, перепроверяя все написаное и ходя по всем референсным документам.
В итоге работу получает тот, кому просто повезло, или у кого язык подвешен.
В итоге работу получает тот, кому просто повезло, или у кого язык подвешен.
По не маленькому опыту работы могу сказать что для изучения чего-то нового хорошо работать в маленьких веб-студиях)). Там хоть каждый день делай новые эксперименты и используй новые фичи. А вот чем крупнее студия тем более трепетно подходят к выбору стека технологий. А если уж работать не в веб-студии а штатным программист то и речи о развитии и не может идти одна рутина. Это скорей все зависит от интересов каждого и места на которые хотите попасть.
Проблема ( как минимум с вебом ) это то что он еще не готов к такому бурному росту/изменению. Берешь какой-нибудь проект, который начинался в 2010, когда еще не было всяких es6, когда стандарты не выпускались каждый год и там дремучий древний лес. Как-то обновлять это — легче переписать с самого начала. Возможно, со временем, если скорость изменений языка/стандартов будет сохранятся, будут придуманы инструменты, для более безболезненного перехода на новые фичи языка.
Ну и да, какие-то монструозные проекты по определению столкнутся с тем, что в какой-то момент масштабировать их будет невозможно, просто из-за количества кода. И тут тоже нужно думать и искать новые подходы/архитектуру. Модульность — как хорошее начало, когда ты можешь взять и переписать один конкретный модуль и в идеале остальной проект даже не заметит это.
Как-то обновлять это — легче переписать с самого начала.
Я по долгу службы работаю с проектом, который начинался в 2002 году.
Нормально там всё обновляется. Можно даже (если б это было реально надо) поэтапно перетащить в современную среду и разбить на модули, несмотря на то, что проект сильно большой.
Ещё направление «миграции» — в сторону предметной области. Обычно предметные области изменяются гораздо медленнее, чем версии фреймворков. Хорошего специалиста по какому-нибудь налоговому учёту с опытом разработки софта для этого, компания, разрабатывающая такой софт, вероятно, «с руками оторвёт», даже если он не знает чем восьмая жава от седьмой отличается.
Тут конечно 1) не всем программистам интересен налоговый учёт; и 2) в этом случае вы ограничите себе выбор работодателя только теми фирмами, которые занимаются налоговым учётом. Но можно утешать себя тем, что специалисту с дипломом что-нибудь вроде «кадровый учёт в бюджетных учереждениях», скорее всего, вообще никогда не придёт в голову собеседоваться на должность «специалист по складскому учёту в международной корпорации» (утрирую).
Т.е. профессия «писатель кода» хороша тем, что код нужен во всех отраслях народного хозяйства. Но плата за это — большое разнообразие используемых технологий (и в некоторых отраслях — очень быстрая их смена).
Тут конечно 1) не всем программистам интересен налоговый учёт; и 2) в этом случае вы ограничите себе выбор работодателя только теми фирмами, которые занимаются налоговым учётом. Но можно утешать себя тем, что специалисту с дипломом что-нибудь вроде «кадровый учёт в бюджетных учереждениях», скорее всего, вообще никогда не придёт в голову собеседоваться на должность «специалист по складскому учёту в международной корпорации» (утрирую).
Т.е. профессия «писатель кода» хороша тем, что код нужен во всех отраслях народного хозяйства. Но плата за это — большое разнообразие используемых технологий (и в некоторых отраслях — очень быстрая их смена).
Если же еду на машине, то стараюсь слушать тематические подкасты для расширения кругозора.лучше уж за дорогой следить. За статью спасибо.
Начинал программистом на .NET в дремучем 2005.
В течение года в добровольно-принудительном порядке стал руководителем отдела тестирования.
Но в кодовую базу свой вклад вносил.
Года через 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 только для винды и тяжёлый — да, но архитектура некоторых решений достойна того, чтобы знать, что так бывает. И так далее.
— Умение выхватывать суть технологии/фреймворка/языка. То есть, попробовать понять, почему он именно такой, каким его сделали? Какие ранее существующие проблемы он решает.
— Общаться с единомышленниками. Обсуждать технологии, спорить, бить морды, но общаться.
В течение года в добровольно-принудительном порядке стал руководителем отдела тестирования.
Но в кодовую базу свой вклад вносил.
Года через 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 только для винды и тяжёлый — да, но архитектура некоторых решений достойна того, чтобы знать, что так бывает. И так далее.
— Умение выхватывать суть технологии/фреймворка/языка. То есть, попробовать понять, почему он именно такой, каким его сделали? Какие ранее существующие проблемы он решает.
— Общаться с единомышленниками. Обсуждать технологии, спорить, бить морды, но общаться.
Sign up to leave a comment.
Как выживать в изменяющемся мире разработки