Привет, Хабр! Меня зовут Андрей и я программист. Как и многие, в свободное время я занимаюсь разработкой своих 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. А для кого ваше портфолио?
К сожалению, в самом начале карьеры я не уделял этому никакого внимания. Если уж и собирать портфолио, то оно должно быть направлено на ту сферу, в которую вы хотите устроиться.
Посмотрите, например, как это делают художники – есть много материалов на эту тему. Если ты хочешь рисовать комиксы, как минимум странно добавлять в портфолио фото пейзажей, написанных маслом.
Надеюсь, было интересно и полезно. В самом конце хотел бы провести небольшой опрос:
