I remember when I was naive, young programmer, a side project would go something like this – I would set myself a goal to get a login and register screen that, as you guess, allowed a user to log in and register. This would take me about a day to do, maybe less. These were the days when the goal wasn’t for later use, because more likely than not, I won’t have to keep maintaining the code that I’ve written for longer than a few weeks at most, if at all.
The mindset was different, the set goal was almost like the smoke and mirror, an illusion masking the real reason why I was doing the side project – which was to learn how to write code that does what I intend, to learn how to create a login and registration screen that works, it didn’t matter much whether I used X patterns, Y framework, and used Z hashing algorithm for password storage – it didn’t matter that it wasn’t perfectly readable either. I achieved my set goal (the illusion), and more importantly, the real reason – I learned something new.
I became worse at delivering side projects with experience
You really don’t want to think like a programmer
Fast forward to today, with over a decade of programming experience, I’ve found that I’ve become much better at what I do – I have become a more attentive to the quality that I produce. Each decision is made with conscious intent. Every abstraction seemingly decided for fewer headaches later down the line… but… I have to say, those things aren’t really helping me ship things on the side. It has slowed me down to the point that I feel that it actually stops me from actually doing one of the most important thing about writing code. Shipping.
I’ve noticed that 60-80% of my time is spent either making sure I am making the right decisions, refactoring or writing that “good enough” code. The time that I spent on outside of work (20 hrs+ per week) takes so long that I sometimes lose motivation to finish thinking that I might not be able to ship until next year.
My mindset has shifted – I have this thing in the back of my mind that tells me the way I’m doing things right now could be so much better. That’s a terrible abstraction. The code isn’t clean enough. This won’t scale. I probably need some caching here. I have too much technical debt. What If this? what if that? I’ve become a slave to Software Design Principles where it doesn’t really matter.
https://t.co/rORz8xdCQp is a single PHP file called "index.php" generating $2,342.04 in a day. No frameworks. No libraries. 💖
— Pieter Levels 🏝 (@levelsio) December 7, 2017
Categorising software projects
So, after some thinking about this problem, I’ve had a thought of placing side projects into three different categories:
- Best Practices
These are the types of projects where you want to try to minimise corner cutting whenever possible unless shipping as quickly as possible is critical. Some examples include:
- Shared opensource project potentially used by at least a few hundred people
- Project that’s making you a fair amount of money
- Code that you produce at work
Sometimes, we have projects where we simply want to learn things, these are the sort of projects that we keep as reference – we never really should have to think too much about whether we’re following best practices for everything, as the scope is small and focused – our only concern is the clarity of how we’re communicating the learnings from the project.
These are the types of projects that you want to ship as soon as humanly possible. Some examples include:
- Internal tools (that small bug or ugly UI isn’t going to get you 100 support emails per day, it’s not worth it.)
- Proof of concept
I think this is where I mostly go wrong with my approach, tending to treat it more like a best practice and learning project at the same time, while desperately trying to ship within the time that I’ve set for myself, which is already unrealistic to begin with – because we are absolutely terrible at estimating.
Perhaps a set of guideline would probably be helpful for these kinds of projects:
a. It affects how the project functions
b. The technical debt has slowed you down more than 3 times
- Bug fixing:
a. It affects a critical path of the solution
b. Assess impact and how many users will be affected. Use your own judgement. Is it worth fixing now?
a. It’s going to take less than 10 minutes to automate
b. You’ve had to do the same thing 3 times, and it costs at least 5 mins each time
- Choosing tech:
a. Only choose tech that you’re already familiar with
b. Do you really need it as an SPA? is it going to be beneficial and/or easier to produce?
- Optimising for speed:
a. Never do this until you have some users
Treat side projects like a hackathon
I recently participated in a hackathon. The scope and rules were clear – 2 days, show your proof of concept. Show something working. Sell it to an audience. When under strict rules are set by both the organisers and the team you’re part of – it becomes more difficult to go off to your normal discipline of doing everything “to the book”. You’re fully focused on delivering something that you can present. Under the right circumstance, you treat a project differently. Accountability is a heck of the driving force for self-enforcement.
Plan. Act. Don’t try to think too much in between.