Coding For Fun – How to Avoid Creating a Second Job

When I was in school, programming was my favorite pastime. Now I code for a living, and though I still enjoy it, I find it more difficult to code for fun. I consider “for fun” to be distinct from “kind of fun professional development that is work, if I’m being honest.” If you have the time and energy to, say, work on an iOS app outside of work, this article probably isn’t for you. You’re already occupied. Good job. For those of you who, like me, have at least three WIP smartphone apps that you don’t want to touch ever again, this post is for you.

Step 0: Recognize the problem.

I can count five abandoned project directories on my computer, which is barely a year old. I’m passionate about software, so why do I suck at making it in my free time?

I suspect this phenomenon is driven by the law of sustainable pace: I want to code for fun, so I make a project. Projects look a lot like work, and I already work 40 hours a week. My project gets whatever time I can spare, and I find that I can’t spare time when the project gets boring and tedious.

And yet, I like coding and want to code for fun. It would be nice if the fruits of my labor didn’t look like the motley crew currently residing in ~/projects, right?

Right. I’ve stumbled onto an approach that has worked for me, and I found it only because I haven’t had the time to invest in a poorly planned pet project. As a result, I program in my free time (read: two hours/week) and feel really happy when I do it.

Step 1: Choose a language.

Wait, what? Isn’t the tail wagging the dog here? Shouldn’t you choose a problem before choosing a tool? Stay with me. The idea here is to make sure that your “fun” activity does not resemble what you do for work. I tried using JavaScript for fun once, and about three minutes passed before I thought, “Oh, this idea applies to this other problem I’ve been having at work. How neat. I should open up that file…” No. Not neat. Separate your worlds.

The second idea is to choose an unfamiliar language, so you can be a beginner. I find learning new languages is particularly refreshing to my brain, and it makes me happy in a way that just writing in a familiar language does not.

It’s also a good idea to choose an expressive language with an out-of-the-box, awesome REPL, like Python, Smalltalk, Racket, or Haskell. I especially like the last two, and it helps to pick a nice book from No Starch Press to get you going.

Step 2: Set some goals.

Your goals should be uncoupled from productivity or the idea that you need to account for this time. This is harder than you’d think, since we exist in a field that is run amok with impostor syndrome, where there is a lot of pressure to be up on the newest technologies and practices. The only relevant metrics are time spent and fun had.

I find when I try to learn something I think will be useful professionally, I’m much less likely to get immersed in it and enjoy myself. I already learn professionally useful stuff all week. I also find there’s an inverse relationship between my intention to learn something useful and learning something useful. If I focus on enjoying myself instead of doing something ‘useful’ or ‘productive’, I’ll reap the benefits the next day with a fresh perspective on the problems I tackle at work.

For example, here are my goals:

1. Feel happy when I’m finished coding for fun.
2. Let go of any hangups that keep #1 from happening.
3. Actually do this for a measurable amount of time per week.

Step 3: Pick a project (or problem set).

I love puzzles, so my go-to problem set right now is Project Euler, which is language-agnostic. I also like Kattis—a competitive programming site with a nice user interface, amusing problems (many from ACM competitions), and support for a wide variety of languages.

In particular, the Project Euler problems are concise and difficult, and they require a lot of thinking time. I try not to pick problems that require a lot of reading/typing time—I already do enough of that at work, and by picking “thinking problems,” I don’t have to be staring at a screen to be programming. This is very helpful, for instance, when dishes need to be cleaned, or the dog walked, or the baby burped. That’s programming time!

A nice alternative to puzzles is making them! Game creation is really fun, too, since you can typically find a framework that does a lot of stuff out of the box and allows you to focus on creating a world or telling a story, or solving a problem in a really unique way. Spinning up a homegrown physics engine in Greenfoot was super-duper fun, even though, you know, there’s a library for that.

I’d also warn against picking a project because it’s a good business idea. If it’s a really good business idea, then figure out how to make it your day job. If you can’t do that, then maybe it’s not that great of a business idea.

Step 4: Profit.

Well, probably not literally. But seriously—coding is fun, and if you do it for a living, you ought to be able to enjoy it as a creative outlet or an avenue for experiencing new ideas without bringing in the stress of real life work. If you’ve had success in programming for fun and attaining happiness from it, please leave a comment!