Вы решили стать разработчиком. Почему нужно учить javascript, а не java?

Привет, уважаемая редакциия! Здравствуйте, коллеги.

Через пару-тройку месяцев мне, как разрабочику frontend, исполнится четыре года. А до пятидесяти в паспорте останется немногим меньше двух лет. За эти четыре года жизнь менялась стремительно, и теперь, спустя время, можно проанализировать, какие решения оказались удачными, а какие не очень.

Начнем с выбора тех. стека, и, как следствие — специализации. Думаю, мой выбор (frontend, javascript) оказался удачным, и я хочу теперь проанализировать, почему.

Мой бэкграунд. Я закончил Донецкий политех по специальности Мишустина (системотехник), в 1994г. Проработав пару лет эникейщиком на различных позициях еще в Донецке, я присоединился к маленькому семейному бизнесу (полиграфия), в котором оставался следующие 15-20 лет. 15 лет работы в своей фирме, и еще 5 лет попыток извлечь пользу из «отраслевого» опыта, работая по найму. Эти последние пять лет не были отмечены ни значительными успехами, ни вдохновляющими переспективами. В поисках альтернативы я стал пробовать делать некоторые вещи в вебе. Это были несложные сайты для знакомых, или для собственных нужд.

После некоторых опытов пришло понимание, что чтобы научиться делать что-то хорошо, надо выбрать специализацию. Я выбрал frontend, учил его около года, затем получил первую работу на фултайме, и за три-четыре года прошел путь от джуна до синьора. Теперь, чтобы сделать следующий шаг, я изучаю Java

Сегодня я думаю, что эта последовательность — сначала js, потом java — оказалась правильной. По следующим причинам.

Когда мы решаем, с чего начать, почему Java вторая опция рядом с Fronted, а не Python, C#, Golang? Потому что Java — это энтерпрайзный код. Это большой, благополучный закачик. Это медстраховка. Это коллеги в большом количестве, у которых можно учится. И таких вакансий много. И их будет много через 10 лет.

Python нам не нужен — в вебе это прототипы, равно статапы, и скрипты. Скрипты это девопс, а мы лиюди семейные, нам нужны хорошие зарплаты, а не ночи на работе. Так же Python хороший иструмент для аналитика, но это другая карьера. Долгая, не гарантированная, здесь нужно почти сразу попасть в правильное место.

C# — отличный язык, возможно лучший. Но он не победил Java, и уже не сможет. И помните, какой язык лучше, решают не разрабочики, а бизнес, когда выбирает технологический стек. Разрабочик иногда может на этот выбор повлиять, но в целом для него этот выбор — данность.

Golang — судя по всему будет расти. Выучите его после Java, чтобы в большой стабильной конторе переписывать старый код с Java на Go. Как это происходит сейчас, например, в Яндексе.

И в итоге, почему все-таки Frontend а не Java?

Во фронтед более низкий порог входа. В javascript есть четыре «больших» темы для изучения: замыкания, this, асинхронность, наследование. Есть конечно еще верстка, про которую отдельно далее. А пока про эти четыре темы.

Замыкания — это паттерны Модуль, Декоратор, и то, как работает js на коллбэках. Это действительно нужно знать. Это прийдется разобрать, выучить, иначе будет больно. Но это более чем реально, и в сравнении с тем, через какие «но» работает замыкание, например, в Java, это ничто.

Работа this в js сильно отличается от this в других языках. Здесь нужно будет разобрать нескольк вариантов его использования — в конструкторе, в инстансе, в методе, в стрелочной функции, и да, js-ный this многолик, ничего не поделаешь… Т.е., я хотел сказать, слава богу. Но для начала вам будет достаточно и пары случаев из этих десяти, чтобы начать работать, получая сначала неплохие деньги, а затем очень неплохие.

Асинхронность. Промисы, setTimeout. Тоже тема не очевидная для новичка, зато последняя из важных. Если потянули замыкания и this, асинхронность тоже освоите, ну, плюс месяц.

Все. Вы спросите, а как же наследование? Как концепт, прототипное наследование очень простое. У него много нюансов реализации, и много самих реализаций в JS. Было. До прихода стандарта ES6. Отныне вопросы про наследование — это скорее способ показать новичку, что он еще не все знает, чем must have для начала реальной работы.

А теперь вопрос. Эти три «большие» темы можно сопоставить с однимими джавовскими дженериками? Да легко. А давайте вспомним, как в java реализовано функциональное программирование. Вот эти все ссылки через два двоеточия… Это более чем сопоставимо с неуловимым this в js…

В общем, как язык, js гораздо дружественнее к новичку.

Да-да-да, конечно, есть css. Каскадные таблицы стилей. Восемь способов оцентрировать div по вертикали, и ни одного человеческого. Инкапсуляцию придумали трусы. Заставьте это работать во всех браузерах. А у вашего начальника вообще blackberry, и там тоже долно быть красиво. Но.

Flex-box осваивается быстро, и вы уже можете что-то показать. Остальное можно учить уже на работе, а кросс-браузерную верстку сбрасывать верстальщикам, которых заметно больше, чем хорошей работы для них.

Это стартовая картина. Как итог, если сравнивать старт на js со стартом на java, вы учитесь меньше на три-шесть месяцев, и получаете работу — первую, тысяч на 80 — в Москве. И когда сосед-джавист получает свою первую работу за 100 тыс, вы уже готовы получить вторую, на 120. Вы делаете джависта на старте. И эти первые месяцы выхода из пике — они очень, очень важны, если вы их уже очень сильно ждете.

Продолжим соревнование с воображаемым джавистом. Проходит еще пару лет. Если вы вкладываетесь, и джавист вкладывается, вы становитесь уверенными мидлами. Джавист подходит к диапазону 150 — 180 тыс. Фронтендер где-то к 140 -160. Если он не предпринимает каких-то экстраусилий (я предпринимал, поэтому не привожу себя в пример). И очень интересно, что происходит дальше.

Переход в категорию старшего разработчкика. Тут выясняется, что фронтендеру легче дрейфовать в сторону фулстэка. Потому что js мультипарадигменный язык. Да, ООП на нем скорее игрушечное, но оно есть. А функциональщины полно, и она в моде. React, rxjs. Фроненд незаметно приучает учиться быстро. И тут вы обгоняете джависта и уноситесь в необъятный карьерный космос…

Поэтому — фронтенд!

P.S. Помогаю желающим освоить frontend бесплатно. Пишите в личку или в комменты.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Что лучше для захода в разработку?

  • 27,6%Согласен, frontend43
  • 43,6%Java. Не поддавайтесь на провокации!68
  • 18,0%Конечно ассемблер28
  • 10,9%Спросите года через два, я пока алгоритмы учу17
Luxoft
think. create. accelerate.

Комментарии 41

    +6
    Уровень зарплаты далеко не всегда зависит от выбранного технологического стека, очень странно видеть от 48-летнего человека настолько поверхностные взгляды, уж извините.

    Надеюсь, в работе Вас мотивирует не только цифра в зарплатной ведомости, иначе мне становится грустно за отрасль.
      +1
      Подскажите, чем себя мотивировать если не зарплатой, когда каждый день имеешь дело со скучными вещами вроде легаси?
        0
        Офферами в компании с интереными проектами же.
          +1

          просто финансовая мотивация самая не надежная: сколько бы вам ни платили, всегда будет казаться меньше, чем "вон у того парня".
          Один только я из всех читающих могу привести минимум два примера когда люди оставляли ненавистную работу, трижды она высокооплачиваемая.


          Разработка имеет очень много схожего с творчеством и если кроме денежной мотивации иной нет, то очень скоро и эта мотивация пропадёт: то ли сами бросите, то ли урежут ЗП "за недостатком мотивации".

        +1
        Это большой, благополучный закачик. Это медстраховка

        я, конечно, не имею ничего против желания хорошо зарабатывать, особенно в текущей ситуации, но выбор профессии за то, что в ней есть большие деньги, мне уже набил оскомину. У пластических хирургов и полярников, кажется, тоже все эти преимущества есть? Почему туда никто не идет?
          +2
          Потому что стать пластическим хирургом чуть сложнее, чем погромистом)
            +2
            В frontend попасть проще
              +1
              У пластических хирургов и полярников, кажется, тоже все эти преимущества есть? Почему туда никто не идет?

              Высокий порог входа в первом случае и высокая сложность (некомфортность) работы — во втором (вахта, холод, высокий риск подорвать здоровье, а главное — отсутствие будущего в профессии, рано или поздно окажешься на берегу и старым).
              В ИТ есть все — и порог входа не очень высок (но достаточно, чтобы вошел всего лишь каждый 10-й), и сложность работы в среднем невысока, и темп, и комфорт присутствует. В общем, сказка, а не профессия.
              +4
              Это ужасно…
              Все что я прочитал сейчас, это просто ужасно, начиная от мотивации и заканчивая аргументацией. Про «Python нам не нужен » хорошо говорит статья яндекса тут не далеко. Да и вообще, черт побери, от джуна до синьера за четыре года? Серьезно? Господа, куда-то мы все не туда свернули, как начинает казаться.
              Это ужасно…
                0
                Да и вообще, черт побери, от джуна до синьера за четыре года? Серьезно?

                Мне кажется тут важно определить что понимается под "синьерством".
                Для меня лично "синьорство" определяет опыт. А опыт не зависит линейно от времени. Что даст больше опыта — полгода на новом проекте или полгода на проекте, с которым вы работаете уже 5 лет. Я считаю, что при наличии желания развиваться и возможности часто менять проекты можно довольно быстро "прокачать" свой профессиональный уровень.


                Личный пример: Я закончил университет в 23, сейчас мне 29, что дает мне 5 лет "опыта коммерческой разработки", который так любят указаывать в ваканстиях. Посление 4 года работы я имел возможность перемещаться между различными проектами (проводя на них по 3-6 месяцев). Я повидал Java-монолиты, микросервисы, ASP.NET и C#, Node.js, различные фронтенд извращения и (в последнее время) AWS Serverless. Суммарно, наверное, под десяток легаси проектов в которых я занимался поддержкой (устранение багов, мелкий рефакторинг, написагие тестов), парочку проектов в разработке которых я принимал непосредственное участие и мой текущий первый "свой" проект, где я являюсь архитектором и техлидом.


                За это время я сталкивался с десятками разработчиков. Иногда я узнавал, что мой ничем не примечательный коллега на 15 лет меня старше. Иногда я (и вся команда) пытался понять, как человек с 25 лет опыта разработки находится на позиции синьера, хотя я бы даже на мидла его не нанял. Видел джунов, мидлов, синьеров и людей, для которых можно было бы придумать и планку повыше.


                В целом — мне кажется опыт разработки — это не главные критерии оценки уровня разработчика.

                  +3
                  Я немного из более раннего поколения, и с немного иным опытом работы и учебы. Последние 20 лет приходилось принимать участие во многих проектах с безумным разрывом в технологиях в них задействованых, а уж чего повидал, так вообще говорить не хочется. Хотелось бы увидеть ваше мнение по этому вопросу через лет 5-7, а вообще там дальше DmitryKazakov8 очень хорошо все расписал.
                    +1
                    Что даст больше опыта — полгода на новом проекте или полгода на проекте, с которым вы работаете уже 5 лет.

                    Посление 4 года работы я имел возможность перемещаться между различными проектами (проводя на них по 3-6 месяцев).

                    Ну вот вы и не знаете толком, как может сказться то или иное решение на дальнейшей поддержке. И вы сениор? Шанс-то есть, но без доказательств верится слабо. Вот вы свой проект сейчас запилите и поподдерживайте хотя бы годик — вот опыта вы наберёте прилично. Суть в том, что вы с высокой вероятностью не знаете как из благих намерений и неплохих архитектур получается это ужасное легаси.

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

                    Если есть опыт программирования на других языках, то в принципе за 4 года выйти ни синьорские скилы в js не так сложно, просто надо постоянно обучаться (утомляет, согласен), а главное, досконально исследовать в глубину используемые инструменты, экспериментировать, чтобы понять их суть. Ничего экстремально сложного на фронте нет.

                    +9

                    Я — начинающий Jav'ист. Брали на должность Jav'иста. Начиная от руководства и заканчивая сеньорами все как один говорят: делай акцент не на ЯП, а на методиках разработки.

                      +8
                      У вас грамотное руководство и сеньоры.
                      –3
                      «C# — отличный язык, возможно лучший. Но он не победил Java, и уже не сможет. И помните, какой язык лучше, решают не разрабочики, а бизнес...»
                      1С победил их обоих, бизнес так решил.
                        +1
                        А что такое «победил»?
                          +1

                          А вдруг это был комментарий из параллельной вселенной, где 1с реально всех победил?

                          0

                          Он решил только проблему с ведением бюрократии, и то только в России

                            0

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

                            +1

                            Куда мир катится…
                            Один хороший человек (из тех, кто работал рядом с Виртом, Кнутом, Керниганом & Ричи и т.д) в ответ на вопрос "сколько надо знать ЯП, чтобы считаться программистом" ответил нечто вроде "после 5-7 языков дальше роли не играет".
                            Заметим — "сколько" языков.
                            А не "какой".

                              0
                              В общем, как язык, js гораздо дружественнее к новичку.
                              Новичку нужен не «дружественный язык», а язык, который будет тыкать обучающегося во все его ошибки: новичок постоянно будет лажать и при отсутствии контроля со стороны языка не сможет понять, что где-то налажал. Потому, ничего и никак не контролирующий JavaScript — наихудший выбор для новичка.

                              ИМХО, из представленного автором списка наилучшим для новичка будет предельно простой и максимально сильно типизированный Go. Но намного лучше любого языка из списка будет качественный учебник программирования, после которого можно будет браться за промышленные языки.
                                0
                                Подскажите парочку таких учебников, пожалуйста.
                                  +1
                                  Для начинающих: Вирт, «Алгоритмы и структуры данных» (издание от 2010 года и новее), Кормен, «Алгоритмы. Вводный курс».
                                0

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


                                Фронэнд-разработка более дружественна к начинающему программисту, особенно если у него нет профильного фундаментального образования. Да, есть куча крутых бэкэнд языков, но чтобы зарабатывать с их помощью деньги, нужно знать гораздо больше всего: фреймворки, базы, девопс, отладка и оптимизация в условиях многопоточности и распределенности. Фронт, особенно если отмотать на 5-6 лет назад, когда автор делал свой выбор, наверное был вполне операбелен при знании JS + DOM + JQuery. Сейчас конечно уже и JS, и популярные фреймворки впитали много сложности из бэка, но все равно вряд ли они стали сложнее чем бэк.


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


                                Дисклеймер: не имею никакого отношения ни к автору, ни к его компании, пишу бэкэнд на Java последние 12 лет.

                                  +5

                                  Доброго дня, по теме статьи мне особо сказать нечего — вполне оправданный путь, один из многих. А вот про "вряд ли фронт сложнее, чем бэк", если есть желание, подискутировал бы. Сам пишу и то, и то последние 15 лет, и по сложности нынешний фронт все же, на мой взгляд, стал сложнее. Вот, чем сейчас занимаются фронтендеры:


                                  • синхронизация дизайн-систем и в целом дизайнов с представлением на устройствах клиентов (требуются обширные знания верстки и стилей, особенностей устройств для кроссплатформенности и кроссбраузерности, в том числе принтеров, скринридеров, PWA)
                                  • юзабилити динамических интерфейсов (анимации, отклик на действия, тач-интерактивность, перфоманс, управление с клавиатуры, процессы перехода по страницам и компонентам, отказоустойчивость)
                                  • seo (оптимизация для поисковиков, различные слои аналитики)
                                  • сборка ассетов и подготовка к отображению в веб-среде (оптимизация размера, компоновка по файлам, в том числе загружаемым асинхронно, возможность кэширования на клиенте, полифиллинг и транспиляция)
                                  • функционал, перекочевавший с бэка (системы локализации, роутинг, подготовка данных для апи и валидация моделей, интеграция со сторонними системами)
                                  • пререндеринг на сервере (node.js, настройка сервера, роутинга, безопасности, производительности, кеширования, сессий)
                                  • интеграционные и e2e тесты
                                  • девопсирование (настройка запуска в докере, рецепты для билда в CI/CD, отправка нотификаций и интеграция с CRM, проверка статическими анализаторами кода, прогон автотестов и замер производительности по условиям)
                                  • логирование ошибок и сбор метрик (пользовательские устройства и история операций, скорость загрузки ресурсов и появления / обновления контента)
                                  • интеграция с CDN
                                  • работа с анимациями на svg и canvas, иногда 3d (графики, мультипликация, карты)
                                  • синхронизация между вкладками и устройствами (SeviceWorker, LocalStorage, IndexedDB, параллельные вычисления и вотчеры, офлайн-режим)
                                  • контроль качества кода и форматирования (TypeScript, ESLint, StyleLint)

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


                                  В целом, бэк сейчас выглядит проще. Бэковая многопоточность и распределенность (подразумевает транзакционность, очереди, реплики данных, систему общения между процессами/серверами) вполне по сложности соответствует фронтовой кроссплатформенности (когда приложение должно работать в десятках различных окружений, а не в одном) и синхронизации состояния на разных устройствах. Бэковая работа с базами и моделями соответствует управлению состоянием сотен компонентов во фронтовом SPA (синхронизация отображения и раскладки, стилей, размеров, кодовые интерфейсы компонентов и методы для их контроля, жизненный цикл). Стейт-машины и управление правами доступа, апи-интерфейсы и валидации есть и там и там, и по сложности, опять же, соответствуют. А вот то, что фронтендеру нужно быть еще и околодизайнером, околопсихологом, околоаналитиком, околотестировщиком (в большей степени, чем на бэке), околомобильным разработчиком, околомультипликатором — это делает профессию сложнее. Бэкендеру же приходится быть околоматематиком.


                                  Сейчас фронт — совсем не то, чем занимались веб-мастера (я в том числе несколько десятков бизнес-сайтов нафулстачил), это очень сложная работа, требующая огромных знаний. За 4 года стать синьором, как сказал автор статьи, конечно, не получится — только среднего уровня миддлом, если за это время интенсивно проходить курсы и иметь за плечами 4 разноплановых проекта, по году в каждом. За 5-6 лет при интенсивной нагрузке можно стать upper middle, но редко можно встретить в наших широтах более высокие грейды, т.к. тут уже все задумываются о переезде в культурные страны.

                                    0

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


                                    Когда я пишу, что фронт проще для новичков, я отталкиваюсь от собственного опыта. Лет 6-7 назад (примерно когда автор статьи начинал свой путь) мне надо было написать небольшую админку. Я взял Bootstrap + JQuery, и это было не просто, а очень просто. Писать можно было практически в блокноте, поменял код — сразу увидел результат, доков по Bootstrap и JQuery было достаточно, чтобы полностью решить задачу. Мне кажется, это идеальный расклад для новичка.


                                    И в то же время я наблюдал (и продолжаю наблюдать) мучения Java-практикантов (с профильным образованием!) со спрингом. Надо поставить Java (не все знают про отличия JDK и JRE), потом maven или gradle (т.е. надо знать XML или Groovy и понимать про сборку и контроль версий), потом самую навороченную IDE (которой они не умеют пользоваться), потом сам Spring (di, beans, classpath, конфиги, cuncurrency и еще дофигище всего просто чтобы начать) ну и какой-нибудь Postgre с его спецификой до кучи. И главное, изменения могут привести к ошибкам где угодно: в сборке, в базе, в рантайме. Это еще как сложно!


                                    Да, сейчас фронт со всеми своими npm'ами и react'ами уже вплотную приблизился по сложности. Но фишка фронта в том, что пока еще можно решать вполне актуальные задачи без всего этого, постепенно втягиваясь и осваиваясь. Можно ли то же самое делать в джаве — вопрос.

                                      +1

                                      Я обычно разделяю профессии, которым требуется работать с фронтом, на верстальщика, веб-мастера, фулстак-разработчика и фронтенд-разработчика. Первым двум да, для создания лендингов и шаблонов для CMS достаточно блокнота, готовой стилевой системы и работы с DOM через упрощенный интерфейс (jQuery). Третьему (как вам 7 лет назад) на начальном уровне тоже. Так что соглашусь, в таком формате фронт начать изучать проще.


                                      Но если взять профессии frontend-разработчик и java-разработчик, то первому будет намного сложнее, т.к. это не только работа с несколькими языками и типами в навороченной IDE со сборкой и контролем версий, но еще все то, что перечислил в предыдущем посте. К тому же, он занимается "лицом" проекта, и любые огрехи видно сразу. Исходя из проведенных собеседований, рынок скуп на толковых фронтендеров (достойны найма только 1 из 7), так что порог входа в эту профессию на самом деле очень высокий.

                                        0
                                        Но если взять профессии frontend-разработчик и java-разработчик, то первому будет намного сложнее, т.к. это не только работа с несколькими языками и типами в навороченной IDE со сборкой и контролем версий, но еще все то, что перечислил в предыдущем посте. К тому же, он занимается "лицом" проекта, и любые огрехи видно сразу. Исходя из проведенных собеседований, рынок скуп на толковых фронтендеров (достойны найма только 1 из 7), так что порог входа в эту профессию на самом деле очень высокий.

                                        Чушь же. Ваши требования — требования к крепкому мидлу, в Java к крепкому мидлу тоже весьма приличные требования, а вы этого не учитывает. А вот на старте… почему-то я не уверен, что фронтендеру сложнее. PS бекэндер, что логично, делает API, оно лицо бекэнда… и там огрехи ещё круче видны, чем на фронте, просто они без визуального представления.

                                          0

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


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


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

                                            0
                                            На бэке же покрыл свой апи юнит-тестами достаточно тщательно — и задача выполнена

                                            Это у вас просто бэк идеальный (сферический и в вакууме). А в реальности там монстр из технологий трех разных периодов, часть из которых не поддается юнит-тестированию, часть зависит от версии системного ПО у заказчика, а оставшаяся часть на треть разговаривает со внешней системой, у которой свои милые заморочки, а на треть — зависит от параллельно крутящегося фонового процесса, с которым происходят конкурентные гонки.

                                              0

                                              Мы все же в контексте простых задач для юниоров говорили, в описываемую вами систему разрабов с опытом менее 3 лет, полагаю, и не возьмут, так как профита фактически не будет — с каждой выполненной им задачей будет расти техдолг и дополнительно увеличиваться сложность за счет неэффективного кода.

                                                0

                                                А то, что вы описываете выше для фронтэнда, не выглядит "простой задачей для юниора".

                                                  0

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


                                                  Мой основной посыл — что фронтенд-разработка в простых кейсах (верстальщик, веб-мастер) — хороший вариант для входа в профессию, но и бэк-разработка на таком уровне — тоже хороший вариант, схожий по сложности. А в сложных кейсах и современных проектах фронт стал скорее сложнее, чем бэк в аналогичных проектах, так как требует очень разноплановых навыков, в том числе и по созданию производительных серверных приложений (frontend for backend) и обилию перекочевавшего с бэка функционала. То есть я наблюдаю все увеличивающуюся сложность фронта и упрощение бэка (учитывать легаси тут некорректно, так как и там, и там это создает массу проблем).


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

                                                    0
                                                    А в сложных кейсах и современных проектах фронт стал скорее сложнее, чем бэк в аналогичных проектах

                                                    Неа. Есть кейсы и проекты, где фронт стал сложнее, чем бэк. Но есть проекты, где не стал. И не станет.

                                                      0

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

                                  –4
                                  Еще раз всем привет, коллеги.

                                  Извиняюсь за многочисленные ошибки и небрежный стиль — временной лимит, недостаток опыта и таланта ). Почищу как карма «отойдет» — если отойдет — и будет момент. Вчера не смог из-за кармы.

                                  Удивлен, конечно, негативом и уничижительными оценками. Отвечу на некоторые.

                                  Я не считаю изложенный взгляд поверхностным. Скорее наоборот. Первая оценка какой-то технологии в интернете часто чисто техническая. Что она может в ставнении с другими. Я хотел помочь сделать практический выбор: что учить в первую очередь. Это то, что очень инересует новичков, и то, в чем бывает сложно разобраться. Потому что дать в этом разобраться не совсем в интересах, например, школ по программированию, у которых курс не только по js и java, и их тоже нужно продавать.

                                  Для тех, кого обеспокоила моя мотивация. Дочитайте до конца, последняя фраза должна вас по идее успокоить.

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

                                  Спасибо всем, кто пишет в личку с вопросами, на которые я стараюсь качественно отвечать. А так же за поддержку )
                                    +3
                                    Когда у меня было 4 года опыта разработки за спиной, я тоже считал себя (и числился тоже) синьором. По прошествию еще 4 лет я понимаю, что только приближаюсь к тем задачам, которые решают настоящие синьоры.
                                    0

                                    (промахнулся с ответом)

                                      0
                                      Имхо, если хотите побольше зарплаты и поменьше порог входа, то надо смотреть более новые области разработки. Мобильная разработка еще актуальна в этом плане. Под Android тоже Java, но разница в требованиях огромна.
                                      JavaScript — сомнительное направление. Из-за огромного числа появившихся технологий, порог входа стал как в бэке на Java, C#. Хотя, имеет смысл рассматривать на JavaScript мобильные направления. Но, как по мне, там требования станут больше по сравнению с разработкой на Objective-C/Swift, Java, т. к. из-за кроссплатформенности требуются знания обоих направлений, плюс JavaScript и какой-нибудь Framework на нем.

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое