Pet-проекты. Советы себе начинающему
Привет, Хабр! Меня зовут Андрей и я программист. Как и многие, в свободное время я занимаюсь разработкой своих Pet-проектов.
Для себя я писал мобильные приложения, игры на Unreal Engine, пробовал обучить нейросеть генерировать квесты и многое другое. Большинство проектов приносили мне удовольствие, самореализацию, рост. А некоторые я мог даже считать своим портфолио.
Но иногда бывало и такое:
— мне казалось, что я пишу «в стол»;
— кризис идей;
— нет сил и желания закончить хороший проект;
— «стыдно» показать свой проект, «да кому он нужен», «это не портфолио» и т.д.
Недавно я решил оценить прошлый опыт и оформить свой подход к работе с pet-проектами, чтобы они приносили пользу и повышали мотивацию, а не создавали выгорание. Вам же предлагаю это в виде списка небольших советов.
Совет №1. Ваш проект должен быть нужен именно вам.
Мне кажется, в последнее время существует некий «культ полезности». Многие считают, что любое действие должно быть направлено на результат и должно приносить пользу.
Типичный совет: «Подумайте, что полезного вы можете сделать»
Как по мне, сам факт того, что вы что-то делаете для себя и развиваетесь — уже полезно.
Примерно 7–9 лет назад, когда я был джуном, мне несколько раз на собеседованиях задавали очень хороший вопрос: «Для себя программы пишете?» Надо писать для себя. Если вы хотите принести пользу обществу, то это уже не хобби, а стартап (даже на добровольной основе). Если цель — заработать деньги, это уже бизнес. И в данных случаях подход к разработке должен быть другим.
Совет №2. Определитесь с тем, что ИМЕННО вы хотите сделать
Если ваш проект не на один день, предлагаю для себя выписать в свободной форме, что вы хотите получить. Несколько строчек с произвольной формулировкой: что пишу, почему, что хочу освоить и что буду использовать. Такое правило »5 Почему» на минималках. Мне помогает отсеивать совсем уж бредовые идеи, которые я не доделал бы никогда. К тому же, помогает не уходить сильно в сторону от первоначальной идеи (ведь всегда есть желание дополнительно «прикрутить» что-нибудь еще) .
Реальный пример. В 2019 году я решил для себя сделать англо-русский словарь на Xamarin. Как это можно оформить:
Хочу сделать англо-русский словарь под Android.
Конкретная проблема
Какую собственную проблему вы решаете делая этот проект:
Надо сохранять слова, которые я искал, для дальнейшего изучения / повторения.
Цель
Какова ваша личная конечная цель:
(как ни странно) Выучить слова.
Актуальность
Почему это актуально для вас прямо сейчас:
Учу язык, плюс всегда хотел попробовать мобильную разработку.
Достижимость
Почему вы уверены, что вы сможете достигнуть результата:
Немного фич, основной язык программирования уже знаю.
Мера
Что вы будете считать полным или частичным успехом:
Минимум: Я пользуюсь своим приложением.
Максимум: Опубликовано в Google Play.
Совет №3. Хотя бы некоторые ваши проекты должны быть завершенные.
Безусловно, какие-то проекты мы начинаем просто для обучения. Часть — это просто проекты выходного дня. Не обязательно каждый проект должен быть оформлен, опубликован, иметь Readme и прочее.
Но, хотя бы некоторые ваши проекты должны быть завершенными. Тем более, если вы используете новую для себя технологию.
Тот же пример из совета №2 я решил доделать на 100%, выложив его в Google Play. Даже несмотря на то, что его скачали всего 16 человек — мне было очень приятно. Осознание того, что вы что-то закончили на 100%, сильно повышает мотивацию, и ты по-настоящему считаешь это своим достижением. И, между прочим, сразу появляется много новых идей.
Совет №4. Помните про конечную цель вашего проекта.
Как продолжение прошлого совета.
Например, мне очень часто хочется сначала сделать простой прототип и только потом «причесывать» код и доделывать самое сложное. И порой с таким подходом и наступает выгорание. Увидев быстрый результат ты расслабляешься, а дальше просто лень разобраться со сложной темой. Проект забрасывается, падает мотивация, вплоть до депрессии.
Совет №5. Нормируйте время работы.
Писать на энтузиазме несколько недель по ночам может показаться классным. Но чаще всего после этого наступает усталость, и вы забрасываете проект на еще больший срок. Или просто со временем вам это надоедает.
Нужно контролировать время, которое вы уделяете проекту. Даже если вы безумно наслаждаетесь этим процессом, надо иногда себя останавливать. Очень часто, когда у меня менялись проект или технология на основной работе, я думал:
«О, круто, что-то новое, и у меня же еще пет-проект. Это же опыт х2!»
Только »Фиг Вам», как говорил Шарик. Через полгода интенсивной работы я начинал думать:
«А может ну его, этот код. Совсем… может лучше в другую профессию?» и т.д. Наши моральные ресурсы тоже ограничены, и нужно давать себе отдыхать.
А теперь несколько советов начинающим на тему портфолио.
Совет №6. Не придумывайте работу.
Когда твое портфолио — это «борьба с ветряными мельницами»
Только если на вашем текущем месте работы есть, что автоматизировать и оптимизировать. Лучше возьмите реальный кейс и разберите его (спросите знакомых, а если их нет — то хотя бы примеры заказов и проектов на фриланс-биржах).
Пообщавшись с начинающими разработчиками с курсов, я заметил, что некоторые для проекта в портфолио придумывают бизнес-сценарий. К чему-то это может привести?
Разработка ПО — это не только про код. Почти каждый интервьюер спросит вас, а какую задачу вы решали? К обсуждению вашего решения добавится еще и обсуждение вымышленного сценария (иногда не реального), что может либо:
— усложнить собеседование;
— повернуть в то русло, к которому вы не готовы.
Совет №7. А для кого ваше портфолио?
К сожалению, в самом начале карьеры я не уделял этому никакого внимания. Если уж и собирать портфолио, то оно должно быть направлено на ту сферу, в которую вы хотите устроиться.
Посмотрите, например, как это делают художники — есть много материалов на эту тему. Если ты хочешь рисовать комиксы, как минимум странно добавлять в портфолио фото пейзажей, написанных маслом.
Надеюсь, было интересно и полезно. В самом конце хотел бы провести небольшой опрос:
