Field Guide for the Bored Programmer Part 1: The Dos

This post is a little different than the typical content I’ve been trying to write on this blog, but after a few disparaging comments on reddit, I figured I’d try my hand at something a little less technical and a little more authentic.

One of my personality traits is that I don’t like to stay in the same place for too long. This is a curse and a blessing. I enjoy a constant flow of new changes and challenges, but I’m also inherently lazy. Without pressure or clearly defined goals I stagnate and have a difficult time completing simple tasks. Consulting has been the perfect cure for these symptoms – except when it’s not. The consistent flow of new challenges is engaging, but spans of bench time, on-boarding periods, and immature SDLC can add up to a lot of time without much to do. Here are some of my tactics to stay afloat when there is seemingly nothing to engage in.


Part 1: The Dos


Have an ordered list of the next things you want to do

Don’t just keep a list of things. Keep it ordered. Keep it updated. Keep it visible. Know exactly what you’re going to do the next time you get bored and know exactly what you can do when you’re finished. For me, ideas flow in and out on a regular basis and I can’t trust my brain to remember anything without the help of IntelliSense.

Maintaining momentum can be tough – recapturing it can be tougher. If you want more, use the momentum you have instead and build it into the momentum you want. Show the list to your colleagues – if you’re lucky they might hold you accountable.

Ask for training

First off, I’m putting this here because its true, but more importantly, you don’t need to be bored to ask for training. Last week Corinna Cohn tweeted about this topic on the same day a Jr. Developer told me he was afraid to ask his boss to expense a book that he couldn’t afford.  I didn’t push him, but I really wanted to know the source of his fear. Is the issue his employer or is it him? Employers that don’t invest in their employees are not employers to stick with. Employees that don’t ask for training likely don’t want training, don’t understand the value of training, or don’t have career ambitions. Good employers seek employees with ambition. Good employees look for employers that enable them to grow their career while adding value to their organization.

You are an asset – without growth you will become a liability.

F**k it (or How I Learned to Stop Worrying and Refactor Code)

Ever gone back to your code from a year or even a week ago, only to cringe and close IDE as fast as possible? Yeah, no. Leave it open. Fork it. Practice refactoring on a code base you are intimately acquainted with. Good refactoring practice is challenging enough against unfamiliar code. Now is your opportunity to tidy this mess up. Even if no one ever sees it, you’ve just made yourself a better programmer.

Read a book

This falls under training, but I wanted to make a separate point about reading books in general. One of the characteristics I’ve observed in all great programmers is that they read. Videos, blogs, meetups, and stackoverflow can get you going, but books take you to a tailored level of detail and, if they have the seal of an established publisher, the quality of the information received is guaranteed. (You can’t go wrong with Manning, O’Reilly, or Apress.)

“It’s not about you”

Recently I had coffee with Jamie Kurtz and I asked him a very pointed question about developing my career. The question isn’t important but the answer he gave me was. One of the most important lessons he’s ever learned in life and software is that it’s not about him or his career, but service. A simple change in attitude is all that is needed to take the focus off of me so that I can apply my skills to a greater cause. Sometimes a candid conversation with your boss starting with the question, “So, what’s keeping you up at night?” is enough to find that pet project that will enable you to use your problem solving skills, cure your boredom, and make your boss very happy.

One comment on “Field Guide for the Bored Programmer Part 1: The Dos

  1. More to follow, hopefully addressing the main point, but a quick off the cuff is that I didn’t see any of those comments link to their own blogs explaining how they solved the problem. As Hanselman has effectively said, blog post or it didn’t happen.

Leave a Reply

Your email address will not be published. Required fields are marked *