Юрий Ярош

У БЭМа есть ряд сугубо исторических причин существования:

• Когда-то в далёком 2008м был Firefox 3, в котором селекторы на классах работали быстрее чем на div'aх - потому что в префиксном дереве не выполнялся проход по фильтру Блума.
  
• Атомарный подход существовал ровно столько же сколько и XUL, но вместо изобретения индивидуального языка разметки, решили обойтись решением на основе стандартных CSS селекторов.
  
• Нужны были инструменты для автоматизации разметки по существующем иерархиям стилей - появился bemjson / bemhtml etc
  

Нужен ли БЭМ ?
Если вы понимаете приемущества атомарных подходов в верстке и активно их используете - он вам не нужен, и будет избыточен. В противном случае - берите и пользуйтесь.

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

Проще всего тут же на тёплом-ламповом фрилансиме.

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

Т.е. работали вы месяц, оформились в ИП, а в акте написать что вы работали 3-4 дня...
Люди обычно ещё проводят через подставных юр лиц. и спд основные суммы, а минималку записывают как доходы, но это уже от 2 до 5ти и куча штрафов.

У меня оно бывает вот так.
Думаю, у вас будет где-то так же через 5-7 лет ...

Пишу на питоне ещё с 15 лет (2.4+)... ненавижу его runtime и архитектуру. Язык хороший - реализация никакущая. Ну да его синтаксис достаточно упрощён, но и за синтаксический сахар приходится платить сложностями отладки и поддержки.

Сейчас же почти все известные мне конторы не используют питон в продакшенах с более-менее высокой нагрузкой. Яндекс тому пример. Чаще питон используется для решения прикладных задач администрирования, так как это делается, к примеру, в SaltStack. Все дружно слезают с питона, РНР и рельсов на Golang, Java/Scala, и иногда даже Groovy - производительность выше в десятки раз, и managed runtime на много стабильнее. Правда в случае с JVM очень сильно раздувается куча в виду избыточности объектной модели (оператву жрёт как дурное, а я байтики считать привык). Сейчас это должно лечится с помощью Project Graal и Truffle, правда пока до этого дошёл только jRuby, который тоже в пару десятков раз быстрее Ruby. По идее и Groovy тоже должен переползти как-то ... Вот про jyton ничего не знаю.

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

Фрилансить с питоном начать можно, но очень желательно опробовать ещё хотя бы пару окружений и фреймворков типа Groovy Grails, или Typesafe Stack. Сейчас требования рынка возросли в пару раз за последние два года - нужны ассинхронности/многопоточности, push-нотификации в мобильные приложения и по вэбсокетам/комету. И это всё с богатыми js-фронтендами на всяких там Angular'ах и React'ах. Естественно можно крутить костыли типа Celery / Gearmand / Beanstalk / RabidMQ, но накладные расходы на коммуникацию слишком большие :( Компилируемые языки со своими Managed Runtime'ами позволяют строить монолитные приложения в которых подобные решения избыточны в рамках одной и той же машины, а если это куча нод в кластере то нужно мерить/думать.

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

А вот с pyramid (pylons) и SQLAlchemy можно строить достаточно хорошие приложения. У них есть enterprise поддержка и соответствующие гарантии.

Типовые задачи на питоне:
- написать какой-то мелкий скрипт с Gui на PyQT / Pyside для какой-то аналитики и отрисовки графиков, иногда попадаются задачки с gstreamer'ом
- написать какое-то простое RESTful CRUD приложение, в стиле "одна табличка БД - один контролеер", это конечно же тонна копипасты и мне больше нравятся DataMapper'ы по типу TastyPie. Иногда люди хотят чистого Tornado или Flask'a, так как им не нравится overhead в джанге и pylons.
- написать скрипты для деплоя чего-то, обычно люди не знают про SaltStack.

В плане архитектуры питонистам чужды различные SOA с CQRS-ES'ом, потому что сам компилятор не располагает. Хотя её достаточно просто поддерживать.

Проблема всех проектов на Node.js / Python / Ruby это отсутствие долгосрочной поддержки библиотек и фреймворков - часто ломается обратная совместимость, и нужно постоянно следить за состоянием всех зависимостей. Опять же нужен TDD/BDD для того что это всё хорошо контролировать. Тестируешь руками - себя не уважаешь.

Ну и вроде всё ...
p.s. я опубликую на хабре статью сегодня-завтра "Freelance - you're doing it wrong" там поделюсь опытом работы и основными организационными проблемами в рамках удалённой работы и фриланса, покажу разницу между ними.