Empirical study on the relationship between developer’s working habits and efficiency (2018)

A tired developer that doesn’t produce a lot of working code

There’s plenty of evidence that suggests that working long or late hours is neither good for you nor your productivity, but that doesn’t stop most developers from doing it anyway. Rodriguez, Tanaka, and Kamei analysed the actual working habits of software developers and the effect that these habits have on their efficiency.

Why it matters

This is where I normally explain why I picked this paper by highlighting a particular problem or raising some question that has never been answered beforeIn a peer-reviewed work, of course..

This week’s paper is a bit different: it was originally submitted for the MSR 2018 Mining Challenge, which aims to bring researchers and practitioners together by letting them analyse a common dataset.

How the study was conducted

In this case that dataset is a set of repository and IDE interaction data that’s gathered from FeedBaG, which according to the challenge’s website is

a general-purpose interaction tracker for Visual Studio that is built as a plugin to JetBrains ReSharper framework

Don’t worry if that sounds a bit vague: all you need to know is that it contains data on the actions that were performed by 81 developers within their IDEs.

These actions include:

The authors use the timestamps of these two variables to determine whether certain working habits truly impact efficiency.

What discoveries were made

The authors look at the data from three different perspectives.

Day of the week

When grouping data by day of the week, it’s clear that:

Time of the day

Grouping data by hour of the day yields the following observations:

Continuous working time

Finally, grouping data by length of programming sessions shows that:

The important bits

  1. Long, uninterrupted programming sessions are more likely to happen on Saturdays
  2. Wednesday and Saturday seem to be the most efficient days for programming work
  3. Builds and/or tests runs tend to fail more often right before the end of working days, which is typically between 15:00 and 17:00
  4. Programming continuously for more than two hours correlates with higher build and/or test failure rates