Modu Chanyu

Дополню к другому ответу примером. Вот это все практически одно и то же:

class Ancestor(object):
    def method(self):
        print("Hello from", self)

class Descendant(Ancestor):
    def __init__(self):
        super(Descendant, self).method()

class Descendant2(Ancestor):
    def __init__(self):
        super().method()

class Descendant3(Ancestor):
    def __init__(self):
        Ancestor.method(self)

d = Descendant()
d2 = Descendant2()
d3 = Descendant3()

Hello from <__main__.Descendant object at 0x00F2FAD0>
Hello from <__main__.Descendant2 object at 0x00F2FB70>
Hello from <__main__.Descendant3 object at 0x00F2FB50>

upd: Второй вариант (super без аргументов) работает только в 3-м Питоне.

Большинство советует потратить полгода-год, работая в компании, но вопрос стоит «Как начать брать крупные заказы на фрилансе?». Да, работа в продуктовой компании поможет поднять свой уровень, но это не тот ответ. После работы в хорошей компании может и не захотеться возвращаться во фриланс. Вопрос стоит «как повысить свою компетентность, продолжая работать на фрилансе, и выбраться из потенциальной ямы лендингов и бложиков?»

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

Применяйте продуктовые подходы во фрилансе.
Свяжитесь с прошлыми заказчиками и поинтересуйтесь, всё ли работает как ожидалось, надо ли что-то доделать, переделать или улучшить. Заполучите постоянных заказчиков. Если повторно поработаете над своим прошлым проектом, заметите, что было сделано не очень, и поймете, как делать лучше сразу.

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

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

Саморазвитие на фрилансе по-любому будет идти медленнее, чем в развитой продуктовой компании.

Вопрос некорректен, т.к. слишком много неизвестных переменных.
В общем случае правки делать прямо на сервере лучше не нужно. Тем не менее, если это мелкие правки и доделки например стилей или скриптов - бекапим нужные файлы, правим на сервере и берем оплату. Это если задачи порядка "поправьте у меня что-то на сайте текст налазит на картинки" и т.п.
Если же задачи сложней, например разработка дизайна, или создание плагина, или правка купленного шаблона темплейтмонстра - процесс будет иным, и зачастую у каждого свой, потому что каждому будет удобней так или иначе это делать. Кому-то в дропбоксе, кому-то в гитхабе, кому-то по фтп с локалхоста заливать. А кто-то вообще CI у себя развернул.
У меня например если мелкие заказы от постоянных клиентов, есть директория заказчика на диске "projects", там создается директория по текущему проекту. Результат передается удобным для заказчика способом, то есть зачастую просто по почте или заливается на файлообменник и опять же по почте. Потому что неайтишным заказчикам именно так привычней и понятней работать. Если задача занимает день или даже неделю - зачастую бекапиться и контроль версий вести нецелесообразно.
Более крупные проекты - это уже совсем другой разговор. Там уже и серверные бекапы, и контроль версий, и распределенная работа, и асана. Так что в данном вопросе нельзя дать единственный правильный ответ.

Вы хотите стать "стать настоящим Middle PHP-разработчиком" но почему-то возникает RoR и NodeJS. Я часто встречаю, когда люди научились работать с циклами в php и думаю, что на этом он закончился. И лезут в совершенно другие сферы. Зачем? Освойте что-то одно хорошо, прежде чем заниматься чем-то совершенно другим. По сути Вы в it теме год с хвостиком и уже php и Symfony знаете отлично?
Хотите стать мидлом - копайте глубже, а не шире. Иначе будете джуном в 45 направлениях.

Не спеши сесть сразу на фреймворки, ковбой. Для начала твой базовый уровень JS (ES5 и ES6) нужно подтянуть до хорошего/отличного. Нужно хорошо разобраться в функциях, прототипах, паттернах и т.д. Хорошее знание всего этого - основа любого фронтендера и любого фреймворка. Знанием jQuery уже давно никого не удивишь. Касательно фреймворков, я бы посоветовал начать с React/Redux, ибо в данный момент это тренд. Но в уме держать Angular2. И еще надо забыть про gulp/grunt, webpack - наше все.

ЗЫ: Когда я хочу изучить какой-нить фреймворк, я просто открываю офф. мануал/туториал и пилю какое-нибудь приложение с нуля. С нуля - это значит с нуля. То бишь, открываю свою любимую IDE, запускаю командную строку, пишу npm init, устанавливаю необходимые либы, делаю сборку на вебпаке и начинаю кодить.

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

Например, клиент спамит сообщениями (вываливает весь свой поток мыслей в чат). Очевидно, что такое же поведение будет и на проекте — бесконечные идеи и переделки.

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

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

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

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

Программировать, конечно. В первую очередь.

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

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

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

Как вариант - пройти легендарный гарвардский курс CS50 (Introduction to Computer Science) на платформе edX.com
Сайт javarush.ru каждую неделю выкладывает очень качественный перевод лекций этого курса.

Данный курс направлен на рекламу Учебного учреждения, но никак не на потенциальное обучение конкретным знаниям. Данный курс будет полезен тем людям которые далеки от технических профессий (в частности - программирование). Данный поток видео просто введет вас в мир компьютеров. Он не научит вас чему то конкретному, просто вам покажут что вообще есть в "мире технологий". Задания выполнять вообще не обязательно. Все равно они вам ничего не дадут. На большинство заданий у вас все равно не хватит знаний. Люди которые сидят там в аудитории, во первых имеют немного больше сообразительности, чем другие люди, по крайней мере потому, что они смогли попасть туда на обучение. Во вторых, по мимо этого курса у них полно других, по конкретным направлениям.
В общем если вы хоть немного шарите в программировании, то вам этот курс толком то ничего нового и не откроет. По конкретным направлениям читайте профильную литературу, смотрите узконаправленные курсы.
А если вы вот только что решили что будете заниматься в области вычислительной техники и вообще не понимаете что да как, то посмотрите данный курс для легкого введения. Просто смотрите, делать задания не нужно.

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

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

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

что должен знать идеальный джуниор (мое личное мнение):

- Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое HTTP или чем TCP от UDP отличается - нужно. В целом это пара часов чтения википедии.
- GIT или любая другая распределенная VCS. Базовые навыки, что бы хотя бы понимал что есть git revert или git rebase, что такое фичабрэнчи и примерное представление как это работает и зачем надо.
- Базовые основы unix. Ну то есть что бы не пугаться таких вещей как ssh хотя бы.
- PHP. Без этого никуда. Он должен понимать что такое слабая динамическая типизация (не заучивать табличку кастов типов, а понимать плюсы и минусы, такая же история с приоритетами операторов - не заучивать а знать как избегать проблем с чтением кода)
- Понимать что код чаще читают чем пишут, а потому не экономить 5 минут на написании кода, а писать так, чтобы сэкономить 30 минут человеку, разбирающемуся в куске кода.
- Знать базовые вещи в плане безопасности. XSS и как защищаться, SQL инъекции и как защищаться, CSRF, MITM. Понимать что такое NDA, что данные пользователей - секретная информация. Как хэшировать пароли (не md5 а password_hash) и почему это важно.
- Знать SQL. Глубоких знаний не требуется, нужно лишь понимание того, что такое нормальная форма, желательно разобраться с вопросом денормализации данных. Идеально иметь хотя бы базовые представления о том как работать с NoSQL решениями.
- Процедурное программирование: почему глобальные переменные порождают сложность, что такое состояние, как можно использовать классы для изоляции состояния и т.д. Инкапсуляция. Инварианты, пост/пред условия, сохранение целостности...
- Разделение ответственности. Это один из важнейших принципов, и упрощать все это до "mvc фреймворк" слегка неправильно. Вы должны понимать что от чего отделяете и главное зачем.
- Автоматические тесты. Джуниор должен знать что это такое и иметь хотя бы минимальный опыт их написания. Должен понимать разницу между юнит и интеграционными тестами. Быть знакомым с пирамидой тестирования.
- Уметь решать стандартные задачи не задавая слишком много вопросов. Например регистрацию пользователя по email-у вы должны написать, или авторизацию через соц сети, или комментарии, или новостную ленту.
- Уметь дебажить. xdebug, blackfire и тд.

В целом где-то за годик весь этот список можно влегкую покрыть с нуля.

p.s. Я в списке специально не указывал ООП, поскольку всеравно первые пару лет у разработчиков выходит процедурщина на классах. Это не плохо, но того что в моем списке более чем должно хватать для решения стандартных задач. Но термины вроде "инкапсуляция/полиморфизм/наследование" требуются в обязательном порядке подавляющем количеством интервьюверов, а стало быть знать это надо. Единственное что - рекомендую в свободное время глубже погрузиться в этот вопрос а не тупо заучивать формулировки.

Так же вещи вроде docker джуниорам знать не обязательно просто потому, что их врядли допустят сходу к управлению инфраструктурой. А так пару неделек на изучение и вперед.

Фрейворк - полочка в которую можно складывать инструменты (библиотеки). А некоторые нельзя складывать в силу тех или иных свойств как полочки (фрейворка) так и инструментов (библиотеки)