Trow_eu

Для многих будет полезно как мне кажется про кастомизацию тем.

В сРунете куча постов про разработку тем под wp (тысячи их, полторы калеки из которых - нормальные), а вот узнать как пилятся темы подобные на themeforest с кучей кастомизации, настроек можно только из зарубежных статей блогов - спрос на ваши статьи мне кажется будет.

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

чисто, имхо

Вам сюда ihatetomatoes.net/one-page-scroll-with-animations
демо ihatetomatoes.net/demos/one-page-scroll-animations

Половина ответа в вопросе, но дьявол в мелочах.
Действительно, для относительно продуктивной backend-разработки практически на любом языке программирования необходимо знать несколько базовых фреймворков и тулов, которые решают большинство задач. Это скелет ~90% приложений сложнее hello world. Хотя и этот скелет меняется и развивается, пусть и не так быстро как хотелось бы, как разнообразные отростки (не консервативность, но более долгий жизненный цикл). Суммарный вес технологий и инструментов не меньше, и уж точно не менее динамично изменяющийся, чем у frontend-разработчиков.
Далее личный опыт на примере Java.
Лет 7-8 тому достаточно было знать Spring, Struts, Hibernate да Apache Commons в довесок для разработки большинства решений. Ну и J2EE-стек для задач Enterprise-уровня.
В году 2014 Spring, Hibernate все также в арсенале программиста, но появилась куча абсолютно новых вещей вроде AMPQ, Hadoop, Netty, Scala с функциональной парадигмой, мультиязычные окружения с Clojure/Groovy/JRuby; стали чаще встречаться альтернативные реализации популярных библиотек (например Guice / Guava); старые технологии вроде J2EE стали использоваться несколько реже. А одних только Key-Value хранилищ, кэшей и прочих NoSQL как грязи. Изменился даже сам подход к построению приложений – мало кто в 2005 слышал про asynchronous event-driven модели и отталкивался при проектировании от REST-стиля (собственно, там и корни frontend-девелопера как отдельной специализации). Про эволюцию систем сборок, VCS, бенчмарков и прочих "микро"-элементов можно расписывать не одну простыню.
И да простят меня frontend-товарищи за, возможно, чванливый тон, но раскурить тонкости работы async IO в зависимости от ОС-специфики вроде epoll/kqueue или учитывать CAP-теорему при построении middleware-кэша это уровнем сложности повыше, чем новый CSS-препроцессор и CoffeeScript c очередным MVC / MVVM-фреймворком. Некоторые задачи, вроде синхронизации потоков, так и вообще лежат большей частью в области математики.
Уверен, что и в frontend-разработке существуют задачи сложнее и интереснее поехавшей на пиксель верстки и обновления полей после парсинга JSON, но ИМХО backend-разработка ближе к системному программированию старой школы, в то время как frontend суть прикладное программирование с примесями дизайна.
Frontend-инструментов больше, backend-инструменты сложнее.

codepen.io/iiil/pen/xiChJ
Вопрос у Вас сформулирован на 5+.

Талантливые сотрудники:
Красивый велосипед из костылей.

Собственное производство:
Классический американский домик, вид сбоку, в разрезе, сверху семья пьёт чай с печеньками, а в подвале китайцы/мексиканцы собирают игрушки

Лучшее качество
Пустой рынок. Открыта только одна палатка. С табличкой "Лучшее на этом рынке!"

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

Препод с универа, который тоже и зарабатывает неплохо и вроде как совсем не дурак - говорит, что "разобраться в MVC, MV... ruby, python" - часа 3-4 (сам работает со встраиваемыми системами по основному профилю)

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

Явно, не стоит делать соцсеть на perl, форум а-ля phpBB на nodejs или лэндинг на erlang.

Наверное, самое главное - это интерес и "подходящие" проекты. Подходящие - значит:
1) вовремя (ничего в данный момент не отвлекает от конкретного проекта)
2) осмысленно (или хорошо оплачивается, или доставляет много удовольствия)
3) хорошая команда или хороший настрой, если делаешь сам
4) хорошо вписывающийся в интересующий стек, что б не впихивать стек в проект и страдать.

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

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