I love programming. I really do. It’s one of the few things that really gets my brain buzzing. In my twenties I’d go to work, program my ass off, then come home and repeat. Or, when I worked for myself, I’d just not stop. But, as I make my way through my thirties I’ve found that most days I come home and simply don’t want to look at code anymore.

I code the back ends to web sites you see, and I’ve been working on web dev. for over twelve years now, and honestly, there’s not a lot of innovation going on in that area. Every now and then someone comes out with a sweet new framework like Rails, but after the initial fun of learning it, and trying to convince everyone you know to use it too, you realize that you’re almost always doing the same damn thing: taking form data and shoving it into a database, then taking crap in a database and shoving it to the screen. The only difference is which crap you’re shoving around, and where it happens to be stored.

It seems that the mid-life crisis comes a bit early to coders, as a number of the ones I’ve talked to have found themselves feeling a bit ground down as they start in on their thirties, wondering if maybe they shouldn’t open a greenhouse or do something else equally removed from the world of code. I don’t blame them. I’ve felt the same way, but every now and then the universe reminds me that coding can be an absolute blast. That no matter how much I might enjoy some other simpler profession, there’s nothing that’d get my brain buzzing like this.

John Bender has come up with five simple rules to keep programming fun. And while they’re all good, I, like you, look at it a bit differently. So here are my rules for keeping programming fun.

1. Remember that nothing is more important than living a full life.
When I worked at iPhrase there was this one guy who worked on the back end. He probably averaged 16+ hour days because he was really into his piece of the project. It really got his brain going. But, eventually, he, like everyone else, got laid off. And I always remember him, because when he looks back on those years of his life, there’s nothing there. There was not time for a social life, and IBM now owns (and has probably mothballed) all of the code he wrote. Code is guaranteed to become obsolete. Pretty much anything you work on will be abandoned sooner or later. Don’t get so wrapped up in your code that you forget to spend time with the people who matter to you. There will always be more code to write. That weekend getaway with your friends is a little once-in-a-lifetime experience you can’t replicate. Sometimes, it’s even simpler than that. When you’re sitting there coding away and your child, wife, or even pet comes up and asks you to play, or spend time with them, do it. Finish that function, hit save, and walk away from the computer. Do not make them wait more than a few minutes.

2) Small, self-useful, projects.
John talks about small triumphs, and while those are very important, I’d take it even further. I get the most joy out of small projects. Writing some cool little app for my phone that I’ll use every day, or some helpful little tool. While John’s right that “You’re rarely going to write the next big thing, or anything really meaningful in a single day’s work.” To me it’s so self evident as to be a non issue. Not only that, if you attempt to write the “next big thing” or anything “really meaningful” it’s going to be work, not play. And I want to look back and think that ,while I may have been spending some of my free time coding, I was coding something fun that put a smile on my face. As such I try and work on very small projects, or very focused features of someone else’s project. Making each feature it’s own little one day project.

Let me give you an example. I’ve been hacking on a fork of Photostream because I thought it was a great proof of concept, but one that could use a lot of improvements. For example, it doesn’t support Flickr contacts. So, while I can add people in manually, I can’t say “load in all the people I’m following on Flickr.” So, one night’s project was to make it support adding a person, their contacts, or them and their contacts. A small accomplishment, like John says. But, I like to, whenever possible, make it so that I could walk away, after a nights work, and have something that would be useful as is, without ever touching it again.

If I wasn’t forking the whole project I would have just submitted that change and felt I’d accomplished something useful, that others could benefit from. But, as I make my way through the day at work I think “I wish it would…” and every couple nights I’ll boot up Eclipse and hack in another feature. But, if my dog decides I’ve been spending too much time at the computer, and too little time with him, I remember rule number one, finish the current thought, or leave myself enough comments to pick it up tomorrow, and go play with him. But, I’ve found that it’s not just about making small goals.

Time and again I’ve found myself getting the most enjoyment out of the smallest projects. A tiny Flickr app, an app that hollers if your servers go down, something that graphs the lines of code per package in a Java project, a distributed bug tracking system, or a library that’ll save me tons of frustration on other projects.

These won’t change the world. They aren’t “really meaningful” but they’ve all been useful to me, and because they’re never so large as to have any chance of becoming work, they’re always lots of fun. Instead of hacking the next great foo, consider adding that feature you always wished that app you use every day had. It doesn’t matter if you never contribute another thing to that project. It doesn’t even matter if you release your code. What matters is that it’s a fun little challenge that you’ll appreciate the results of afterwards, and hopefully learn something interesting along the way.

3) It’s all about you baby.
Never code for anyone else in your free time. If you do, it’s work. Rick Miller left a great example of this in the comments on my art-blog. He said,

“I know from experience that something you love doing can become a pain in the ass when you feel like you have to do it. For a while, I was making flutes out of any kind of pipe, hose or hollow plant stalks that I could get my hands on. I used to carry them with me and play them when I had a few spare moments. Sometimes when someone would make a positive comment or if a child was curious about the flute I would hand it to them and say, “It’s yours.” Sometimes I’d give them away just on a whim. Once I even gave one out through my car window to a girl in another car on the freeway at 60MPH. Then I agreed to make a flute for a Spanish fellow for $20. My flutemaking stopped. When I finally forced myself to make the damned flute, it was nothing to be proud of. I was glad that my bank couldn’t figure out how to draw on a check from the boonies of Galacia because I’d have felt bad if the guy had actually paid for such a piece of crap.”

You’ve never hear of a child “playing for someone else”. Why? Because it’s simply not possible to play for someone else. You can play by yourself, or with others, but never for others.

4) Prioritization.

John says

“Write whatever you need to put a useful piece of software out, then add on the frills later. This will let you release earlier, possibly get feedback and, if anyone is interested in your project, maybe even get help.”

And while that’s a good plan, it’s a bit too close to work for me. I prioritize my personal coding like this:

It’s only when I’m about to release a new project that I even begin to consider what anyone else wants, and even then it’s pretty minimal. Because it doesn’t matter to me if you use my code or not. I had fun writing it and that’s the only thing that’s important. However, I’d feel bad if my code caused you misery or frustration, so, before the release of a new project I make sure that I’ve got all the basics covered.

For example, my Photostream fork isn’t released yet because if you tried to load junku’s 3,700+ contacts, you’d almost assuredly run out of ram. So, I need to add some paging to the list of your buddies. And, it just wouldn’t be right to use the same icon, so I need to change that too, but, both of these things are things I want to do for me anyway, and thus they’ll be fun, but even if they weren’t fun, the knowledge that it would make others unhappy would make me unhappy. So I’ll do a little work to avoid sadness, and increase everyone’s happiness.

5) Share freely.
Talking about “advice” John says:

“I find myself afraid of asking questions for fear that someone else will steal my idea or think I’m an idiot, and this keeps me from heading to the an irc channel when I need help. The bottom line is, 99 percent of the people who come up with really cool ideas never finish them and most never even start, so if you need to divulge a little in the interest of getting the thing done, do it.”

I say, screw that. You’re doing this for fun right? If you’re playing it so close to the vest that you don’t want anyone finding out what exactly you’re doing, then you’re working not playing. I remember reading a post by a novelist who talked about how there were all these people with great ideas for a novel who were afraid to mention them for fear some author would steal them. But professional authors don’t hesitate to share their ideas because they know that cool ideas are a dime a dozen, and, like John says, executing on one of them is something hardly anyone ever bothers to do.

Even if someone took your idea and ran with it, what they’d end up with would be radically different from what you would end up with. Plus, there’s the fact that all the stories have pretty much been written already. New novels are just old stories processed through different people’s imaginings. As with writing, there are very few new software ideas. Mostly, we’re just making iterative improvements to existing ideas.

Personally, I’ve got notebooks filled with ideas for projects, and about half of them would be profitable businesses, but I’m not going to implement 99% of them (and if any of my geek friends was in need of a business idea they’re there for the taking).

So ask your questions. Discuss your ideas. “Worst” case scenario someone else does most, or all, of the work for you, and you get that fun app you wanted without having to lift a finger, which leaves you more time to work on that other fun app. Or maybe they point out that you really are an idiot, but, wouldn’t it be better to discover that you’re doing something stupid *before* you spend weeks coding on it? Best case scenario, you get free suggestions on how to make your thing better, and if you release it open source then maybe someone will send in a patch with a nifty new feature, or fix that bug you never got around to addressing.

Remember, as soon as you start charging for it, you have responsibilities to the users, and those can very quickly turn into work. And if you’re not charging for it there’s no good reason not to release it as open source. Plus, every time you get a patch or a bug fix sent in it’s like a mini-christmas. Some surprise present, and we all like presents.

In summary, for me, the key to having fun with coding is to focus on the fun, the little bits of joy, and always keep sight of the life that’s going on around you. Be part of it, and make sure that when you look back on any part of your life, you’ve got something to show for it beyond some code that’ll probably be replaced or abandoned in 5 years.