ksean

Мне 30 лет. По образованию инженер-механик. До 26 лет, после вуза, работал в машиностроении, как на крупных заводах, так и в маленьких консалтинговых фирмах, кормящихся за счёт тех же заводов на поставках инструмента и оборудования.
До тех пор, начиная с третьего курса вуза, считал что машиностроение не моя тема. Также как и вы считал, что ИТ моё призвание. Тянуло к интеллектуальной работе. Поначалу я искренне так считал.

В течении почти четырёх лет работал над тем, чтобы переквалифицироваться и стать Программистом. Шёл по священному пути хабра-сообщества, следуя его идеалам ) Алгоритмы, шаблоны проектирования, UML и проектирование. Ориентировался на Java SE и EE, Web. Параллельно "освоил" C++, php, asm (x86), позднее Dart, некоторые другие технологии и платформы.
Кроссплатформенность выбирал изначально, поскольку являюсь сторонником свободного софта, и выбрать платформенно зависимые вещи не мог (ибо в коммерции в 99% случаев компьютеры потребителей заправлены MS Woe).
Даже поступал на учёбу на второе высшее дистанционным способом, в ТУСУР. Толку, правда, было мало, так что ушёл после года "обучения".

В 26 лет, пока не поздно, как я считал, наконец сделал рывок. Сменил работу. Устроился в ИТ-отдел одной несофтверной корпорации. Здесь я и хлебнул всей ИТ-грязи сполна. Хотя плюсы тоже были, кое-что с того места работы я для себя извлёк в профессиональном плане (написание больших и сложных SQL-запросов, хранимых процедур и функций). То был типичный ИТ отдел типичной несофтверной организации. Мы занимались разработкой информационной системы для собственных нужд (ERP/CRM/SRM/... и т.д.), чуток админили. В общем это было первое место в моей ИТ-карьере. Продержался на ней меньше года. Далее был книготоргующий магазин. Затем, наконец, софтверная фирма, специализирующаяся на широкопрофильных бизнес-приложениях.

В общем, этого хватило, чтобы понять, что профессиональная разработка не моё призвание. Сейчас я очень доволен, что во время осознал это, что не стал форсировать, делая работу, которая, мягко говоря, не по душе.
Во всех трёх фирмах я занимался по сути одним и тем же, пусть и используя разные инструменты и языки. Увольняясь с последнего места работы, уже имел стойкое отвращение к бизнес-приложениям. Здесь я окончательно убедился, что большинство коммерческих ИТ-проектов глупы и никчёмны. А от гламурненьких сайтиков с "чётко проработанным дизайном" просто тянет блевать. Вот, например, одна из вкладок, открытых в данный момент в моём браузере: ссылка. Это пример нормального дизайна (хотя осознание этого пришло не так давно). Только информация, без всяких прелестей, какие имеют место в enterprise, и помогающих продажникам впарить очредную систему учёта. В общем, я не буду останавливаться на камнях ИТ-пути, какие попались мне (всё таки toster - ресурс, аудитория которого программисты или студенты ИТ-специальностей, дабы не вызвать гнев окружающих).

Сейчас я снова работаю в машиностроении, специалист высшей категории )) Но программирование всюду со мной. Мои дополнительные руки - GNU Octave и plain C. Все задачи, встречающиеся мне решаю творчески. Вычислительные эксперименты и обработку экспериментальных данных, нейросети - в Octave, синтаксические анализаторы текстов программ для систем ЧПУ станков с программным управлением, большие вычисления на всех ядрах - на Си. Это, конечно, не повседневные задачи, ибо слабо отражают суть моей технологической работы. Но Octave нужен ежедневно, ежечасно, почти ежеминутно.
В последнее время стал копать низкоуровневое программирование и встраиваемые системы. Это очень увлекательно. Но это не продаётся (по крайней мере так, как продаются всякие "системы автоматизации бизнеса").

Это было долгим введением, чтобы сказать: не ступайте на ИТ-путь, путь "мужчины у монитора". Фрилансом особо сыт не будешь. Современным веб-дизигнерам и фронт-ендщикам следует отрывать руки, не становитесь с ними в один ряд. В любом случае освоение новой платформы и технологии на профессиональном уровне - кропотливый труд. Не знаю, как бы я занимался этим сейчас, обзаведясь семьёй и ребёнком: просиживать вечера напролёт теперь стало нереально.
Но что можно предложить, если желание серьёзное? Совместить. Как тенденция междисциплинарности в науке, как межотраслевая интеграция в бизнесе - найдите идею как применить одно к другому, как совместить автодело и программирование, чтобы они стали удобны, прежде всего, для вас самих. Не ставьте крест на опыте авторемонта (а уходя в ИТ, потребуется уйти в него с головой, как отмечали здесь некоторые). Дополните ваш опыт новым вливанием, новыми знаниями. И если у вас что-то выйдет, то можете поделиться этим с миром open source )

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

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

Собственно, когда вы определились с ЯП, начните изучать его. Но ни в коем случае не налагайте на курсы\видео-уроки типа Специалиста и т.д.(подробнее об этом - читайте дальше). Еще отправной точкой для выбора языка\технологии может стать изучения рынка вакансий. Хотя этот фактор нисколько не отражает действительность.

Выбрали ЯП? Изучите его до более-менее среднего уровня. Освойте основные технологии\библиотеки\фреймворки применимые для этого языка. Зачем это? Возьмем для примера C#. Знания самого языка не несут такой ценности, как владение фреймворком .NET и навыками работы в том же ASP.NET, WPF\Silvelight и т.д.
Помните, вы не сможете освоить язык и его технологии на все 146%. Как показывает практика, 20% конкретных знаний достаточно для решения 80% всех задач (Закон Парето).

Теперь немного об конкретном, а именно о книгах.
Для начала я бы рекомендовал прочесть "основы основ", например:
Объектно-ориентированное мышление
Паттерны проектирования
Приемы объектно-ориентированного проектирования. П...
Объектно-ориентированный анализ и проектирование ...
После этого можно приступать к специфической литературе по конкретному языку\технологии.
Думаю, с этим списком вы определитесь сами, когда подберете себе что-то.

Если вы думаете записаться или посмотреть в Интернете курсы, например, того же Специалиста, сразу же БРОСЬТЕ ЭТУ ЗАТЕЮ!
Приведу пример с моего горького опыта. Дело было в 2011 и я впервые услышал об этом Специалисте и наивно полагал, что там действительно делают "специалистов". Такие уважаемые люди как Борисов и Тарасов, в которых уйма всяких сертификатов, просто внушали доверия и интерес ко всему этому. В итоге я посмотрел 50 часов HTML + CSS. Никакого результата. Эти 50 часов не покрыли даже половин знаний, что я до этого почерпнул с книг. Да ладно, идем дальше. Засел я за 2 уровня JS на 30 часов + 6 часов jQuery. И тут все мои радужные представления об Специалисте моментально разрушились. Будущие специалисты бежали с аудитории после пары непонятных слов, преподаватели путали элементарные понятия, все рассказывалось на тяп-ляп и в каком-либо порядке. В итоге этот курс не покрыл и 20% материала из книги Николаса Закаса по JS. В итоге все эти десятки часов пошли коту под хвост.
Если вы действительно нуждаетесь в курсах, то лучше воспользуйтесь видео-учебниками Lynda, Tutsplus и т.д. Эти ресурсы за пару часов ознакомят вас с основами сабжа и направят на путь истинный.

Что же касается книг, то как было верно отмечено пользователем kstyle:

только 10% молодых человек способны к самообучению (то есть если им предоставить литературу и задачи, то 90 % не справятся). многие - из-за качеств характера.

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

И, конечно же, вы должны быть уверены и настойчивы!

Мне 30 лет. Начал свою карьеру в ИТ в 27.
У меня ИТшное высшее образование, но жизнь сложилась так, что во время учебы нашел работу не по специальности, которая сразу начала приносить неплохой доход (производство рекламы: наружка, полиграфия). В один "прекрасный" день, спустя 10 лет работы, я понял, что достигнут потолок и мне совершенно не интересно дальше развиваться в этом направлении. Тогда то я и начал искать чем заняться.
Я прекрасно понимаю страхи и мысли, которые крутятся в голове у человека уже с семьей.
"А не поздно ли?", "А с чего начать?", "А как на меня будут смотреть другие люди/друзья/коллеги?", "А на какой доход и через сколько времени можно рассчитывать?", "А откуда взять время на жену/детей и учебу?" и еще куча других...
В 16-22 все эти вопросы совершенно не волнуют - ты еще юн, свободен от обязательств и в какой-то мере финансово не обременен...

Немного порассуждаем :)

Отвечу на самые-самые вопросы:
А не поздно ли?
Нет. Никогда не поздно! Звучит банально, но это работает.
Нужно срочно забыть сколько тебе лет и оперировать только понятием жизненный опыт. А его к 30 уже порядком. Мозги еще не "заржавели", тело еще не барахлит.
НО нужно сразу условится - любая сфера ИТ требует ПОСТОЯННОГО самосовершенствования и изучение нового материала. ЛЮБАЯ.

Чем заняться-то?
Я для начала для себя определил две области ИТ в которых возможен быстрый прогресс за короткий срок и достаточно быстрое трудоустройство. 1С-программирование и веб-программирование.
Они были выбранные после тщательного анализа локального рынка труда + низкий порог входа + возможность быстрого прогресса. Долго сомневался, читал форумы и статьи, что бы выбрать окончательно, но в итоге победило направление веб-программирования. Решающим стали два критерия: возможность удаленной работы на зарубежных биржах и отсутствие привязки к конкретной узкой технологии. В финансовом плане 1Сники на начальном этапе получаю больше, но со временем Веб вырывается вперед.
Многие написали выше, что надо учить основы основ. Разложить всю теорию по полочкам. Понять принципы ООП и паттерны проектирования. Это правильно, НО... время+семья+деньги накладывают некоторые свои ограничения. Как мне кажется главная цель - это смена сферы деятельности, т.е. добиться результата. Да, по началу будут жуткие "решения" и "ужасный вырвиглазный лапшевидный говнокод", НО плох тот программист, который не продолжает свое обучение ПОСТОЯННО. Но учиться уже на работе под руководством более опытных товарищей НАМНОГО проще.

А с чего начать это ваше "веб-программирование"?
Сразу оговоримся, что есть принципиально два разных направления: "фронт-энд" и "бэк-энд". "Фронт-энд" проще и дружелюбнее для совсем начинающих. Его изучение позволит быстрее прийти к выполнениюглавной цели. Поэтому дальше я буду рассматривать именно это направление.
Да-да, конечно, потом можно и "бэк-энд" изучить и даже полностью перейти на него. Можно совмещать, обв.
И еще одно отступление: уровень английского Pre-Intermediate. Это само собой разумеющееся. В любом случае придется читать, слушать и понимать.
Итак по теме вопроса.
Рекомендую начинать с: htmlacademy.ru - пожалуй лучший русский ресурс для новичков. Интерактивные задания с самых азов. Все основные курсы бесплатные. Платная подписка открывает доступ к продвинутым курсам - рекомендую покупать эту подписку уже после прохождения всех базовых курсов. Есть два платных месячных "интенсива" - весьма неплохие и стоят своих денег.

Остальные ресурсы рекомендую проходить параллельно с HTML-академией, начинать где-то после 7 курса:
www.codecademy.com - на английском. Помимо курса по HTML&CSS можно попробовать JavaScript и jQuery + неплохие ознакомительные курсы по "бэк-энду"
https://dash.generalassemb.ly - на английском. Интересны тем, что имитируют выполнение реального заказа на фрилансе.
Есть еще куча ресурсов и курсов, но для начала этого вполне хватит.
В любом случае придется изучить JavaScript. В этом деле поможет уже упоминаемый выше www.codecademy.com + learn.javascript.ru

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

А откуда взять время на жену/детей и учебу? Как совмещать-то все еще же работа есть...
Если уделять учебе хотя бы 1 час в день, то можно вполне все успевать.
Я учился так:
- на работе была возможность почитать и поделать небольшие занятия в течение дня ( в сумме полчаса)
- еще часик уже ночью, когда все спят дома.
- в выходные вставал пораньше и в субботу за два часа пока все спят повторял все сделанное за неделю, а в воскресенье подбивал итоги и планировал следующую неделю.
Придется пожертвовать сериальчиками и какими-нибудь излишествами нехорошими - всегда есть что-то. Все время дисциплинировать себя первое время. Можно вести блог или поставить цель на смартпрогресе. Главное регулярно заниматься. даже 15 минут в день - это уже большой плюс.
Еще очень важно, что бы домашние знали к чему вы стремитесь и чем заняты.

А на какой доход и через сколько времени можно рассчитывать?
Тут все ОЧЕНЬ индивидуально. Все зависит от усердия и желания.
Можно грубо прикинуть "скоростное прохождение этого квеста":
1) материальные вложения: 30-32 т.р. два интенсива(базовый и продвинутый) и помесячная платная подписка на htmlacademy.
2) временные вложения: 5-7 месяцев на курсы и интенсивы от htmlacademy + 2-3 месяца на основы JavaScript и jQuery

После этого вполне можно пойти работать верстальщиком с перспективами карьерного роста с окладом от 15 т.р. или попробовать себя на фрилансерских биржах.
Почему так мало?В моем регионе именно столько получают стажеры-верстальщики в первый месяц, но это уже работа + на реальных проектах прогресс пойдет намного быстрее. А следовательно и вырастет доход.

А не будет ли мне сложно "работать" в молодом коллективе?
Возможно первое время будут какие-то сложности, но как мне кажется в любом случае ценятся базовые человеческие качества + профессионализм. А если учесть, что к 30 уже есть достаточно богатый жизненный опыт, то я не думаю, что возникнут проблемы.

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

Собственно, прошу совета: не поздно ли мне, ибо вокруг всем по 19-20 лет и с практическим опытом, а у меня особо похвастать нечем.

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

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

За больше 20 лет - только 3 человека попались с опытом 19-20 лет.
99,99% и в 22 года - без опыта.

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

В данном случае: забить на веб-фриланс (и вебдев вообще) как основной источник дохода и пойти работать... курьером, на завод, дворником, в конце концов.

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

В общем что нужно иметь в наличии чтобы брать заказы на фрилансе или устроится в студию на удаленку?

Нужно найти такие вакансии и посмотреть, что они требуют

Просто есть много контор, где пыщ-пыщ и в продакшн. Там особой квалификации не нужно, зарплаты, маленькие, переработки постоянные. Конечно им нужен "до 35 лет ... молодой, энергичный", а по факту просто низкоквалифицированный чувак с низкой зарплатой.

Опытные программисты и сами в такие конторы не пойдут.
После 50 знакомых программистов нет, но после 40 вроде никаких проблем с трудоустройством не замечено.

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

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

Но мне стало интересно как и вам, кто и как меня взломал. Своими скромными силами я не смог определить.
В итоге создал в корне сайта файлик forHacker.txt
В нем задал вопрос - собственно как вы меня хакнули?
на следующий день в аську стучится человек, я спрашиваю
- Мол чего вам надобно? - в ответ
- Товарищ Иван, вы же сами просили меня вам рассказать как я вас хакнул
- Спасибо что откликнулись, просветите плз
- Ваша девушка Света была не аккуратна, скачала мой файлик. В связи с чем я смог получить доступ к ее компу. Далее по локальной сети обнаружил доступ к вашему. Подсадил кейлогер и просто подождал ввода пароля.
....
Всего вам хорошего и удачи. Ваш сайт оставляю в покое =)

Это примерный наш разговор.
Так что способов получения ваших данных велик )

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

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

Наш отечественный малоизвестный, но неплохой сервис find-xss.net (реф)
Есть бесплатная проверка файлов до 5Mb, при этом показывается по моему первые 5 найденных уязвимостей и мест на которые стоит обратить внимание.
Можно купить платный доступ на 24 часа за 3$ и проверять проекты до 20Mb, а так же сразу покажет весь отчёт.

Для параноиков есть клиент сканера реализованный на Java для проверки на своей машине.

С бесплатной версией есть небольшой лайфхак. Выкидываете из проекта всю графику, js, css и вёрстку (если она подключается шаблонизатором например) что бы проект максимально облегчить, жмете максимально архив и заливаете. Если всё равно не хватает места, то проверять в несколько этапов разбивая проект на куски и выкидывая из архива всякие плагины, модули и тд.

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

Жаль нет возможности прикрыть мой комментарий от индексации :)

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

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

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

Теперь задумаемся о декомпозиции всего этого хаоса. Мы находим какую-то задачу, которую выполняет наш код (например какую функцию вызвать для обработки каждого конкретного запроса) и выносим это в отдельный объект. Отправка email-ов - отдельный объект. Весь SQL зашиваем в отдельный объект. Соединение с базой - объект. Пользователи - объекты. Все - объекты.

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

А все безхозные функции, которые не пренадлежат никаким объектам (например функции порождающие объекты) можно вынести в статические методы. Главное что бы статичесих переменных у нас небыло (ибо это те же глобальные переменные). И поменьше публичного ибо черт его знает что эти разработчики будут использовать. Причем "те разработчики" это вы завтра.

Вообщем писав всё время на процедурке, сложно перейти на ооп.

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

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

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

Фреймворки универсальны, а значит чистого ООП там быть не может. Во всяком случае нет ни одного фреймворка на котором стоит учиться ООП.

Есть хорошие упражнения на развитие понимания объектно-ориентированного проектирования. Например вот: https://habrahabr.ru/post/206802/

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

Или может подскажите книгу/сайт где пошагово в ооп написан какой-то проект, чтобы быстрее пришло понимание.

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

просто тупо изучать классы - нет никакого смысла, нужно садиться и решать какие-то задачи. А помимо самого фреймворка, обычно идёт как минимум 5-10 must-have расширений из коммьюнити, с которыми так же стоит ознакомиться.
Нужно понять lifecycle фреймворка - пройтись с xdebug по стеку выполнения рендеренига простой страницы.
Понять принципы роутинга, обработки запросов, конфигурации, авторизации. DI, событий. И сразу применять на практике. Yii2 не простой фреймворк для первого знакомства с фреймворками в принципе, хоть и достаточно с низким порогом вхождения, но у него много специфических плюшек, после которых перестроиться на другие фреймворки может быть тяжелее - в частности виджеты, поведения, и сама специфика конфигурации компонентов с магией

В основном это Web, "пэхэпэ" это тоже UNIX обычно, поэтому и системное администрирование и разработка нативных компонентов "пэхэпэ" туда входят, и Android тоже Unix-like, и там и там UNIX является как целевой платформой так и "родиной" для всех IDE, отладчиков и компиляторов, включая Java и Android NDK (тот самый GNU toolchain, который на Windows известен как MinGW).

И еще хотелось бы остаться на платформе до конца, а не переучиваться через 5-10 лет. Или лучше писать и изучать виндузятские продукты?

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

Со стороны исполнителя:
Нужно просить столько сколько как вам кажется стоит ваш труд. Я например прекрасно представляю себе что "сделай вебстраничку, ну че те" обернется (лично для меня) такими лишениями на которые я не соглашусь за те деньги которые мне предложат. Поэтому я фрилансером и не работаю. И называя сумму и срок ты связываешь себя жесткими обязательствами. И иногда потом заказчик может встать в позу и ты еще и дурак оказываешься, ведь он совсем не то хотел. Вплоть до суда который ты еще и проиграть можешь. Такие риски мне нафиг не нужны. Вот и как тут оценить проект. Один ссыкун как я, а другой смелый и увереный в себе готовывый пахать за любые деньги. На базаре, чтобы узнать "болевой порог" используют такой инструмент как торг. И еще мне кажется что чем опытнее специалист тем точнее он составит смету, учтет больше нюансов. И сумма такой точной сметы может на порядок отличаться от сметы составленной школьником-вебдизайнером.
Со стороны заказчика:
Нужно обьяснить обьем работ, составить план, только тогда можно будет получить представление о том труде который предстоит выполнить. Нужно так же понимать что вынуждая человека принять низкую ставку, можно неосознанно склонить его халтурно отнестись к работе. Можно взять и после первого макета дать неожиданную премию и тем самым мотивировать человека и создать о себе хорошее впечатление. Тут большей частью все от межчеловеческих отношений между сторонами зависит. Чем лучше они, тем больше усердия будет приложено. Качество оно субьективно. То что заказчику может показаться качественной профессиональной работой может оказаться проходной халтурой, на взгляд настоящего специалиста. Так и то что для заказчика неприемлемо может показаться исполнителю вполне нормальным решением. О каких тут можно говорить ножницах, это лоттерея как с покупкой подержанного автомобиля.

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

Тут сложный момент. Не рискну говорить за всех, но расскажу о своём личном опыте и опыте моего друга.
Мне на данный момент 33 и я всю жизнь проработал в офисе, никогда ни одного дня не фрилансил. Хотя понимаю, что во фрилансе больше денег. Но. Находясь в офисе ты находишься во взаимодействии с коллегами, а значит возможен очный обмен опытом, который, как ни крути, более интенсивен и более значим, нежели заочное общение на форумах. Просто потому что очно общаться проще и продуктивнее. Кроме того, для фриланса важна сильная самодисциплина: слишком много дома есть отвлекающих факторов и, лично мне, трудно находясь дома сосредоточиться на работе; далее, я разделяю среду обитания: на работе я работаю, а дома я отдыхаю. Ввиду таковой психологической установки мне трудно дома переключиться на рабочий режим. Ну и плюс к этому, о доходе в полмиллиона деревянных мне можно лишь мечтать, но меня деньги не интересуют как таковые, а потому мотивацией являются не деньги, а делание полезного и большого продукта, т.е. относительно маленькие проекты (с ограниченным сроком разработки и поддержки) меня не интересуют. Потому я всегда работал в ай-ти-шных интернет-компаниях над большими проектами, но никогда не рассматривал возможность трудоустройства в студию.

Далее про друга. Он фрилансит уже более 10 лет. И, когда начинал, то немного троллил на тему "а я вот не работаю на дядю". Спустя 5 лет, он понял, что всё-таки работает. Но только на много разных дядь.
Далее, есть момент в сложности самообразования: когда он не взаимодействует с большим коллективом таких же умных людей, то обмен опытом происходит гораздо слабее (писал выше), а потому знания необходимо самостоятельно подчерпывать из разных источников (хабр, англоязычные статьи, книжки, блоги умных разработчиков, и т.д.), но вот ведь вопрос: а когда это всё читать?, и каким образом это можно опробовать (если только не вести собственный(ые) опен-сорс проектики)? А значит, если нет жажды знаний, то варясь в зафиксированном стеке технологий начинается профессиональная стагнация. На что друг стал жаловаться мне 3 года назад: он понял, что очень много не знает, что появилось много нового и интересного, но он из-за того, что "просто решал прикладные задачи конкретного заказа" пропустил это всё. Было интересно за ним наблюдать, когда рассказывал ему про Git, DIC, модульное тестирование и т.д. --- то были удивлённые глаза ребёнка.
Кстати, о детях. Упомянул выше, что для фриланса нужна сильная самодисциплина. У него тоже было такое: когда начал фрилансить, то он уже жил с девушкой (ныне женой) и она никак не могла понять почему нельзя отвлекать: ну вот же он!, что такого, чтобы помочь что-нибудь сделать по дому по-быстрому (например помыть посуду или вынести мусор): работа ж не убежит?, а что такого, чтобы подойти и спросить что он хочет на ужин? В конечном итоге проблема решилась тем, что договорился с ней о том, что в период с 2-х часов дня до 6-ти часов вечера, она к нему даже близко не подходит, не спрашивает, не отвлекает и вообще старается не шуметь. Вроде, всё стало хорошо... пока не родился ребёнок, а вот там уже не объяснить ребёнку, что папа работает и не надо мешать. Поэтому всё закончилось тем, что он снял комнату в офисе и теперь каждый день, как и многие другие люди, ездит работать в офис.

Собственно к чему я это всё. И там и там есть плюсы и минусы. И каждый находит и занимается тем, что ему интересно, к чему больше лежит душа.
Но лично я с большой настороженностью отношусь к найму фрилансеров в штат компании лишь по одной причине: если недостаток знаний всегда можно восполнить общением и обучением, то вот с коммуницированием возникают (по моему опыту) значительные проблемы: нежеление (а иногда и саботаж) в части принятия используемого код-стайла; нежелание исправлять замечания, оставленные во время код-ревью; притаскивание сторонних говно-библиотек без необходимости; нежелание писать модульные тесты; а в отдельных случаях, даже эгоизм. При этом, уточню, что это относится не ко всем! Далеко не ко всем! Во всей моей практике такое было лишь дважды и то были молодые фрилансеры. Так же замечу, что опытные фрилансеры (ввиду большего жизненного опыта) гораздо спокойнее и легче вливаются в команду (такие тоже приходили и у меня был опыт работы с ними).

зачем они вообще нужны в работе, ведь всё хорошо и без них?

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

Словом, если вы разберетесь с принципами SOLID и GRASP, а так же в принципе с ООП (сокрытие состояния, обмен сообщениями между объектами разных типов), то паттерны будут появляться сами по себе.

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