Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

Developer Productivity Report – Part 3: Developer Efficiency

*See the full series: Part 1: Developer Timesheet – Part 2: Developer Stress – Part 3: Developer Efficiency – Part 4: Deployment Pipeline

Don’t let me keep you from your work….

Our ongoing *cough* Developer Productivity Report has given us some valuable insight into what makes developers tick. In Part 1: Developer Timesheet, with commentary provided by Guest Geek Lincoln Baxter III, we took a deep look into how developers spend their days (SPOILER ALERT: only 3 hours each day is spent “writing code”).

In Part 2: Developer Stress, featuring Guest Geek Martijn “The Diabolical Developer” Verburg, we saw that developers are concerned about making deadlines, and their own code quality, continuing education and adherence to “best practices”.

In Part 3: Developer Efficiency, we look at what elements of the job contribute to or decrease efficiency at work. We asked over 1000 developers “What keeps you from doing your work?”, and the following are the Top 5 Show Stoppers at Work:


The majority of respondents felt that Too Much Multitasking was the primary reason for not getting work done. Over 1/3 of devs also mentioned that Boring Tasks where responsible for under-efficiency in the cubicle. This begs the question whether or not it is better to get “boring” tasks over and finished as quickly as possible, but this marketing droid understands how feeling uninspired to attack your work will lead to procrastination.

It is fair to conclude that Boring tasks, Bad management and Lack of motivation are indicative of a sizable gap in communication between management and development teams, or, more interestingly, a lack of self-management for organizing one’s time, one’s mind and one’s life.

Extended Interview with Guest Geek Matt Raible

We asked Matt Raible, Web architecture consultant, frequent speaker and father with a passion for skiing, mountain biking and good beer, to give us some of his insight on the factors that keep developers from finishing their work, so here we go!

ZT: Hey Matt, thanks for joining us. Hey, I heard this rumor that you are mostly Irish-Montanan?

MR: Yep, I grew up in the back woods of Montana with no electricity and I’m mostly Irish. So keep that in mind when asking me how I get things done at work.

ZT: Understood. So what do you think about issues regarding “Too much multitasking”?

MR: I’ve got a couple of suggestions that work for me:

  • Work disconnected. To further facilitate not checking e-mail or reading blogs, I’ve found that going to a coffee shop w/o connectivity is my most productive environment. They have liquid motivation in the form of coffee, and you can feed your brain with breakfast/lunch or some kind of snack. My most productive days are the ones where I show up at my local Einstein’s (bagel shop) at 6 a.m., have two cups of coffee, and work with my headphones on. After the coffee and uber-productivity, I often have an awesome ride to work and barely notice the miles. NOTE: I’ve found that I’m more productive writing code late at night and authoring articles/books in the early morning.
  • Stop reading e-mail, Twitter and Facebook. One of the ways I can tell I’m in uber-productive mode is my unread (or starred) mail piles up and I haven’t read any blog posts (or blogged myself) in a couple days.
  • Sleep. While working late nights can be productive in the short term, doing it consecutively will burn you out quickly. Getting a good night’s sleep can often lead to greater productivity because you’re refreshed and ready to go.

ZT: Yeah, sleep is nice. *yawn* …. Sorry, where were we? Ah, “Boring Tasks”. 

MR: Some tasks are boring and there is nothing really to do about it. I find that music can make a big difference and potentially grow some inspiration where it didn’t exist before. If you’ve got outside projects that you find more interesting, position them at the right time of day.

  • Listen to music while you work. Some noise-cancelling headphones and your favorite music can do wonders for your productivity. Of course, earbuds work just as well – whatever makes the music sound good. Good music can really help you “get into the groove” of what you’re working on, regardless of whether it’s writing or coding.
  • Work on open source late at night, with a beer on your desk. While I sometimes get the opportunity to work on open source at my day job, I still find that I’m most productive at night. Maybe this is because no one bugs me via e-mail or IM, or maybe it’s just because the world is asleep. The strange thing is I often find myself motivated at 3 p.m. for my 11 p.m. workload. However, when I get to 11 p.m., I’m not motivated to work on anything. I’ve found that cracking open a beer at 11 when I start helps me focus and quit worrying about all the other computer-related tasks I need to do.

ZT: What can you say about “Bad Management”? In your case, you deal with a lot of self-management for your time and resources…what can you tell us that would apply to both contractors and those of us working in teams?

MR: Yeah, what works great for me is to get used to non-standard work hours, and avoiding inefficient wastes of time.

  • Work long hours on Monday and Tuesday. This especially applies if you’re a contractor. If you can only bill 40 hours per week, working 12-14 hours on Monday can get you an early-departure on Friday. Furthermore, by staying late early in the week, you’ll get your productivity ball-rolling early. I’ve often heard the most productive work-day in a week is Wednesday.
  • Avoid meetings at all costs. Find a way to walk out of meetings that are unproductive, don’t concern you, or spiral into two co-workers bitching at each other. While meetings in general are a waste of time, some are worse than others. Establish your policy of walking out early on and folks will respect you have stuff to do. Of course, if you aren’t a noticeably productive individual, walking out of a meeting can be perceived as simply “not a team player”, which isn’t a good idea.

ZT: One of the responses was about “Buggy software”. Now, this could refer to buggy software that is being used or developed, but I rather think the latter.

MR: Yeah, I would assume they are talking about productivity inhibitors they use professionally. Well, I could make a suggestion that Java developers might enjoy – start using IntelliJ IDEA instead of other IDEs :-)

ZT: We’ll actually get to see how popular IntelliJ IDEA is compared to other IDEs in the final Developer Productivity Report 2012 … finally, Lack of motivation was cited as another factor preventing developers from being more efficient. Any final thoughts on that?

MR: Look, you have to work on something you’re passionate about. If you don’t like what you’re doing for a living, quit. Find a new job as soon as possible. It’s not about the money, it’s all about happiness. Of course, the best balance is both. It’s unlikely you’ll ever realize this until you have a job that sucks, but pays well. I think one of the most important catalysts for productivity is to be happy at your job. If you’re not happy at work, it’s unlikely you’re going to be inspired to be a more efficient person. Furthermore, if you like what you do, it’s not really “work” is it?

ZT: Our team definitely agrees with you here, Matt. Hey, thanks a lot for your time and contribution. We’ll see you in Madrid at Spring I/O in a couple days!

Final Notes

The findings from Part 1: Developer Timesheet showed us that devs spend less time than we might think actually “writing code”, and more time in meetings and filling out reports. Part 2: Developer Stress showed us that developers are acutely aware of their personal abilities and concerned with learning more in order to do their job better. Now we can see that the work environment, management style, self-discipline and finding ways to stay motivated are major factors in determining developer efficiency.

Stay tuned for the next part, where we shift focus from the Development side of things and check in on our friends in the Operations space – Part 4: Delivery Pipeline (or from code to app and back again).