My side projects workflow
- 2020-04-06 -If you're losing motivation when working on side projects, don't feel productive or simply don't know where to start, this is the approach I usually take with the side projects I actually "finish". Maybe it'll help you as well.
Idea, Requirements and Motivation
I usually start with an idea of what I want to achieve (A website for announcing group events! A bullet hell game!) and then start refining it into some sort of a general requirements list or a list of features I'd like to have. Then I try to minimize the requirements as much as I can to a minimum viable product (MVP) that I think I'd be satisfied with.
I also start thinking about what's in it for me. Is it to learn a new tech? Is it to have fun? Is it something that I'll find useful?
I've found that the projects that motivate me the most are those that I find useful.
Many projects end after this stage when I see how much work needs to be done or when I find that it doesn't interests me enough, and that's fine. I got to practice my skills of generating ideas, defining requirements and minimizing scope. And those are good things to practice. So I just file the project description in my private repository of projects that I might (read: won't) do one day.
Design and Exploration
If the project survives the first stage, I create a general design describing the general architecture and which skills/libraries do I need to be familiar with to accomplish this project, and then do a quick tour to reduce the amount of unknowns.
Sometimes in this process I think about different or easier ideas to implement, or ones that are more interesting to me, and start working on those instead.
Sometimes I just decide that I don't want to work on all these things right now and stop there.
Incremental Implementation
But when a project survives the general design phase, I then go and list the first few things I should do in order to build the project and start breaking them down to small tasks that I can manage in relatively short time and that will show some progress.
This is really important to me.
In order to get back to a project I need to know what the next thing I should do is, I need to know that it's not something that's going to take too long, and I need to see some progress in order to get some gratification from what I done.
The end of each session should be "what's the next I should work on?". Once you get the ball rolling when you begin a session, and get some gratification at the end of a session, it's easier to keep going with a project. And this is the fuel that keeps me working on projects.
If I don't know what is the next thing I should be doing and how much time and effort it's going to take or I won't see some visual improvement after what I did, I probably won't feel like actually doing anything.
Note that I find refactors fine. The progress made is in the code quality and the ability to achieve the next goals with ease. They also give a nice change of pace once in a while. But they should be done when they simplify the upcoming tasks, and not done arbitrarily.
Summary
So, in short:
- Create some sort of spec and reduce it only to what you really need.
- Think about what you will get from working on this project.
- Make a general design, understand your tools and reduce surprises.
- Split some of the work to small tasks you can finish quickly that will actually show progress.
- Build your project incrementally and keep going back to (4) as needed.
- ???
- Project!