Conquering Boredom

There are a lot of reasons you could be bored. Below is a few of the things I do to conquer it without wasting my own time.

I have a list of ideas in an Evernote note that I wanted to get to but didn’t have time. Most offer just a little bit of a time sink that I can use to tune my ability. For instance, I’d like to add a feature to a small open-source Solr gem I wrote. It shouldn’t take me more then 15 minutes to do it right, and why not clone the repo and do it while I wait for something to build? The list of ideas I can work on is pretty extensive, ideas range from 5 minutes of work to full blown projects. I do generally leave the projects for when I can dedicate an afternoon or more to them. Though, I suppose you could break it apart into smaller pieces and think of the project that way.

Are you a software guy? Read about hardware. Hardware guy? Read about software. I’ve found that spending some downtime learning about Arduino has really helped me look at things differently. If you get bored with that, take a look at an interesting language. Most of them have a ‘Quick Start’ page that can take either a few minutes to read over, or a few hours. For instance, the Scala language guys have a Scala by Example PDF that is a few hundred pages and goes through a lot of the language. You won’t be an expert, but you’ll kill sometime without getting stupider.

Still bored? Read some RSS feeds. Subscribe to your languages mailing list. Subscribe to languages you find interesting mailing lists. Read Wikipedia pages about interesting topics. Read Hacker News. Do anything that will allow you to gain diversity in your knowledge. None of the things here will make you an expert, but you might find something interesting enough to develop into a skill you can use.

The Failure That Are ‘Roll Offs’

Projects that hire contractors are plagued.

They are plagued by ‘roll-offs.’ I am talking specifically about when a developer leaves the team, or is replaced by a new developer.

Sure, pairing mitigates the lose of knowledge but it doesn’t allow a developer to quickly step in to fill the gap left behind. A single developer’s knowledge split across multiple pairs doesn’t cause silos, it causes ghettos.

A ghetto defined in this context is something that makes it nearly impossible to find out which developer knows the best answer. The person who has the most context and can quickly answer the question could of just rolled off. Now what?

Take this scenario — you have a complex ETL process, and the developer who was the anchor on developing at has recently rolled off. Two weeks later, the process fails at 0300. The on-call developer picks up the trails and tracks the issue that woke them down to the ETL process. What does the developer do next?

What would you do next?