Как программисту изучать новые технологии: инструкция для новичков и сеньоров

Совет 1

Составьте план

Любой серьёзный проект без плана обречён на провал. А изучение новой технологии — проект более чем серьёзный, особенно для новичка.

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

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

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

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

Когда пройду курс и «набью руку» на учебных задачах, запущу проект на текущем рабочем месте. Понимаю, что такая возможность есть не у всех, но, как только вы освоили базу, нужно сразу искать работу за деньги. Так вы познаете всю боль коммерческой разработки и набьёте полезные шишки.

Совет 2

Найдите ментора или учителя

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

Вредный альтернативный совет: опубликуйте код на GitHub и напишите в Twitter: «Смотрите, какой классный код я написал»! Придёт 1000 человек, и все скажут, что вы не правы, объяснят, почему ваш код плохой, и параллельно отметят, что как личность вы тоже так себе. Грубовато? Да. Зато вы найдёте опытных разработчиков и получите самое подробное и крутое код-ревью в жизни, обещаю.

Совет 3

Найдите людей с аналогичной проблемой

Если нет опыта, объединитесь с другими ребятами и сделайте совместный проект. Находите людей, которые столкнулись с той же проблемой или изучают ту же технологию. Apes together strong.

Сейчас я заканчиваю учёбу в KIT — одном из самых сильных университетов Европы в области computer science. Однажды я проходил курс по парадигмам программирования — сложнейший предмет на пути студента KIT. В его рамках ​​пришлось изучать Haskell — да так, чтобы решать на нём любые задачи. Немного погрузившись в учебник, я понял, что ничего не понял. В то время я даже стримы в Java знал плоховато и был далёк от функционального программирования.

Тогда я решил скооперироваться с однокурсниками, которые тоже безуспешно бились с Haskell и функциональной парадигмой. Набралось 30 человек — примерно десятая часть курса. Мы собрались и начали решать задачи вместе: сначала каждый искал своё решение, а потом мы вместе разбирали, что у кого получилось. Так мы могли перенимать друг у друга приёмы, методы и логику мышления.

Задания были сложными. Например, рендеринг 2D-картинок в математическом пространстве. Мы должны были решить такую задачу минут за 20−30, но на практике получалось дольше. Решения из учебников и методичек не всегда очевидны, а чтобы разобраться в проблеме, нужно понимать ход мыслей. Вместе мы быстро разбирались с очень сложными математическими задачами, потому что у каждого есть своя суперсила — каждый из нас «щёлкает» свой тип вопросов и доступно объясняет решение остальным.

Совет 4

Найдите понятные книги и лекции

Пять лет назад я стал учить Java — свой первый «серьёзный» язык. В интернете мне посоветовали прочитать «Философию Java» Брюса Эккеля. Я пошёл в университетскую библиотеку, взял книгу на 1200 страниц, принёс домой, открыл и начал шумно втягивать носом воздух — уже с первой страницы я перестал хоть что-то понимать. Учебник начинался с абстрактных вещей: объекты, классы, полиморфизм и другие важные, но сложные понятия, которые пугают новичков. Книгу я закрыл и учиться по ней не стал.

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

С помощью видео я кое-что узнал о языке, но всё ещё не мог самостоятельно писать код. Тогда я нашёл ещё одну книгу, которую до сих пор считаю самым толковым учебником по Java для новичков — Head First Java O’Reilly.

Ещё одна замечательная штука для неспециалистов, далёких от компьютерных наук, — курс CS50. Его читают в нескольких университетах США и Европы, там классно подаются базовые понятия и сущности, связанные с кодом: переменные, алгоритмы и другие концепции вроде машины Тьюринга. Я смотрел его на видео несколько раз и всегда рекомендую практикантам или студентам, если они спрашивают, с чего начинать.

Совет 5

Много практикуйтесь

Вы должны писать много кода, причём не «в стол»: необходимо показывать его опытным разработчикам. Новичку критически важно проходить код-ревью, чтобы повысить свои скиллы. Кто-то должен сказать: «Друг, твой алгоритм слишком медленный. У тебя тут квадратичный, а задача быстрее решается с помощью линейного». Если вы чего-то не поймёте, вам подскажут хорошие источники по теме — так вы быстро вырастете. Это намного полезнее, чем писать код для себя и никому его не показывать.

Обязательно решайте задачи на Сodewars, LeetCode, Coursera и других сайтах. Можно начать с простых, потом перейти на те, что посложнее, и даже попробовать что-то из архива международных олимпиад. Это как тренировки в зале — чтобы был прогресс, нужно постоянно увеличивать нагрузку.

Простой пример — у меня есть ученик лет шестидесяти. Я помогаю ему с первыми шагами в разработке и дал несколько задачек из Head First Java. Он неоднократно повторял, что понял теоретический материал. И эта фраза для меня — как триггер. По ней я сразу понимаю: человек ничего не понял, ведь одно дело увидеть готовый код и понять, что он делает, и совсем другое — написать его самостоятельно.

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

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

Совет 6

Создавайте собственные проекты

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

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

Совет 7

Помогайте другим

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

Помогайте знакомым, людям в Twitter или отвечайте на вопросы на Quora или «Хабре». Заметьте, речь не о совсем простых задачах вроде «Эклипс не запускает программу хелп», а о чём-нибудь посложнее. Например, как настроить базу данных в конкретной ситуации, как оптимизировать такой-то код, как найти затаившийся в системе баг.

Совет 8

Не бойтесь просить помощи у коллег

Поделюсь маленькой историей. У меня на бэкенде был практикант, который мало знал Java и Python, — он находился в самом начале пути. Зато в DevOps тот парень был невероятно силён, потому что долгое время работал админом. Как-то раз я завис с настройкой пайплайна на одном микросервисе. И рассказал об этом своему практиканту за кофе. Он посмотрел на меня с удивлением и разложил всё по полочкам: что у меня не так с системой и как правильно сделать.

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

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

Участникам вашей команды важно знать, в чём вы профи, а что совсем не знаете. Только так можно эффективно распределить обязанности и ответственность. В общем, разработка — это не только про «покодить», но и про работу в команде, коммуникацию с окружающими.

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