Как найти пэт проект

Пет-проекты — еще одна возможность для джуна получить реальный опыт работы. Это собственные проекты, которые иногда становятся глобальными сервисами (например, Gmail и AdSense когда-то были пет-проектами), но чаще помогают в процессе саморазвития и закреплении изученного материала. Придумать идею для собственного проекта бывает не просто. Для вдохновения рассказываем о пет-проектах наших студентов: от аналога Trello до программы для интерактивного дисплея на клавиатуре.

Что такое пет-проекты

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

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

Для студентов

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

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

Для разработчиков

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

В некоторых крупных компаниях существует практика поощрения собственных проектов сотрудников. Например, введенное в 2004 году Google «Правило 20%» позволяло разработчикам тратить пятую часть рабочего времени на пет-проекты. Так появились Gmail и AdSence. Стоит отметить, что в случае с Google такая политика предполагала, что все разработки становятся интеллектуальной собственностью компании.

Где взять идеи для проекта

Универсальный ответ на этот вопрос — попробовать автоматизировать процессы или решить проблемы, с которыми приходится сталкиваться каждый день. Однако на практике поиск идей может оказаться не самой простой задачей.

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

Рустем Тарасевич, JS/TS-разработчик

В моем GitHub репозитории около 10 пет-проектов. Первые три — помидорный таймер, сервис для составления списков задач и приложение погоды — своего рода Hello, World в портфолио каждого начинающего фронтенд-разработчика. Не буду останавливаться на них подробно, а расскажу про более сложные проекты.

Чат для комьюнити. Упрощенный аналог чата комьюнити Хекслета в Slack, который я сделал в качестве четвертого, финального учебного проекта. Приложение представляет собой чат с входом по регистрации и отдельными комнатами для обсуждений. Сообщения в нем можно редактировать и удалять.

На проект я потратил больше двух недель — за это время успел разобраться в вебсокетах, интернационализации, кастомных хуках, Redux Tool Kit и другими технологиями.

Трекер задач. Идею для этого проекта я взял из книги Fullstack React with Typescript. На русский язык она не переведена, так что во время чтения подтянул английский до уровня B1B2.

Проект похож на доску Trello: это канбан-доска с возможностью перетаскивать задачи курсором (Drag and drop). Для реализации этого функционала я использовал библиотеку React-DND, а стэйт-менеджмент написал с помощью Redux Tool Kit, самостоятельно типизировал логику с помощью документации. Это потребовалась, поскольку в оригинале предполагалось реализовать приложение на чистом Redux.

В ходе проекта я также изучил библиотеку styled-components, которая позволяет  писать стили компонентов прямо в tsx-файле.

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

Читайте также:
Как сохранять фокус на протяжении всего обучения: советы от Хекслета

Иван Иванов, разработчик на С++

Свой первый проект я сделал около семи лет назад, когда самостоятельно учил C++. Тогда я купил игровую клавиатуру Logitech с черно-белым экраном и столкнулся с тем, что для нее доступно очень мало программ. Я решил сделать свою программу, которая будет выводить на экран сообщения из Skype (на тот момент главной платформы для общения геймеров, по аналогии с Discord) и позволит отвечать на них, не сворачивая окно с игрой.

Рядом с экраном находилось четыре кнопки: первую я использовал для того, чтобы открыть окно с сообщениями, вторую — для автопрокрутки. Третья кнопка перехватывала ввод с клавиатуры и перенаправляла его на экран клавиатуры, а четвертая — отправляла сообщение.

Для работы над проектом я изучил API Windows, которое использовал Skype, и API клавиатуры — это была библиотека на языке C, с которым я раньше не сталкивался. Нужно было разобраться, как подключать C-библиотеки и использовать их в программах, написанных на C++, и как работать с пиксельной черно-белой пиксельной графикой.

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

Константин Мамонтов, PHP-разработчик

Мой пет-проект — интернет-магазин, точнее, интернет-склад. Он не решал никакую конкретную проблему и всегда был некоммерческим. Его целью было закрепление знаний и поиск подводных камней при разработке подобных продуктов.

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

Этот опыт пригодился мне на собеседовании, которое благодаря курсам и проекту я прошел почти моментально, и во время выполнения тестового задания. В результате я нашел первую работу PHP-программистом на Laravel.

Никогда не останавливайтесь:
В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях

Привет! Меня зовут Артур Домбровский, и я наставник и соавтор курса «Java-разработчик» в Яндекс Практикуме. Зарабатываю на жизнь программированием уже более 7 лет, из которых больше трёх провёл в Amazon. Сейчас я — старший программист/тимлид в финтех-компании Wise. Последние пару лет плотно вовлечён в процесс найма, собеседую и джунов, и принципал-инженеров.

Хочу отметить, что всё сказанное ниже — моё личное мнение и не даёт инсайта о том, как на резюме смотрят эйчары. Но может помочь людям, которые начинают карьеру в бэкенд-разработке.

Какие пет-проекты делать, чтобы было легче найти работу?

Тема этой статьи родилась из вопроса, заданного на вебинаре одним из студентов. Я посоветовал не тратить на это время, хотя интернет забит рекомендациями и примерами портфолио.

Под пет-проектом мы понимаем некий самостоятельный, написанный кандидатом от начала и до конца сервис. Это может быть доска объявлений, to-do-лист, социальная сеть для фотографий котиков и т. д. При создании такого проекта требуется написать архитектуру приложения, реализовать её и, возможно, написать фронтенд-часть, а также задеплоить проект на сервер. В теории звучит прекрасно, но есть проблема.

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

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

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

Альтернатива пет-проектам

Мне, как интервьюеру, гораздо интереснее кандидаты с записью в резюме о контрибуции в open-source-проекты. Open source даёт кандидату весомые преимущества в глазах нанимающего менеджера:

Идеальное замещение реального опыта работы. Open source даже лучше реального опыта, потому что то, что делал кандидат, доступно для просмотра, а не скрыто в приватных репозиториях и под кипами NDA. Тот факт, что за этот код не заплатили, меня мало волнует.
Вне зависимости от размера вклада (а это может быть лишь пара строчек) сам процесс — именно то, чем будет заниматься новый разработчик в своей будущей команде. Нужно взять большой и сложный проект, разобраться в нём, внести изменения, протестировать, получить одобрение команды. Отсутствует только шаг релиза, но вряд ли свеженанятого начинающего разработчика допустят релизить код в продакшен без присмотра.

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

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

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

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

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

Обязательно включайте в резюме проекты с открытым исходным кодом. Это реальный опыт работы, просто за него не заплатили. С моей точки зрения, open source будет смотреться на порядок весомее, чем портфолио из очередных CRUD-сервисов.

Как выбирать проекты для контрибьюшена

Чтобы выбрать проекты, в которых можно поучаствовать, зайдите на GitHub в раздел Explore.

В Explore зайдите в раздел Trending Repositories и выберите в нём язык коммуникации и язык программирования, на котором написан проект, например Java.

Так вы отфильтруете популярные, активные репозитории, где контрибьюторы общаются на английском и основной язык самого репозитория — это Java.

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

Вот пример такого issue:

Также можно подписываться на топики по интересующим вас темам, инструкцию можно найти тут.

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

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

В open-source-проектах джуну важно показать максимальную самостоятельность. Пройдя весь этот путь, он покажет, что знает, что такое Git, умеет создать pull request и достаточно знает про Java, чтобы запустить проект и внести в него какие-то значимые изменения. А если он чего-то не знал, то самостоятельно нашёл решение. Это максимум, который я могу требовать от джуна.

К кому обращаться за помощью, если пишешь для open source

В open source довольно доброжелательное комьюнити. Если вы правильно задаёте вопросы, вам всегда помогут. Навык задавать вопросы — тоже важен для IT, но обладают им далеко не все. Половина моих студентов после четырёх месяцев объяснений всё ещё периодически загружает не текст исключения и описание проблемы, а сообщение: «Помогите, что делать?»

Правильно сформулированный вопрос в IT состоит из таких пунктов:

1. Описание состояния, которое вы пытаетесь достичь, например: «Пытаюсь библиотеку валидации ABC:1.2.3 заставить работать с фреймворком FooBar:3.2.1».
2. Перечисление, что вы для этого делали, — пошагово.
3. Описание, куда смотрели, что читали и пробовали.
4. В идеальном случае достаточное количество информации, чтобы проблему можно было воспроизвести.
5. Вопрос, какие шаги нужно предпринять дальше, чтобы приблизиться к решению.

Это и будет идеально заданный предметный вопрос. Если вопрос более абстрактного характера, то такой алгоритм тоже подходит, например: «Я смотрю на технологию A и технологию B. Мне кажется, что технология A имеет такие преимущества и недостатки, а технология B — такие, что я упускаю?»

Вопросы, заданные в таком формате, демонстрируют уважение к отвечающим:

• Избавляют от необходимости уточнять. Вы можете что-то упустить, но должны по крайней мере прилагать усилия, чтобы у отвечающего была полная информация. Человек может быть в другой временной зоне или ответить через неделю. Если ему надо переспрашивать, это увеличивает turnaround time до неприличия.
• Свидетельствуют о том, что вы не просто наткнулись на проблему и тут же подняли лапки. Вы копали по разным направлениям, у вас есть прогресс, и вам как минимум не нужно советовать то, что уже испробовано. Вы действительно потратили своё время и действительно в тупике.

Open source делает вас самостоятельной боевой единицей

С моей точки зрения (только с моей, не с позиции Amazon или Wise), джун — это самостоятельный разработчик, которому можно отдать на откуп компонент с довольно чётко прописанным ТЗ. А дальше, при минимальной помощи и поддержке от других членов команды, он должен довести работу до конца. Это человек, которому я могу сказать, в каком месте у нас баг, при каких условиях он появляется, и попросить решить. Джун сделает пусть не идеальное, но самостоятельное решение. Если не сделает, то это не джун, а человек, который ещё только учится.

Перейти из стадии «просто учится» в джуны можно как раз с помощью open source. Такие проекты — это доказательство, что человек стал самостоятельным. Следующей ступенью эволюции будет мидл — специалист, которому можно поручить дизайн компонента, работающего на уровне всего проекта. А следующая ступенька — уже синьор. Он видит много сервисов и может работать над их взаимодействием, над всей системой. Это довольно условные разграничения, но самостоятельность нужна в любом случае.

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

У джунов же горящие глаза и рудиментарные навыки, а будет ли из них толк — становится понятно через полгода. И часто оказывается, что толка не будет. Чем больше продемонстрируете доказательств вашей самостоятельности, тем лучше для вас.

Выводы

• С точки зрения работодателя, наём — это риск. Дорогой риск. Поэтому в найме false positive лучше, чем false negative. Лучше не взять потенциально хорошего программиста, чем нанять плохого.
• Джунов сложнее собеседовать и страшнее нанимать, потому что они стоят в найме не намного дешевле синьоров, пользы от них на порядок меньше и получает её компания гораздо позже. То есть какое-то время бизнес просто тратит деньги в пустоту.
• Понять про джунов на собеседовании тоже можно гораздо меньше — у них слишком мало опыта. Зачастую они не могут рассказать, что делали, какие ошибки допустили и чему научились. А это важно, чтобы оценить кандидата.
• Open source, на мой взгляд, идеальный вариант сэкономить ресурсы компании и заявить о себе. Этот вариант подойдёт и рекрутерам, и HR-специалистам — у них есть строчка, в которой указывается, какие проекты человек делал. И это идеально для меня как для нанимающего инженера. Ведь я могу посмотреть и реально увидеть код кандидата.
• Собеседование — это стресс, а работаем мы в спокойном состоянии. Мне интереснее посмотреть, как будет выглядеть код, написанный дома для реального проекта, чем на нервный лайвкодинг.
• Open source — это опыт, о котором можно заявить в CV и который даёт вам действительно полезные навыки коммерческой разработки. А пет-проекты показывают, в каких инструментах заинтересован человек, какие базовые действия он освоил в процессе учёбы.

Ваше мнение — во что лучше вкладывать время и силы?

Проголосовали 143 пользователя.

Воздержались 44 пользователя.

Некоторые pet-проекты со временем превращаются для своих создателей в основное занятие и основной источник дохода.

Поговорим про то, какие сервисы могут помочь вам в создании и развитии pet-проектов:

Как построить продукт:

– Timepad: отличное решение для того, чтобы организовывать и монетизировать онлайн-ивенты. Вам не нужно строить сложную систему бронирований и устанавливать онлайн кассу: регистрируетесь, подписываете договор, создаете ивенты и вперед.
– Gumroad: максимально простая и понятная система для продажи цифровых продуктов. Старт бесплатный, сервис берет только transaction fee.
– Airtable и аналоги: базы данных на все случаи жизни. В целом, если вам не нужны адвансд функции и/или вы не хотите разбираться с принципом работы сервиса, можно использовать знакомые, но менее секси варианты: google forms, exel, trello и тд — зависит от вашего кейса.
– Typeform: вспомнив про google forms, нельзя не упомянуть typeform — крутейший инструмент, с помощью которого вы можете создавать не только формы опросов, но и лендинги для сбора заявок в waitlist, со встроенной анкетой или вообще, сконструировать продукт на основе квизов.
– Zapier: казалось бы, ну уж для api-интеграций сторонних сервисов-то нужны программисты? Тоже не всегда нужны — есть Zapier, который может заинтегрировать что угодно, с чем угодно и стоит сильно дешевле бэкэндеров.
– Getcourse: не уверена, что сервис нуждается в представлении — лидирующее на рынке РФ решение для создания онлайн-курсов, марафонов, онлайн-школ — вот этого всего. Есть альтернативные решения вроде Teachable, Thinkific и тд.
– Ну и последнее в списке на сегодня: маркетплейсы no-code разработчиков (как бы оксюморонично это не звучало). Например, стартап с российскими фаундерами WeLoveNoCode, предлагает услуги no-code разработчиков, что выходит сильно дешевле и быстрее, нежели платить за классическую разработку.

Как привлечь юзеров:

Мы не говорим про рекламу и другие платные каналы, т.к. это реально дорого, а у pet-проектов нет бюджетов – у нас остается основной путь:

Собрать коммьюнити лояльных подписчиков:
— в российских традициях: в телеграм-канале. Думаю, пункт в пояснениях не нуждается.
— привычным методом: в соцсетях: органику здесь получить сложно: FB, VK, Instagram требуют большого количества денег, времени и контента на то, чтобы набрать весомую лояльную базу. Это не значит, что это невозможно — но то, что это сложно, нужно учитывать на старте. Youtube в этом плане лояльнее к начинающим — все еще остается возможность получать органику чисто на качестве контента, что не может не радовать.
— или согласно зарубежным трендам: в виде email-подписчиков. Цены за клик в платных каналах все растут и маленьким начинающим стартапчикам и pet-проектам все сложнее получать юзеров и подписчиков — а на email-рассылки с ценным контентом, от людей, чьей экспертизе доверяешь, сейчас подписываются все более активно. Ну и лид-магниты как рабочая механика продолжают себя оправдывать. Наращивать базу подписчиков и взаимодействовать с ними через email-рассылки можно при помощи сервисов вроде Substack, Revue или сервиса с российскими фаундерами — Surfaces.one. Surfaces позволяет максимально просто создавать лид-магнит мини-лендинги, вести публичную страницу со своим контентом, создавать имейл рассылки и собирать базу подписчиков.
Где брать трафик для создания коммьюнити:
Сделать лид-магнит страничку недостаточно — надо направить на нее трафик. Платные методы мы, опять же, для pet-проектов не рассматриваем — пробежимся по бесплатным:
– Форумы: особенно эффективно для зарубежного рынка: Indiehackers, Quora, Reddit, HackerNews, форум на YC StartupSchool. IndieHackers, правда, почему-то недавно стал недоступен из РФ, но вы знаете что делать.
– Статьи: особенно эффективно на рынке РФ) Писать можно на vc.ru, на Хабре. Если знаете еще подобные варианты — напишите в комментах, пожалуйста.

– Платформы вроде ProductHunt и AppSumo. И да — это валидно не только для набора юзеров, но и для сбора подписчиков: советую познакомиться с кейсом развития продукта Trends.vc — ребята начинали как email-подписка.

Как искать инвестиции:

Допустим, pet-проект пошел в гору, вы понимаете, что пора бы все это дело скейлить. Масштабирование — это страшно деньгозатратное мероприятие и вы задумываетесь над тем, как найти инвестиции:
– Первый вариант — никак не найти: бутстрапить до победного: ваш продукт платный, ценность для юзера высока –> юзер за него платит вам –> вы пускаете эти деньги на развитие продукта.
Плюсы: никому ничего не должен, самостоятельный предприниматель, создал бизнес, а не мыльный венчурный пузырь, самооценка повысилась.
Минусы — продукт растет медленнее, нежели мог бы с венчурными деньгами на скейлинг и маркетинг.
– Фандинг-платформы: платформы вроде Stonks.com, SeedInvest.com могут быть вашим вариантом.
– Ангельские инвестиции: ищите на angel.co и пишите релевантным инвесторам.
– Акселлераторы: топовые вроде: Y Combinator, 500 startups, Techstars, и/или менее крутые — их миллион — выбор за вами.
Важно: тот факт, что для вас продукт все еще “pet-проект” и вы работаете full-time где-то на стороне — как правило, «red flag» для акселераторов — учтите это при построении стратегии привлечения денег.

Обещанный бонус:

В следующий понедельник, 6 декабря в 19:00, проводим БЕСПЛАТНЫЙ вебинар «Как найти время и мотивацию для своего проекта».

Будет много полезной информации и классных фишечек и приёмов. Поговорим о том, что такое pet или side-проект; почему им стоит заниматься (если вы ещё не) и точно стоит продолжать (если уже да, но подвисли); какие бывают подводные камни side-проектов, а также как правильно распределять время на проект и увеличить вероятность его не забросить. Ну и конечно много личного опыта и практических советов!
Зарегистрироваться пока еще можно по ссылке:

Всем дочитавшим, удачи с проектами и встретимся в понедельник!