Полгода самостоятельного изучения .NET – не повторяйте моих ошибок
Доброго времени суток! Меня зовут Ваьсен, я — начинающий backend разработчик, поставивший себе цель переучиться из экономиста в программисты с нуля. Обучение я начал в конце сентября прошлого года и на текущий момент выходит, что прошло ровно полгода с момента начала пути. Все нормально, я еще не вкатился и неизвестно, когда «вкачусь», я осознаю, что много чего осталось не изученным, в каких областях имею лишь очень поверхностные представления и просто продолжаю дальше учиться.
Так или иначе, разница между пониманием базовых вещей сейчас и тогда, на старте, огромная, и за столь небольшой временной промежуток успел набить пару шишек, получить какой-никакой опыт, понять в чем был не прав и могу предостеречь таких же попутчиков от повторения моих ошибок. Также данная статья является неким ответом на собственный вопрос из прошлой статьи, где я переживал за то, что имею так мало реализованных проектов, около пустой профиль на гитхабе и не знаю, как оценить свой прогресс. Заодно и советом начинающим, как эффективнее учиться, улучшать свои практические навыки программирования, понемногу заполняя свой гитхаб. Итак, какие ошибки я совершил за это время и в чем был не прав.
Roadmap
В самом начале, как и многие другие, наверное, я составлял свой маршрут. Есть много различных способов это визуализировать, немало написано статей и снято роликов.
Пример Roadmap
Так вот, главная ошибка заключается в том, что как бы вам не казалось в начале, родмап — это скорее ориентир, чем маршрут и не стоит к нему относиться слишком серьезно и категорично. По нему можно разве что подготовиться к какой-то викторине, где вы можете блистануть количеством известных вам технологий, нежели их пониманием и глубокими знаниями. Ну чисто формально конечно можно записать себе в портфолио работу с различными БД, если вы их подняли на какой-то ORM и написали пару крудов, но вряд ли эти знания впечатлят кого-то на собеседовании. Добавляем к этому то, что некоторые вещи взаимозаменяют друг-друга и выходит, что нужно какое-то нереальное количество проектов чисто для галочки в резюме и одному Ктулху известно, сколько на это нужно времени, и сомневаюсь, что это рациональная трата времени.
Лично у меня сложилась такая ассоциация. Представьте какой-то интерфейс абстрактный большой фруктовый сад, на котором вы можете собрать любой фрукт или ягоду. Вы заходите в него с пустыми руками, выход напротив вас, и не сказать, что он как-то очень далеко. Вам надо пройти через сад, чтобы на выходе у вас на руках было как можно больше фруктов, чтобы кто-то на выходе мог сделать из них полноценный напиток и продать. Какой именно? Да неизвестно, может морс, может коктейль, может компот. Какие именно нужны фрукты именно этому кому-то? Да тоже неизвестно, но главное, что их должно быть достаточное количество для изготовления какого-то напитка. Как вы наверное догадались, «столько это сколько?» тоже не имеет конкретного ответа. Сад же абстрактный, в конце концов. Забыл представить, этот кто-то — ваш потенциальный работодатель, который решает достаточно ли вы имеете с собой фруктов. Каждый фрукт — это какой-то стек, фреймворк, библиотека или какой-то подход, которым вы должны владеть в достаточном количестве. Вот и попробуйте унести в одних руках парочку арбузов, с десяток яблок, пригоршню крыжовника и т.д. Пока вы идете от куста к кусту, что-то роняете и теряете, при этом вам еще нужны лимоны, смородина, дыня. И дружелюбным надо быть еще, не забываем, софт скиллы прокачиваем, периодически выкрикивая из под куста о своих успехах, работодатель же хочет знать как вы принимаете то или иное решение, как мыслите, готовы ли к работе в команде…
Я думаю мысль вы уловили, что все не унесешь и как таковой дороги нет. Определите что чаще спрашивают, сколько нужно обычно и учите именно это, чем браться за все и сразу или идти только одним единственным маршрутом. И вторая мысль заключается в том, что некоторые вещи стоит понять и использовать раньше, чем они стоят в этой схеме. Самый очевидный пример — Dependecy Injection, оно же исходит от Dependency Inversion, оно исходит от SOLID, который исходит… из дома, который построил Джек. Если серьезно, то вы не сможете понять большую часть статей и чужого кода, если не усвоите что это за зверь такой, зачем он, что такое контейнер зависимостей. Поэтому сразу после изучения базы по языку, грызите DI пока не прокусите до состояния на автомате его использовать.
LeetCode
Моя ошибка была в том, что я очень долго откладывал решение литкод задач. Тут конечно найдется немалое количество людей с опытом, которые скажут, что литкод не нужен и им пригодился в работе ровно 0 раз и будут правы. Но они уже с работой и опытом, который гораздо ценнее, чем умение сортировать массивы и рекурсивно обходить деревья, а мы, начинающие, должны как-то компенсировать отсутствие такого достоинства как у них, чтобы как показать всем на собеседовании, чтобы все как ахнули и предложили оффер. Поставьте себя на место нанимающего, которому на вакансию бэка мидла-джуна приходит сотня откликов с± одинаковыми резюме, как отсеять наименее подходящих кандидатов? Вполне логично немного погонять по алгоритмам. По крайней мере я рассуждаю так, могу и ошибаться, естественно, но почему-то все чаще и чаще вижу в вакансиях требование на знание алгоритмов и структур данных, или упоминание о прохождении такого тестирования на собеседовании. Поэтому, поскольку обучаться с нуля довольно длительное мероприятие, а задач на литкоде много даже простых, стоит как можно раньше начинать их решать. Хотя бы решая по одной в день, через полгода у вас наберется уже солидная циферка и закрепленное руками понимание этих самых алгоритмов.
Я жалею, что долго не брался за литкод, начал решать с месяц назад только и имею маловато задач, но за этот месяц я уже понял, что:
— стал лучше разбираться в базовых алгоритмах и находить решение задач, что немножко так эмоционально радует и придает уверенности (напоминаю, что я экономист, и мое понимание алгоритмов и их эффективности отсутствовало изначально);
— улучшается качество кода и закрепляются примитивные навыки: с каждой решенной задачей все чаще расставляю адекватные отступы и пробелы, скобки, чего изначально не делал (и в первые проекты теперь больно смотреть), а также проще стало работать с LINQ выражениями, хотя несколько месяцев назад все эти лямбды казались какой-то внеземной материей;
— привыкаю к рутинным вещам: решил задачу, создал комит, добавил информацию о результатах, обновил репозиторий. Доходит до того, что когда физически не получалось решать задачи чувствовал какое-то напряжение, что уже два или три дня ничего нового не решал и не обновлял репозиторий. В общем появляется какой-то азарт, нацеленность на результат, что тоже положительно сказывается на учебе.
А если оставить в сторону связь собеседования и литкода, то для самого себя это отличный индикатор учебного прогресса, естественно в разумных пределах и без фанатизма, ведь цель получить новые знания и закрепить их, а не получить какую-то ачивку.
Ачивка
Чем больше вы решите задач, тем проще будет это делать в дальнейшем, начнете читать книги по алгоритмам, они потянут за собой новые вопросы, о ресурсах, об оптимизации и эффективности, которые в свою очередь приведут к таким вещам, как имутабельность, например.
Отклики на вакансии
Ладно, кого мы обманываем, отказы всегда неприятно получать и зачастую момент «Х» откладываем на потом. А когда речь заходит за собеседование, то как-то даже становится неловко заявляться на вакансии, где требуют год коммерческого опыта минимум и кучу чего еще знать и уметь использовать по назначению. Я планировал, что дойду сначала до какого-то уровня, пойму, что вроде неплохо стал разбираться в самых популярных вещах, глядишь — и отклонять будут реже. Но сейчас пришло осознание, что не стоило так делать и стоить спамить на все открытые вакансии и возможно чуть больше. Зачем? Чтобы хоть кто-то из этого списка дал бы вам тестовое задание. На текущем этапе получить хотя бы тестовое задание, это уже прогресс, потому что получаете какую-то конкретную задачу, которую надо реализовать, при этом надо это сделать обычно в ограниченные сроки и сделать максимально качественно. Ну ок, хотят проверить знание каких-то базовых вещей. И эту задачу (в идеале, конечно) кто-то будет проверять на результат и качество, и если сойдутся звезды, то получите фидбек. И это сейчас очень ценно и продуктивнее, чем любые собственные проекты, которые обычно никто не смотрит и не оценивает кроме вас самих (объективно и беспристрастно, естественно)
Бывалые разработчики скажут конечно, что не царское это дело решать тестовые задачи, но мы же в голове держим про достоинство и его размер, да? Поэтому мы сейчас ищем любую возможность получить какое-либо задание и стараемся решить его. Например недавно реализовал полноценный RESTful API сервис игры в крестики-нолики. Для кого-то это ерунда и элементарщина, я понимаю, но лично для меня было решить такую задачу, потому что это вызов и таких вещей не делал раньше.
Туда же относим все хакатоны, в которых есть требования, условия и дедлайн, привыкаем к нему с юных лет. Как пример, совершенно случайно узнал про вот такой хакатон, в котором принял участие. Только благодаря ему я узнал о такой вещи, как .NET Graph SDK и большую часть времени потратил на изучение его API и документацию, как зарегистрировать свое приложение в Azure и подключить Active Directory аутентификацию. Поэтому на само приложение и времени почти не осталось, и не придумал ничего умнее, чем сделать прототип почтового клиента (считай просто страничку с последними письмами и вложения к ним), который внутри себя вызывает ChatGPT и переводит письма на английский, а также голосовые вложения перегоняет в текст. Скажем так, прошел базовый экспресс-курс по Azure и получил опыт, на который и не рассчитывал изначально, а также плюс один еще проект в репозиторий.
Не игнорируйте активности, участвуйте везде, где можете, даже если не хватает знаний — получите по ходу движения поезда.
Выводы
Если у вас получилось дочитать эту статью до конца, то спасибо за уделенное внимание и очень надеюсь, что мои советы не окажутся вредными и помогут в дальнейшем обучении. Если подытожить, то тезисы вышли следующие:
Если составили дорожную карту разработчика, то используйте ее как ориентир, а не как строгое указание. И уделите внимание Dependecy Injection как можно раньше.
Начните как можно раньше решать задачи литкода. Сохраняйте результат решения себе в гитхаб, так вы сможете отслеживать свой прогресс, что будет придавать вам стимул продолжать учиться.
Откликайтесь на вакансии, даже если не проходите по требованиям. Ваша цель — получить тестовую задачу, попрактиковаться в решении задач. И участвуйте в хакатонах, они дают бесценный опыт на начальном этапе и пополняют ваш гитхаб профиль.
Дополнительно хотел сообщить, что открыт к любым проектам и предложениям, ищу опыт бэк разработчика. Вы фронт с классной идеей? Пишите, буду раз сделать какой-нибудь проект на несколько человек. У вас есть какая-то задачка, которую можете на кого-то спихнуть? Супер, будет очень интересно попробовать свои силы.
