Building More Faster Part 2 - Goldilocks Project
This post is part of a series. The other parts can be found here:
- Building More Faster Part 1 - Chasing the Dragon
- Building More Faster Part 2 - Goldilocks Project
- Building More Faster Part 3 - The Need for Speed
Choosing the correct scope for a hobby project can increase the chances of it being completed drastically. Too big and you run out of steam before creating something useable, too little and it runs the risk of being a boring project.
Today I'll try to figure out the correct size for the kinds of projects I like to do.
Ambition vs. Discipline
Defining the scope of a project is tricky to get right. I always struggle between wanting to revolutionize the world with my grand ideas (aka my latest fever dream) and doing something I'm actually able to finish.
As I (unfortunately) already know, I run out of steam pretty quickly if I work on a project for a couple of months and don't have anything useful to show for, I have to consider which project size is right for me and where I get the most learning for my spent time.
Done is Better Than ...
... everything else basically. A finished project is a good project. Having something that is actually usable at the end really drives that satisfaction home.
Even though I always try to finish projects, there are still a bunch that have been abondoned. Sometimes too early but sometimes also way too late which can quickly sap all the enjoyment out of the hobby.
What makes me abondon projects?
I think it boils down to a couple of reasons:
- The scope of the project is too big for me to handle in a timely manner and I get overwhelmed/lost.
- It turns out the project isn't as useful as I had anticipated and I lose interest (which is most likely even the right call).
- I get distracted by another idea that seems cooler.
A project that is never finished always feels a little bit like a waste of time, even though I still learned a lot along the way.
Lessons from the Past
Let's compare some of my past projects and see if some patterns emerge.
Closing Loop
Basically a task planner where you dump all your to-do's and it will schedule them according to priority so you can work away on it.
Time spent: 4 months
Things learned:
- JakartaEE is actually pretty neat
- JakartaEE can suck if you deviate too much from standard stuff
- Social-media login
- Wildfly
Status
Done but unused. Turns out, one ticketting system in my life is enough to make me dreadful - cough Jira cough.
Pros
Figuring out how social-media logins work is quite valuable. Also getting exposed to modern JakartaEE made me appreciate the project way more as it is actually quite nice to use.
Cons
There was actually nothing really novel about it and it's unused now, so with little cool stuff learned it feels more like a distraction in hindsight. But not every project can be great I guess.
Solvent
A CRDT-based to-do list web-app.
Time spent: 3 months
Things learned:
- CRDTs are awesome
- Go
- Web-backends with Go
- Duplicating business logic in the frontend is tedious
- React
Status
Done and my most used project to date. It could need some love as new data is polled all the time but it's doing its job.
Pros
Actually useful and it works pretty well. Knowing about CRDTs is super cool and even though I don't reach for them often I now always consider them for a problem.
Cons
Maintenance is somewhat annoying as all the fancy Javascript libraries would need constant updates which I'm currently not willing to do. Other than that, the perfect project.
Project Ikarus
A DIY quadcopter flight-controller.
Time spent: 6 months on and off
Things learned:
- C
- PID controller basics
- Raspberry Pi Pico
- Timers
- Interrupts
- MPU 6050
- Emscripten
- Raylib
- Websockets
- Deleting code is awesome
Status
That one is currently "on hold" because I stopped to enjoy working on it. Mainly because there is still a lot of stuff to do and it will take quite some effort to get useful results.
Pros
Learned a truck load of stuff and embedded programming is quite cool.
Cons
The scope was probably too big to finish in a reasonable amount of time even though I already tried that project once in the past.
Blog
The blog you're currently reading ;)
Time spent: 2 weeks
Things learned:
- More Go
- Recursive descent parsers
- BBolt key-value store
- SEO
- Systemd/journald
Status
Done and currently used.
Pros
I'm having lots of fun with this one as I can use/improve it every day and therefore feels very useful. It also laid the foundation for the new way to host my projects via systemd.
Cons
All things considered probably not the most "ground-breaking" project there is but high on the satisfaction ladder.
Voltbuddy
A small CLI that helps me calculate a pi pad.
Time spent: 2 hours
Things learned:
- How a pi pad works
- Building simple CLIs in Go
Status
Done.
Pros
It felt really good because I could use it immediately to order the proper resistor values for the amount of dampening I wanted to achieve.
Cons
"Just" a quick CLI. But that's kinda also what makes it great.
Temporary
Time spent: 5 months
Things learned:
- Elixir
- Phoenix web framework
- Javascript
- File encryption
- Erlang's Mnesia key-value store
Status
Done but needs updates to the latest versions.
Pros
Another site I use from time to time and development was quite pleasant. Basically the last remnant of me being Erlang crazy for two years.
Cons
The project is behind a couple of versions and you can't even start it with a recent version of Erlang/OTP. Maintenance is quite high as I already did a Phoenix upgrade one or two years ago when I ran into the same problem. This makes it kinda iffy to work with because sometimes I feel the urge to improve it a little but when I need to do a framework upgrade first I'll rather leave it be.
Verdict
While looking through my past projects I realized that shockingly my local projects directory contains over 50 projects and only ~ 6 are actually live and somewhat useful. That's quite insane when I see it white on black.
I think the number one lesson really is to pick my battles. I have to admit that I only have so much spare time left for coding and therefore can only tackle projects that have a very clear time horizon.
The second huge insight, that I only really came to appreciate this year, is that switching tech stacks is just a massive time sink. I always like to read up on the latest hot tech and give it a try but if my aim is to build something functional I just need to stop that. Even though the newest language might make my work a little bit more pleasant, it just takes too long to replace all the existing support infrastructure that I have already built. But more on that topic in another post...
Ultimately the right project size depends on what I want to get out of it - delving deep into a rabbit hole vs. getting some maybe shallower, but quicker wins.
Long-term projects can be very rewarding, but only if I get around to actually finish them, otherwise they become very unsatisfying and I tend to look at them as failed projects. A change of attitude towards half-baked projects might be the most effective fix, although that's easier said than done.
The perfectly-sized project would be something that is kinda long-term (~ 1 year) but still delivers something useable pretty quickly so I can iterate on it, but at the same time pushes the limits of hardware/software a bit so it is not the 100s copy of some proven technology.
Grand vs. realistic Revolutionizing vs. reinventing Crazy vs. sane
Still hard to not take more than I can chew.