Как я научился получать удовольствие от pet-проектов


    Скрин последнего pet-проекта

    Термин pet-проект каждый трактует для себя по-своему, сам я его объясняю следующим образом: разработка, отличная от работы.

    Классификаций pet-проектов тоже предостаточно. Я определил для себя следующие:

    • краткосрочные/долгосрочные
    • коммерческие/некоммерческие

    Думаю, комментарии тут излишне, помимо одного — под краткосрочными я понимаю те проекты, которые занимают 1-2 вечера или же выходные, но не более.

    Понятно, что две эти классификации можно и нужно между собой комбинировать: краткосрочные & коммерческие, долгосрочные & некоммерческие и т.д.

    В жизни, я сталкивался со всеми из перечисленных типов pet-проектов. В основном, это как раз таки краткосрочные & некоммерческие — как самые простые в плане реализации и затраченного времени. Как правило, это проекты направленные на изучение того или иного модуля, технологии, подхода, алгоритма и т.д. Тут все просто: быстро сделал, быстро порадовался. Можно использовать на боевом проекте для решения реальных задач. В общем, все тоже самое, за что я люблю хакатоны (надо уже наконец собраться и написать статью про хакатоны).

    Но были конечно и долгосрочные проекты (об одном из них я уже писал пост) и вот с ними то у меня большие проблемы, а именно с мотивацией. Помимо того, что вы до конца не уверены, что проект окупится(если речь конечно идет про коммерцию), так и сам проект превращается в рутинную вторую работу: все те же таски, бэклог, приоритеты и т.д. Не знаю, как на других, но на меня это очень сильно давит. Хоть я лично и встречал людей, которые делают свои pet-проекты в одиночку по 6 лет, свои долгосрочные проекты я либо сразу забрасывал, либо даже не начинал делать, зная чем это закончится. Исключением из правил для меня являются проекты, в кооперативе с кем-то: так и интереснее и процесс быстрее идет, да и ответственность как никак появляется не только перед собой.

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

    В моем случае, мне помогли 2 вещи, которые мне посоветовали 2 товарища:

    1. книга «Вы, конечно, шутите, мистер Фейнман!»
    2. спонтанное планирование

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

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

    Понятно, что я не открыл Америку и такой подход вряд ли можно заюзать на работе (хотя я где-то слышал, что Valve так когда-то делали), но в рамках долгосрочного одиночного некоммерческого pet-проекта — почему бы и нет?

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

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

    Делитесь своими историями и методами, которые помогли именно вам сдвинутся с мертвой точки.

    Комментарии 8

      +3
      Делитесь своими историями и методами которые помогли именно вам сдвинутся с мертвой точки.
      Не разговаривай о проекте, пока не доделал до определённого состояния завершённости.
        +5
        Делитесь своими историями и методами которые помогли именно вам сдвинутся с мертвой точки.


        Для меня работали следующие практики:

        • не бросаться сразу писать код

          Лучше неделю/месяц потерпеть и потратить это время на анализ конкурентов, составить примерный план работ, завести задачи, если прийдётся с чем-то новым работать, то сделать несколько прототипов и т.п. А вот потом если всё ещё есть смысл продолжать, то браться за написание MVP/прототипа.
        • тратить на MVP проект не больше 2-х (максимум 3-х) месяцев (это грязное время т.е. работая после работы, в выходные, сидя в машине и т.п.)

          Суть в том что на такой период мотивации обычно хватает, а вот на больший период уже нет. Плюс виден результать работы (+ проблемы, возможности и т.п.) и можно оценить стоит продолжать или нет.
        • не останавливаться даже на день т.е. что-то да надо для проекта каждый день сделать (здоров — пишешь код, заводишь issue, рисуешь иконки и т.п., заболел и не можешь писать код — заведи issue или добавь хотя бы строчку к существующей)

          Начнешь пропускать дни — всё встанет и никогда не будет сделано.
        • использовать инструменты которые ориентированы на быстрое создание прототипов и с которыми есть опыть работы

          Я для веб приложений использовал Rails т.к. ИМХО он идеально подходит для создания прототипов/MVP если есть опыт работы с ним. Он посути как конструктор т.е. из готовых блоков можно буквально за пару дней собрать основные экраны, админку, API, за пол часа «прикрутить» аутентификацию, настроить деплой и т.п. При наличии опыта всё делается очень быстро.

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


        Как-то так.
          0
          Очень исчерпывающе!

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

            Дело было чуть больше 5 лет назад. Выбирал из Qt, Electron, SWT, Swing и JavaFX. Выбрал JavaFX. Практика показала что сделать приложение на JavaFX можно и оно будет неплохо выглядеть и работать, но проблем с ним как и с другими фреймворками хватает. Например, чтобы было понятно, после Jigsaw в JDK «выпилили» jpackage и на несколько лет сборка инсталяторов под разные ОС стала очень не тривиальной задачей. Или например где-то в это же время сломали ListView т.е. если он раньше мог без проблем работать с 1М элементов и более, то теперь он загибается на нескольких тысячах. Это особенно критично если учесть что виртуального режима у ListView нет (как например было в WinForms или Swing) и это кстати тоже серёзная проблема (вроде как glazedlists может ее решить, но я уже не помню чем закончились эксперементы с ним). Всё это можно поправить/обойти при желании, но вместо работы над продуктом прийдётся решать эти проблемы и тратить кучу времени посути впустую и как я писал выше всё это сильно демотивирует.

            Я сейчас время от времени смотрю на крос-платформенные UI фреймворки которые уже имеют какую-то историю или недавно появились, но что-то не один не внушает доверия.
          +3
          А собственно зачем заставлять себя, если не лежит душа? Не хочешь заниматься pet проектами — не занимайся. А хочешь — так занимайся.

          P.S. Сам я все свое свободное время провожу за личным проектами, но не по тому, что это «надо» а просто мне нравится так проводить время… Зачем же еще это может быть?
            +6

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

              +2

              У меня тут свой термин образовался: pet code in production project. Это когда вместо проверенного и знакомого кода суёшь в проект что-то новое и молодежное, потому что "ну а где и когда я это ещё попробую?".

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

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое