Ever found yourself starting a personal software project and, after a good start and feeling awesome learning something new, you're suddenly treading water, mostly yak shaving and reading documentation in more and more depth, to make sense of the 7th tool that you are using to make it all work? It's not something unheard of. I suffer from this condition myself on occasion, many of us do. When you're starting something new, especially something you wanted to start, it's nice to add many nice-to-haves, and pile up many technologies that you don't know, just because you can. If you combine these many unknowns with limited available time to learn, you'll end up with yet another unfinished project. Can you help yourself, though?
One thing to keep in mind is the scope of your project, and the goal you've got. It's not necessarily a mistake to bury yourself in documentation and theory if your goal is the exploration and understanding of the underpinnings of a technology. It only becomes a problem when your goal is to use what you're building, deploy it, and run it. To save ourselves, let's use the project to build this very blog you're reading as an example of a successful "deploy-to-production" project.
My goal was: to build a blog using a static generator, just as I used Hugo before. The fun begins after that. Since I wanted to improve my lisp and guile in general, I decided that it would be great if I could use a static generator written in guile scheme, and for that reason, I ended up with the sublime Haunt. End of story? Of course not!
What I had to deal with
Here's a list of the things I had to learn to different degrees of proficiency:
- Haunt. Haunt documentation is short, so I opted to read it all. I also cloned Haunt repository (free and open source software is awesome, isn't it?) to go deeper later
- Blog examples. I went through a few other blogs built with Haunt, in order to get a feel of how scheme was putting an actual website together. After reading the documentation, I needed to see some action in order to gain a better understanding
- CSS. I wanted simplicity, so no frameworks here. To do that, I had to consult css rules and check more examples. I ended up learning a bit more about how to use font families. It's usable. Lots of room for improvement here
- Find a place to deploy. I spent a good amount of time here. I'm using sourcehut pages because sourcehut is great and such a friend of the free software movement. I had to learn how their continuous integration work, meaning, how can I publish a new post with a single push to my repository? builds.sr.ht is the answer
- Git to publish, editor to write code and blog posts: Emacs. Even though I know these tools already, I included them here because it's another knowledge layer needed and Emacs is awesome.
- Markdown. This was very quick. I learned whatever commonmark I needed in literally seconds
I'm sure there's more knowledge that I internalized and can't think of now. In such a small project there's a surprising amount of things to learn.
Cut back
The only way to have something done quickly is to concentrate your efforts and cut back the scope. At least we got an advantage in software, which is we can release it and keep improving afterward. In my case, I focused most of my efforts on Haunt and later on css. everything else, if I wasn't able to do quickly, I put aside for later.
Consistency, the unsung champion
Last but not least, you could have limited your scope all you want and still end up abandoning your project, simply because you slowly stopped working on it. I've done that more than a few times. The way I found to maximize my chances of completing a project after the scope is sufficiently reduced, is to enforce consistency, if possible daily, in a way that I feel is not a big deal. For example, in my case, I always work on my projects before the workday starts, for about 45min to 1h30. This kind of consistency is a game changer, and worth another blog post.
In sum, you should delay everything that is not essential to the project, and reduce what you need or want to learn in depth while keeping a consistent pace. Moderate and steady is better than great bursts followed by stretches of inactivity.