Developers are some of the lucky few for whom the classic phrase rings true: “Do a job you love and you’ll never work a day in your life.” At least, that’s the dream.
Like many developers, I thought it was the coolest thing ever to make a computer show HELLO WORLD with a simple BASIC program. (I did this just last week and it was worth 8 sprint points — just kidding!)
Initial interest grew into a hobby which led me to the dream of getting paid to write programs. Wouldn’t that be the coolest thing ever?
Unfortunately, spending all day being told by someone else how to do your hobby can leave you wanting to do something else, anything else, when you get home at night.
Even side projects, purportedly done just for fun, can be draining. They start off simple, but the urge to do something (“airquotes”) “worthwhile” with your time can grow and mutate. Before you know it your project’s on GitHub, available to be picked up and made use of by all and sundry; now you’re constantly worrying about making changes in case it breaks for someone who’s using it. Worse yet, people will start putting in feature requests that admittedly sound pretty interesting, and suddenly you’re spending your hobby time being told what to do!
Other times, that clever idea that you’ve been building in your spare time turns into something which you think might be monetised some day. Exciting!… except that this means you have to spend time making it usable and understandable by lots of people, rather than just something quick and fun for yourself.
Now, to be clear, I’m not against fixing bugs, making things easy to use or monetising your products. But sometimes that stuff’s just not fun.
Keep It Simple, Stupid
My suggestions for fixing this is to just pick a nice, simple mini project and just do it!
Here’s some quick and easy rules of thumb:
- It should take only a night or two to complete.
- Pick something interesting.
- Pick a problem that you understand, but that's also a little bit challenging.
- Use languages or frameworks you know. Having to refer to documentation every few minutes is boring.
- Implement it in a way that makes sense for you. Don't get side-tracked with looking up how to optimise the algorithms. That's boring!
Ideally the ideas should flow straight down out of your brain, through your fingers and into code.
I wouldn’t recommend trying to learn a new language, framework, or library (etc), for this type of project. Continuing skill development is valuable, sure, but we’re talking about relaxation, not education. Trying to do that always seems to lead to a brick wall really quickly.
Let’s say that I want to play with some computer vision tools. For me, the process tends to go like this:
- Let's install the CV library
- I'm missing a dependency, better install that
- The library is not available for my OS? I guess I can compile it
- Whoops, I need to install the compiler
- 4 hours later: Great, it's ready to go!... except it's time for bed. Maybe I'll get started tomorrow?
Or, when learning a new language:
- OK, I've learnt how to write Hello World, this is easy!
- Hmm, I heard they use structs instead of classes? How do I create one of those?
- Wait, structs can't have computed properties? Back to classes.
- It's nearly working but is this best practice? Let me research.
- 4 hours later: It's a moot point as I still can't get the compiler to work.
You can see how what started as a quick little code snippet to wind down can turn into nothing more than an exercise in frustration.
An Example
What’s my latest project along these lines? Well, right now I’m working on a little something that’s pretty simple to implement but still requires a little bit of thought. It’s a small program that solves Simon Shuker’s Code Cracker.
These puzzles may look like crosswords, but they’re quite different. Here’s an example of one:
Each square has a number corresponding to a letter. You’re given two letters to begin with and after filling them in you should be able to figure out some other letters to complete a word. That word will give you more letters that you can fill in around the board, you’ll guess more words and the process continues.
My little Python program works in the same way. It iterates through all the words and finds any that have letters that haven’t be populated. It then populates those and sees if any words match (from a list of dictionary words). Usually only one word will match, but if there are multiple candidates it will continue the process down each branch. Eventually it will come to the end where all the letters are correct and make valid words, or it hits a dead end, in which case it backtracks and tries again.
I wrote the code in a few hours over a couple of nights.
It takes less than a second to solve a puzzle but it can take a minute or two to transcribe the grid.
It’s written in Python, which I’ve used day in and day out for many, many years. This lets me just express my thinking in code without having to constantly figure out how to code, leaving more brain to come up with the algorithm.
I’m happy with that.
Next Steps
Here’s the part where I give you the GitHub link. Or talk about how I’m going to turn this into a PSAAS (Puzzle Solving as a Service) with a REST API.
But that’s not the point, is it? Those things sound like too much work now. I’ve already done the fun and most enjoyable part of the exercise, and that was my goal.
So get out there and code! Don’t worry about a big impressive project, or something to monetise. Don’t put it on GitHub, unless you’re willing to put in the time for non-coding maintenance.
Just relax and write something fun, just for you. Don’t even write a blog post about it.
…wait. Oops.