#️⃣ Кстати, на тему пет-проектов.
Я пришёл к выводу, что в целом имеет смысл браться только за три типа — всё остальное не стоит отвлечения на себя времени и внимания.

1) Маленькие утилитарные проектики.
Буквально скрипт на коленке, когда вы устали выполнять какую-то рутинную операцию и вдруг думаете:
А почему бы не автоматизировать маленький шаг?

Из последних примеров: я хотел навести порядок в своём Obsidian — проставить атрибуты дат у заметок, разложить их по папкам, чуть подправить именование по паттерну.
Понятно, что сделать это можно и руками, но со скриптом — прикольнее.

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

2) Вам просто в кайф это делать.
Это, наверное, самая сложная категория — непонятно, откуда она появляется и почему исчезает, но она точно нестабильна.

Если нет никаких логических причин, но вам по какой-то причине интересно проводить время за написанием программы на Elixir, изучением Rust или чем-то ещё — делайте это.
Не пытайтесь в этот момент натянуть сову на глобус и добавить к интересу ощущение пользы — это только всё убьёт.

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

Главное здесь — не загубить свой интерес попытками заработать на проекте или «увеличить импакт».

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

Почему конфликт?
Потому что сама идея по себе — скучна. Когда у вас миллион вариантов, что сделать, вы впадаете в ступор: ничего не выбираете, интерес пропадает, а критерии успеха становятся размытыми.

Вот пример: у нас есть AI-агенты, ChatGPT, куча фреймворков и SaaS-платформ вроде Vercel и Supabase, где можно почти без кода поднять приложение.
Возможностей — море. Толку — немного.

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

Например:
Мне надоела система сборки JavaScript, но с ней так удобно работать. Было бы круто, чтобы сборки не было, но всё работало как раньше — быстро и удобно.
Или:
Я люблю, когда в проекте есть требования, но ненавижу их писать. Было бы круто, если бы код одновременно был и требованиями, и реализацией.

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

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

Теория ограничений вообще утверждает, что такое решение всегда существует.
Мы просто часто его игнорируем, когда идём по проторенной дорожке.

4) И напоследок — оставляйте вкусное себе.
Это правило гораздо глубже, чем кажется, но многие про него забывают.

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

Вам нравится делать всратый дизайн, но вы этого не умеете?
Делайте, но не губите свой интерес, помните аппетит приходит вовремя еды, найдите конфликт, он в 100 раз дороже идеи.

И удачи вам с вашими петами.