Silver13

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

Но само решение придумывает программист, а не язык программирования.

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

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

Нет одинаково эффективного пути для всех и каждого.

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

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

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

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

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

На первых порах, тестирование будет занимать до 99% времени и сил. Заодно подтягивается синтаксис используемых языков (вообще не важно каких), вырабатывается внимательность, концентрация, тренируется память и пр.

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

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

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

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

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

Ах да, обложись справочниками по любому инструменту и научись быстро вникать и подхватывать необходимый минимум. Обычно достаточно на 20% владеть инструментом, чтобы решать 80% задач.

В любом случае я за критерий истины держу платежеспособный спрос.

От нуля до героя фронтенда часть 1

От нуля до героя фронтенда часть 2

с мнениями, что знания ангуляр1 "вредны".

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

Например вот то как я готовлю ангуляр, а вот как другие. Последнее считается вредным. Скажем если вы используете $scope в ангуляр приложении версии 1.5+ то вы уже готовите ангуляр не правильно. Если у вас бизнес логика вытекает в компоненты - тоже что-то странное и тд. Но последнее уже никак к ангуляру не привязано.

Стоит ли тратить время дальше на jQuery?

Учите javascript. и так и так понадобится. Причем серьезно учите. И не только основы, надо еще общие вещи, не привязанные к js знать. Типа ооп, функциональное программирование, принципы solid, grasp, dry и другие аббривиатуры. Короче именно серьезно так подойти к этим вопросам. Паралельно разобраться с HTTP, уметь не только пользоваться API но и проектировать их и т.д. Короче это огромный пласт знаний который формируется не один год.

Стоит ли тратить время сейчас на Backbone?

Нет, не стоит. Backbone это низкоуровневая библиотека для тех кто знает как все делать. Человеку который не отличает MVC от MVVM оно только навредит (у меня есть парочка проектов доставшихся от других разработчиков которые демонстрируют проблему).

На сколько экосистема ReactJS стремительно изменяющаяся по сравнению с angular1-> angular2 ?

С учетом того что с моммента выхода angular 1.x до момента выхода angular2 (а он еще в бэте) прошло 4 года... мегабыстро.

Всё упирается в то, что времени/сил после работы на учебу не много остается и не хочется тратить их на то, что в последствии окажется "вредным".

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

Самое сложное во фрилансе, не языки и технологии.

• Умение продавать себя в толпе конкурентов. Это самое сложное. Есть много высококлассных специалистов, сидящих на среднем окладе. Они тупо не могут себя продать даже в другую компанию, а не редко и боятся менять привычное место.
  
• Умение грамотно составить или согласовать ТЗ. Так что бы проблема заказчика решалась в оговоренные сроки и бюджет. А не перерастала в вечнострой с кучей доделок и переделок с базовым бюджетом. Когда обе стороны уже ненавидят друг друга. Ибо работая в офисе разработчиком, всё это ведут менеджеры и тим лиды, а вам спускают конкретные задачи. Вам же придётся научиться понимать, что хочет клиент, не разбирающийся в программировании, говоря то или это. Научиться понимать и предлагать те решения, которые будут ему актуальны с учётом технологий и отказывать в том, что сделать не реально. Находить компромиссы, но опять же, объясняя почему так или иначе.
  

Самое лучшее для фрилансера, да и любого разработчика. Это большие и долгие проекты. Когда можно постоянно заниматься одним. А не вникать каждый раз по новой, не привыкать к новому заказчику. Да, тут есть шанс отупения и застоя в развитии, но это лечится средними своими проектами или доп работой небольшой. Хотя, если проект живой и развивающейся, руководство ищет способы развития бизнеса и само заинтересованно в росте. Тогда можно и на текущем проекте развиваться, пробуя новые технологии, службы, стеки. Это будет рост как специалиста.

А технологии, языки. Это уже второстепенно. Главное развиваться. Ибо в попсовом PHP можно делать большие проекты и быть специалистом с большой стоимостью часа или на редком python/java сидеть и быдлокодить мелочь за копейки. Главное не метаться, а развиваться и расти, беря более сложные и более длинные проекты. И брать их не с "поддержкой", а с возможностью постоянного развития. Задачи "в стол", не интересны. А вот задачи на перспективу, на развитие. Это уже интересно. Ибо "в стол" это как правило теория(придумали, сделали, забыли). А развивающиеся, это практика на реальных условиях, когда в процессе приходится много менять (менять бизнес модель, менять архитектуру из-за возросших нагрузок, менять технологии).

Я рекомендую изучать JS примерно таким путем:
– чтение learn.javascript.ru (чтение и, естественно, практика);
– параллельное прохождение модулей по JS на codeschool;
– держите перед глазами актуальные вопросы для собеседования JS-разработчика (habrahabr.ru/post/239065/), стараясь на них ответить;
– читайте хороших авторов: Дуглас Крокфорд, Джон Рейзиг, Стоян Стефанов;
– найдите на GitHub людей, которые согласятся ревьюить Ваш код, я серьезно!

Ну и не забывайте: чем чаще Вы пишите код, тем лучше получается; чем сильнее стараетесь разобраться в основах языка, тем легче будут даваться в освоении фреймворки и паттерны.

Желаю успеха!

Руководствоваться в этом деле нужно принципом "от простого к сложному". Чтобы достичь поставленной цели: реализация собственных проектов в вебе, - необходимо, как минимум, владеть знаниями по следующим языка/технологиям:
HTML/CSS
JavaScript
PHP
Apache
MySQL
XML/XSLT (опционально)
Ajax
jQuery

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