Доброго времени суток! Меня зовут Васьен, я – начинающий backend разработчик, поставивший себе цель переучиться из экономиста в программисты с нуля. Обучение я начал в конце сентября прошлого года и на текущий момент выходит, что прошло ровно полгода с момента начала пути. Все нормально, я еще не вкатился и неизвестно, когда "вкачусь", я осознаю, что много чего осталось не изученным, в каких областях имею лишь очень поверхностные представления и просто продолжаю дальше учиться.

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

Roadmap

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

Пример Roadmap
Типичный маршрут ASP.NET Core разработчика (отсюда). Мне кажется можно стать уверенным мидлом, не трогая и половины из этого
Типичный маршрут ASP.NET Core разработчика (отсюда). Мне кажется можно стать уверенным мидлом, не трогая и половины из этого

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

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

Я думаю мысль вы уловили, что все не унесешь и как таковой дороги нет. Определите что чаще спрашивают, сколько нужно обычно и учите именно это, чем браться за все и сразу или идти только одним единственным маршрутом. И вторая мысль заключается в том, что некоторые вещи стоит понять и использовать раньше, чем они стоят в этой схеме. Самый очевидный пример — Dependecy Injection, оно же исходит от Dependency Inversion, оно исходит от SOLID, который исходит... из дома, который построил Джек. Если серьезно, то вы не сможете понять большую часть статей и чужого кода, если не усвоите что это за зверь такой, зачем он, что такое контейнер зависимостей. Поэтому сразу после изучения базы по языку, грызите DI пока не прокусите до состояния на автомате его использовать.

LeetCode

Моя ошибка была в том, что я очень долго откладывал решение литкод задач. Тут конечно найдется немалое количество людей с опытом, которые скажут, что литкод не нужен и им пригодился в работе ровно 0 раз и будут правы. Но они уже с работой и опытом, который гораздо ценнее, чем умение сортировать массивы и рекурсивно обходить деревья, а мы, начинающие, должны как‑то компенсировать отсутствие такого достоинства как у них, чтобы как показать всем на собеседовании, чтобы все как ахнули и предложили оффер. Поставьте себя на место нанимающего, которому на вакансию бэка мидла‑джуна приходит сотня откликов с +‑ одинаковыми резюме, как отсеять наименее подходящих кандидатов? Вполне логично немного погонять по алгоритмам. По крайней мере я рассуждаю так, могу и ошибаться, естественно, но почему‑то все чаще и чаще вижу в вакансиях требование на знание алгоритмов и структур данных, или упоминание о прохождении такого тестирования на собеседовании. Поэтому, поскольку обучаться с нуля довольно длительное мероприятие, а задач на литкоде много даже простых, стоит как можно раньше начинать их решать. Хотя бы решая по одной в день, через полгода у вас наберется уже солидная циферка и закрепленное руками понимание этих самых алгоритмов.

Я жалею, что долго не брался за литкод, начал решать с месяц назад только и имею маловато задач, но за этот месяц я уже понял, что:

  • стал лучше разбираться в базовых алгоритмах и находить решение задач, что немножко так эмоционально радует и придает уверенности (напоминаю, что я экономист, и мое понимание алгоритмов и их эффективности отсутствовало изначально);

  • улучшается качество кода и закрепляются примитивные навыки: с каждой решенной задачей все чаще расставляю адекватные отступы и пробелы, скобки, чего изначально не делал (и в первые проекты теперь больно смотреть), а также проще стало работать с LINQ выражениями, хотя несколько месяцев назад все эти лямбды казались какой‑то внеземной материей;

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

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

Ачивка

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

Отклики на вакансии

Ладно, кого мы обманываем, отказы всегда неприятно получать и зачастую момент «Х» откладываем на потом. А когда речь заходит за собеседование, то как‑то даже становится неловко заявляться на вакансии, где требуют год коммерческого опыта минимум и кучу чего еще знать и уметь использовать по назначению. Я планировал, что дойду сначала до какого‑то уровня, пойму, что вроде неплохо стал разбираться в самых популярных вещах, глядишь — и отклонять будут реже. Но сейчас пришло осознание, что не стоило так делать и стоить спамить на все открытые вакансии и возможно чуть больше. Зачем? Чтобы хоть кто‑то из этого списка дал бы вам тестовое задание. На текущем этапе получить хотя бы тестовое задание, это уже прогресс, потому что получаете какую‑то конкретную задачу, которую надо реализовать, при этом надо это сделать обычно в ограниченные сроки и сделать максимально качественно. Ну ок, хотят проверить знание каких‑то базовых вещей. И эту задачу (в идеале, конечно) кто‑то будет проверять на результат и качество, и если сойдутся звезды, то получите фидбек. И это сейчас очень ценно и продуктивнее, чем любые собственные проекты, которые обычно никто не смотрит и не оценивает кроме вас самих(объективно и беспристрастно, естественно)

Бывалые разработчики скажут конечно, что не царское это дело решать тестовые задачи, но мы же в голове держим про достоинство и его размер, да? Поэтому мы сейчас ищем любую возможность получить какое‑либо задание и стараемся решить его. Например недавно реализовал полноценный RESTful API сервис игры в крестики‑нолики. Для кого‑то это ерунда и элементарщина, я понимаю, но лично для меня было решить такую задачу, потому что это вызов и таких вещей не делал раньше.

Туда же относим все хакатоны, в которых есть требования, условия и дедлайн, привыкаем к нему с юных лет. Как пример, совершенно случайно узнал про вот такой хакатон, в котором принял участие. Только благодаря ему я узнал о такой вещи, как.NET Graph SDK и большую часть времени потратил на изучение его API и документацию, как зарегистрировать свое приложение в Azure и подключить Active Directory аутентификацию. Поэтому на само приложение и времени почти не осталось, и не придумал ничего умнее, чем сделать прототип почтового клиента (считай просто страничку с последними письмами и вложения к ним), который внутри себя вызывает ChatGPT и переводит письма на английский, а также голосовые вложения перегоняет в текст. Скажем так, прошел базовый экспресс‑курс по Azure и получил опыт, на который и не рассчитывал изначально, а также плюс один еще проект в репозиторий.

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

Выводы

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

  1. Если составили дорожную карту разработчика, то используйте ее как ориентир, а не как строгое указание. И уделите внимание Dependecy Injection как можно раньше.

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

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

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

Комментарии (22)


  1. ShadowMaster
    00.00.0000 00:00
    +21

    Изучив базовые вещи нужно что-то начинать писать. Потом писать что-то полезное для себя или для кого-то. Знания программирования приходят с практикой. Знания всех фреймворков не нужны, все равно их не изучить все, да и с новыми версиями вносятся изменения, иногда меняя вообще весь фреймворк. Главное знание технологий в общих чертах, какие есть известные фреймворки, для чего применяются и их достоинства/недостатки относительно друг друга. Книжки про архитектуру и паттерны нужно читать не сразу, а после некоторой практики, когда уже будет некоторая боль отладки и рефакторинга плохо написанного кода.

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


  1. ShadowMaster
    00.00.0000 00:00
    +21

    Изучив базовые вещи нужно что-то начинать писать. Потом писать что-то полезное для себя или для кого-то. Знания программирования приходят с практикой. Знания всех фреймворков не нужны, все равно их не изучить все, да и с новыми версиями вносятся изменения, иногда меняя вообще весь фреймворк. Главное знание технологий в общих чертах, какие есть известные фреймворки, для чего применяются и их достоинства/недостатки относительно друг друга. Книжки про архитектуру и паттерны нужно читать не сразу, а после некоторой практики, когда уже будет некоторая боль отладки и рефакторинга плохо написанного кода.

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


    1. s207883
      00.00.0000 00:00
      +3

      Ещё для отслеживания прогресса вполне подойдёт гит. Открыл свой код трехмесячной давности (чем больше опыта, тем дальше надо откатиться) и посмотри на него. Если он хуже, значит есть рост.


      1. Vasjen Автор
        00.00.0000 00:00

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


    1. Vasjen Автор
      00.00.0000 00:00

      Спасибо за комментарий! Я с ним полностью согласен и судя по по плюсам, не я один. Я его закрепил наверху, как наставнический. Надеюсь, вы не будете против.

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


      1. belirofon
        00.00.0000 00:00

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


    1. HerrDirektor
      00.00.0000 00:00

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


  1. sergs79
    00.00.0000 00:00

    опыт не приходит без ошибок, поэтому самый лучший выбор - это не бояться их повторить


  1. casuss
    00.00.0000 00:00
    -1

    Меня зовут Ваьсен

    Как правильно произносится Ваше имя?


  1. JohnRambo
    00.00.0000 00:00
    +1

    Мне кажется что для того чтобы начать работать программистом ты делаешь слишком много лишних телодвижений, распыляешься. А надо то всего-то прочитать книжку чтобы понять базовые вещи, потом придумать себе проект и делать его. Что-то реальное желательно. Это полезно, т.к. опыт и понимание приходит только с практикой. И большинство людей прекрасно понимают, что если джун без опыта про всё читал и про всё слышал, хто вообще не факт что он хоть что-то может. Бесплатная идея для своего проекта - напиши торгового робота для биржи. Опыт + заодно проверишь гипотезы о "халявном" заработке на бирже.


    1. Vasjen Автор
      00.00.0000 00:00

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

      Бесплатная идея для своего проекта - напиши торгового робота для биржи.

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


      1. JohnRambo
        00.00.0000 00:00

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


  1. Clutchmeister
    00.00.0000 00:00

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


  1. Ainyru
    00.00.0000 00:00
    +1

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


  1. stanlyzoolo
    00.00.0000 00:00

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


    1. Vasjen Автор
      00.00.0000 00:00

      Боты есть, с них и начинал практику. Один покупал игры через турецкий аккаунт, пока майкрософт не прикрыл лавочку, другой парсит тысячи страниц с одного сайта, проверяет цены и присылает уведомление в телеграм. Работает отлично.

      Если считать это за коммерческий опыт, то выходит, что он у меня оказывается есть =)


  1. DaneilDem
    00.00.0000 00:00

    Какой у вас хороший Roadmap, так всю прекрасно структурировано. Сам уже больше 10 лет в NET, но часть технологий/сервисов вижу впервые


    1. Vasjen Автор
      00.00.0000 00:00

      Это не мой роадмап, взял из репозитория гитхаб, вроде и ссылку указал. У меня он гораздо проще и скромнее.


    1. berkot
      00.00.0000 00:00

      хех, больше 20)

      но тоже кое что вижу первый раз..


      1. a-tk
        00.00.0000 00:00

        Повторите попытку лет через 5 :)


  1. suwakomoria
    00.00.0000 00:00
    +1

    Интересная статья - я сам начал свой путь в современном .NET в декабре 2022, но до этого имел крайне ограниченный опыт в IT (эникейщик, 3 года, до этого учился на считающейся IT-related специальностью, где шарпом пользовался как основным языком с 2 по 4 курсы). И да, с бОльшинством проблем/особенностей из статьи я сталкивался или сталкиваюсь прямо сейчас.

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

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

    Отклики на вакансии с целью получить тестовое - хороший совет. Сам за 55 откликов (месяц, может, чуть больше откликался с сопроводительными, искал удалёнку по РФ и очную в городе, где живу) получил только одно тестовое (RESTful API интернет-магазина со Swagger, кэшированием и авторизацией), но это было хорошей практикой.

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


  1. a-tk
    00.00.0000 00:00

    Для полноты картины не хватает указания технологий и фреймворков, которые за последние 10 лет стали историей (OWIN тот же), и того, что в этом списке есть, что станет историей через 5 и 10 лет.

    И да, веб - это далеко не весь дотнет.


  1. dimchik_b
    00.00.0000 00:00

    Пока вы изучаете программирование, вы же где-то учитесь/работаете, да? Вот и подумайте, какую программу вы можете написать, которая облегчит, автоматизирует вашу работу. Можете предложить эту услугу вашим друзьям, родственникам. Бесплатно. Хотя даже символическая оплата дисциплинирует. Так появится опыт реальных проектов, взаимодействия с заказчиком. А сам факт ведения подобных проектов зачтется как инициативность.