У всех это было: учишь какой-то язык, штудируешь один учебник за другим — и ничего. Тогда начинаешь сомневаться: «это слишком сложно», «программирование, наверное, не для меня». Уверен, это чувство вам знакомо.
Меня самого недавно настигла эта напасть: мне — уже неплохо освоившемуся младшему PHP-разработчику — вдруг захотелось слегка глубже изучить Python, особенно Django.
Поискав в Интернете, я нашел чуть ли не идеальное руководство: достаточно сложное, чтобы было интересно, но и не слишком перегруженное.
Там предусматривалась работа над проектом, и мне понравился его конечный внешний вид. Казалось даже, что это будет достаточно интересно, чтобы добавить к моему постоянно растущему портфолио.
Однако осилив 80% руководства, я начал сомневаться. Я просмотрел видео и вручную переписал весь код. У меня был отличный проект, который можно показать другим. Так почему же мне казалось, что за все это время навыков у меня не прибавилось?
Переведено в Alconost
Несколько недель я по вечерам работал с этим руководством, и в итоге у меня был красивый законченный проект. Но даже тогда мне все еще не казалось, что я узнал достаточно, чтобы воспроизвести этот проект без руководства. А тогда разве можно использовать его в портфолио?
И вообще, впечатлит ли проект в портфолио, который выглядит и работает так же, как и у всех остальных, кто делал его по руководству? Ведь в нем и код точь-в-точь, как в GitHub-профиле автора руководства…
Показал ли я хоть какие-то собственные навыки, кроме умения следовать пошаговым инструкциям?
Понимаете, изучать туториалы — это замечательно, ведь вы приобретаете новые навыки. Но если ограничиться только ими, не получится научиться тому, без чего не стать успешным разработчиком (даже младшим). Я говорю вот о чем:
- планирование и организация проекта;
- правильный выбор инструментов для данной бизнес-задачи;
- исследование собственных проблем и поиск их решения;
- разрешение проблем, неизбежно возникающих во время разработки.
Руководства — хороший способ сходу взяться за новую область.
Это вам говорит 29-летний бывший сантехник, который сегодня работает на должности младшего разработчика в компании-разработчике ПО. Сменить род занятий я решил около 12 месяцев назад.
Как и большинство новоиспеченных программистов, я начал проходить обычные курсы, а затем изучать более продвинутые руководства. Основное внимание я уделял изучению PHP (единственный язык, о котором я хоть что-то слышал, когда начинал). Довольно быстро я изучил основы синтаксиса и его применение.
За 9 месяцев я прочел достаточно руководств и получил достаточно знаний и мотивации, чтобы убедить местную софтверную компанию дать мне возможность поработать у них. (Подробнее о том, как я убедил работодателя рискнуть взять меня и платить мне за то, что я буду учиться программировать, можно почитать здесь.)
В конечном счете, предложить свою кандидатуру и устроиться на работу за такое короткое время мне помогло то, что я мог показать реальные примеры сделанных проектов. Говоря о проектах, я подразумеваю СОБСТВЕННЫЕ проекты — а не то, что было скопировано из руководств.
Руководства помогут начать, но дальше нужно делать собственные проекты.
Не поймите меня неправильно: руководства — это здорово, особенно для начинающих, когда нужно изучать основы. Понятно, что качество и уровень объяснений в туториалах бывают очень разные. Но если проходить руководства одно за одним, это само по себе не превратит вас в специалиста.
Нужно создавать собственные проекты. Изучив синтаксис и разобравшись в основах применения выбранного языка, нужно — повторюсь — начинать свои проекты, без мудрых подсказок из учебника под рукой.
Обычно, когда я это говорю, мне отвечают: «Но я понятия не имею, что писать».
Ну так никто не ждет, что вы сделаете что-то крутое. У вас, скорее всего, даже нет нужных навыков — даже если стоящая идея есть.
Вот список из 500 проектов, за которые можно взяться, — там есть и примеры решений.
Можно создать что-то вроде блога, например. Да, есть тысячи руководств, в основе которых — создание блога. Возможно, в одном из них вы даже копировали код раньше. Такой проект может и не очень впечатлять, но…
Сделайте СОБСТВЕННЫЙ блог. Прежде чем браться за код, сядьте и распишите необходимые шаги, а также функции, которые будут у блога. Разберитесь, что вам нужно, и в соответствии с этим выберите, какие языки и фреймворки будете использовать. Узнайте, как установить необходимые инструменты и самостоятельно настройте среду разработки. А когда столкнетесь с проблемой или не сможете разобраться в какой-то функции, погуглите и выберите лучшее решение.
Сделайте это — и вы узнаете в 10 раз больше, чем после какого бы то ни было руководства.
Сделайте это — и один такой проект в вашем портфолио будет стоить двадцати проектов по туториалам.
Чтобы заинтересовать своим резюме работодателей, вам может понадобиться что-то еще в портфолио, но это зависит от сложности выбранного проекта. Возможно, ваш код и не будет самым лучшим, но это ВАШ код: вы сможете объяснить каждую его строчку и рассказать, как и почему вы приняли решения, реализованные в проекте.
При этом вы покажете, что умеете управлять проектом, работать самостоятельно, приобретать новые знания по мере необходимости и создавать конечный продукт. Вы овладеете несколькими ценными навыками, которые смогут заинтересовать потенциального работодателя.
Если уже год или даже полтора вы учитесь и еще не нашли работу или вам кажется, что вы не готовы, — не унывайте. И не сдавайтесь. Не нужно думать, что вам придется выложить тысячи долларов на какие-нибудь «волшебные» курсы — просто начните собственный проект, и вы удивитесь тому, насколько быстро вы вырастете как разработчик!
Все больше и больше людей устраиваются на работу сразу после freeCodeCamp — вероятно, этому как раз и помогает сделанный там упор на обучение по реальным проектам.
В конце каждого модуля рассказывается о соответствующих проектах. Затем обучающемуся предлагается найти собственные решения.
Думаю, freeCodeCamp выпускает отличных разработчиков именно благодаря тому, что там никто не держит за ручку.
Поделитесь собственным опытом обучения в комментариях?
О переводчике
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией приложений, игр и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов, перевод технических текстов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
Подробнее: alconost.com
Комментарии (29)
Cyberneticist
06.07.2017 11:16+4ставь + если узнал на постере статьи быстрый обратный квадратный корень по методу Джона Кармака ;)
samodum
06.07.2017 11:42+1Тоже зашёл про это написать :)
https://en.wikipedia.org/wiki/Fast_inverse_square_root
nikkonrom
06.07.2017 16:44+1На самом деле это не его метод, он был разработан в Silicon Graphics.
Cyberneticist
06.07.2017 17:32это правда, но свою популярность он получил как раз как «метод Кармака» и под этим именем он чаще всего и известен в среде программистов.
Дело в том, что весь код SGI (как минимум до создания на базе урезанной IrisGL открытой библиотеки OpenGL, но это уже закат силиконов) был закрытым, а Джон наоборот, свои движки после достижения ими определенного коммерческого успеха всегда выкладывал под открытыми лицензиями. Соответственно, программисты и знакомились с ним в основном читая исходные коды Quake, и соответственно, автоматически ассоциировали его с Кармаком и компанией ИД
tmin10
06.07.2017 12:20Логично, просто копипаста кода из руководства не требует понимания работы. Смотришь на код: вот это вроде понятно, это тоже, можно переписать к себе. А как нужно будет отойти от шаблона, то возникают новые проблемы и неспособность из решить.
Поэтому нужно поставить цель в написании своего проекта, со соими целями и задачами. И тогда, решая реальные проблемы, появляются знания. А проект потом можно добавить к портфолио, его будет не стыдно показать другим людям.
marcor
06.07.2017 14:45Я даже где-то читал, что вместо копипаста кода надо его перенабирать вручную. Как раз типа, понимание работы, глубже вникаешь и точнее запоминаешь.
Оригинальная точка зрения, но кому-то, быть может, подходящая.
А по поводу выбора проекта всё просто: огромное количество функционала, нужного — по крайней мере мне в повседневной жизни — не реализовано. Собственно, я так и начал писать код.
Электронное фортепиано с неБаховским строем, парсер нот из pdf в midi, кастомный скаффолд трёхслойки, большие числа и так далее.
И у каждого из нас есть программки, которые вроде бы и мелкие, но которые так хочется иметь под рукой. Их и надо разрабатывать в первую очередь, имхо.Eldhenn
06.07.2017 15:21+2Вместо набора вручную надо решить задачу «сделать так же, но с перламутровыми пуговицами».
vmm86
06.07.2017 12:20+1По правде сказать, документация у Django структурирована не совсем удобно для изучения — один и тот же сегмент фреймворка описывается с разной степенью детализации в разных разделах сайта.
Но, конечно, это не отменяет упорства в изучении вместе с практикой.
Py7h0n
06.07.2017 16:44Еще меня как новичка вводил в заблуждения начальный туториал где сначала решается задача одним методом а потом говорится что вот лучше делать так на шагах где главная тема совсем не та. Потом когда ищешь как правильно делать нужно копаться среди всех страниц выискивая подходящий пример. Хотя может это и к лучшему, заставляет выучить получше с первого раза чтобы потом не копипастить методы а обдуманно их использовать.
AnneSmith
06.07.2017 16:44+1сразу надо делать свой проект, причем не для портфолио, а на продажу или для зарабатывания денег
если язык/технология вас заинтересует, то вы всегда можете почитать мануал уже совсем другими глазами, а если нет, то этого уровня знаний будет достаточно, чтобы указать его в вашем skill set
pm_wanderer
06.07.2017 17:42+1Я бы сравнил туториалы и множество книг — с инструкциями по строительству дома.
Информации о строительстве стен, кровле и прочим штукатурным работам в избытке, но вот как правильно заливать фундамент и готовить почву под него — практически нет инфы.
Паттерны проектирования описаны, но мало уделено внимания тому, когда и какой надо использовать. Про юнит тесты написано много книг, но как писать тестирумый код — снова умалчивается.
Самый короткий и наглядный пример этого безобразия запомнился мне из одной книги по js:
«Оператор delete используется когда вам надо удалить свойство из объекта»
И ни слова о том, зачем и для чего это применяется))
С курсами тоже самое — «мы учим синтаксису и фреймворкам — копипастите код очередного todo-app, улыбайтесь и ставьте лайки».
Печально все это ((
bro-dev
06.07.2017 19:23По своему опыту, способов как то сильно ускорить обучение не существует. А единственный способ учиться чему то это много делать это.
Главная проблема которая возникает в ходе обучение это то что люди основном не терпеливы, учителя решают именно это проблему.
DarkOrion
06.07.2017 19:53+1Никогда не понимал как люди что-то учат по туториалам или книгам. Дали задачу — запили или умри.
shushu
06.07.2017 23:40Для ознакомления с новой технологией — самое оно, особенно если документация этой самой технологии не очень.
Для примера тот же питон, его не очень просто осилить читая одну документацию.
А вот после ознакомления с синтаксисом и базовыми практиками по туториалу можно уже и в документацию смотреть.
plartem
07.07.2017 00:35+1Просто не факт, что нагугленный тобой путь будет правильным/оптимальным. Ошибаться не стыдно, но все же.
Xlab
07.07.2017 15:11А он и не должен быть правильным или оптимальным, он должен работать. 10 раз напишете неоптимальный, но работающий код, на 11 раз задумаетесь и сделаете идеально. Во всяком случае у меня как-то так работало.
plartem
07.07.2017 20:45грубо говоря вы можете даже не подозревать о какой-то возможности языка/фреймворка, пока не встретите ее в чужом коде/каком-то туториале и самому до этого дойти будет сложновато.
eoffsock
07.07.2017 17:35Когда я первый раз пришел на работу разработчиком, мне выдали портянку Pl/SQL-кода и сказали: «Надо, чтобы работало так-то». Ничего, разобрался.
Потом на той же работе первый раз в жизни увидел очень древний перловый код, на нем какие-то отчеты строились. Тоже ничего, разобрался и даже ничего не сломал.
Практика — она такая, полезная штука.
Еще интересную байку про практику вспомнил. У меня первый ноутбук был Dell какой-то там, на P133 проце, большой черный кирпич. Стояла там 98-я. А еще там был заменяемый флопик/дисковод в одном гнезде, причем на горячую менять нельзя. Хочешь читать диски — вырубай ноут, выдергивай флопик, ставь дисковод.
В какой-то момент винда слетела. BIOS с диска грузиться не умеет, только с дискеты. Соответственно загрузочную дискету я загрузить могу, а дальше никак. Ничего, придумал решение — грузился с дискеты, с другой дискеты грузил NC, переносил руками загрузочные файлы на диск, правил пути, загружался уже с диска, ставил систему.
Кажется, именно с той поры я и увлекся компами и всем сопутствующим.
dcheremnov
07.07.2017 07:35Язык программирования — обязательное условие для работы программистом.
Но как говорит начальник отдела (и я с ним полностью согласен) при приеме юниоров — главное умение работать в команде и иметь базовые навыки по процессу разработки.
А для этого нужны ряд компетенций
http://it-check-list.asvoip.com
mike_y_k
07.07.2017 09:58-1Сейчас уже очень сложно оценить статью и комментарии.
Начиналось все очень давно, один из учебников — знаменитая книга Клары Джермейн, и к ней очень много практики ;). В итоге дизассемблирование кусков кода спокойно делали с карандашом на распечатках или уже позже с экрана.
Когда число языков перевалило за десяток процесс превратился в рутину. Читаем документацию, ставим задачи, реализуем их, анализируем результат, читаем образцы чужого кода, анализируем его, на основе сделанных выводов оптимизируем решения,…
eugenk
07.07.2017 09:59+1Забавно… Только сегодня(точнее уже вчера) об этом зашла речь(https://habrahabr.ru/company/wrike/blog/330900/#comment_10300708)… Согласен с мужиком на все 146%. У меня с этим всё ещё экстремальнее. Я вообще не могу ничего изучить, если под изучаемый предмет нет абсолютно конкретной и реальной задачи. Причём не для того чтобы показать в портфолио какому-то дяде, а исключительно для себя. Например я так и не смог изучить хаскель, хотя и пытался. Ну просто не было под него никакого реального проекта! И сейчас нет. Зато сейчас с успехом и с удовольствием изучаю скалу, считающуюся значительно более сложным языком, делая на ней проект, на котором собираюсь зарабатывать. Хотя точнее будет сказать делаю проект, параллельно с изучением скалы. Серьёзный недостаток тут в том, что на работу Вас почти всегда принимают как уже готового специалиста и начальство просто не даст Вам участвовать в проекте на чем-то чего Вы не знаете, но хотели бы изучить. Поэтому во-первых учиться приходится «без стипендии». Во-вторых смена сферы деятельности чаще всего сопряжена со сменой работы. Мне тут правда немного легче. Сейчас сижу без работы и сам выбираю чем мне заниматься.
marenkov
07.07.2017 17:05+2Пошаговый туториал — это не обучение, а экскурсия по новой технологии. Вы проходите по ней, осматриваетесь, и принимаете решение хотите ли с ней связываться.
sarbash75
08.07.2017 00:19Самая большая проблема при любом обучении — это наличие времени на это самое обучение.
Но при достаточной мотивации, возможно всё, ну, или почти всё.
Потом, что касается туториалов, Practice makes perfect. Софт эволюционирует, туториал может просто устареть, и написанное в нём потерять свою актуальность. И это может случиться намного быстрее, чем вам это кажется.
То же самое касается документации. По личному опыту знаю, что то, что написано в документации, и то, что в реальности, не всегда совпадает с вашим пониманием прочитанного.
Нередко, после прочтения доков, начинаешь делать, и, внезапно, понимаешь, что ничего не понимаешь, и всё на самом деле не так, как понималось и думалось.
Так что, что касается разработки софта, тут без практики вообще совсем никак.
Тупая копипаста ничего не прибавит в голове, поэтому просто бессмысленна.
Успехов Вам в освоении новых горизонтов!
Последние несколько месяцев я постоянно только этим и занимаюсь.
Чтобы работать в софтверной компании, за три месяца мне пришлось с нуля усвоить материал по нескольким технологиям. Я ещё продолжаю.
Almet
Помимо чтения туторилов необходима практика! Ставишь себе задачу — и постепенно ее выполняешь, обращаясь к тем или иным источникам информации при возникновении трудностей. Можно даже на каком-нибудь IT-форуме выполнять лабораторные задания, которые так любят размещать студенты в разгар сессии.
Areso
Лабы и реальная работа имеют очень маленькое пересечение.
Almet
Полностью согласен, но это хоть какое-то закрепление теории :)
maisvendoo
Такой способ лично мне кажется единственно верным