Developers’ Diverging Perceptions of Productivity

Understanding developer productivity from a “bottom-up” perspective.

I recently discovered the book Rethinking Productivity in Software Engineering, which contains a collection of essays on developer productivity perceptions. The book was written by a group of researchers during the 2017 "Dagstuhl" seminar on productivity in software engineering, a mastermind summit held at a castle in Germany.

This week I read one of the chapters from that book, ”Developers’ Diverging Perceptions on Productivity”, written by André N. Meyer, Gail C. Murphy, Thomas Fritz, and Thomas Zimmerman. This chapter summarizes three of their previous research studies (which I’ll cover individually in future newsletter issues) on developer productivity.

You can also listen to my interview with André about his research here. 

Key ideas from the chapter

André and his colleagues have spent years researching developer productivity from a “bottom-up” perspective, meaning they looked to define the individual developer’s productivity perceptions and then quantify productivity more broadly. The “top-down” perspective (or manager view) looks at the artifacts produced to measure productivity. (Note: this research was published before the SPACE framework, a paper that leverages quite a bit of André and his colleagues’ foundational work and which proposed a model for thinking about developer productivity that combines multiple perspectives.) 

Here are key findings from their previous research:

1. Developers spend 25% of their time at work on coding-related activities. 

One of their previous studies found that developers spend 25% of their total work time with coding-related activities and another 25% with collaborative activities such as meetings, e-mails, and instant messaging. (Note: These studies were conducted before the pandemic. With the shift to remove/hybrid work, this may have changed.)

André said, “We were surprised by this. We would have thought that developers spend the majority of their time coding or at least with coding-related activities. But that wasn’t the case, at least in the companies we studied. The reason is that there are many other parts of development work that people are not aware of.”

2. Developers have differing views on what it means to be productive. 

“No single activity is considered exclusively productive or unproductive by all developers. Coding, for instance, was not always considered to be a productive activity, for example when the developer was blocked on a task.” Meetings, context switches, and other collaboration activities were considered by some to be productive and by others to be unproductive. 

The authors further suggest that “measures or models that attempt to quantify productivity should take individual differences, such as the context of a developer’s workday, into account, and attempt to capture a developer’s work more holistically rather than reducing them to a single activity and one outcome measure.”

3. The most costly interruptions are those from coworkers. 

The authors prior research has found that developers’ days are highly fragmented: “When we looked at how much time developers spend on activities–actions they usually pursue at work (e.g., writing code, running tests, or writing an e-mail)–we found that developers switched tasks on average 13 times an hour.”

"Interruptions from coworkers are one of the most often mentioned reasons for costly context switches, especially when they happen at an inopportune moment, such as when a developer is focused on a challenging problem.”

4. Developers can be grouped into six categories based on their “ideal workdays”. 

“We found that developers can roughly be clustered into six groups of similar perceptions…” The six categories are: social developers, lone developers, focused developers, balanced developers, leading developers, and goal-oriented developers. (See the image below for descriptions, or read the descriptions in the chapter.)

Identifying these groups can help us understand the wide range of definitions of productivity, and how managers can better support their teams.

Final thoughts

I enjoyed reading this chapter of Rethinking Productivity in Software Engineering, and I would recommend checking out the rest of the book because it appears to be a goldmine of perspectives. The book is also an excellent portal into top research studies over the past couple decades, which I look forward to diving into in more depth in upcoming newsletters.

---

Other recommended reads

Elements of Internal Developer Platforms

Sid Palas, DevOps Directive

Elements of an Internal Developer Platform (IDP): 1) Treat the IDP like a product (get customer feedback, solve real problems), 2) Enable self-service (empower developers to get their code running without the need for intervention), and 3) Provide structure and standardization (standardize how resources are provisioned and configured).

Building personas for our customers (developers)

Max Pugliese, former Director of Developer Experience at IBM

“We have an internal developer advocacy team… it’s allowed us to build robust personas [for developers] to understand their constraints, where they have pressures coming from, and their own timelines and deadlines. By having personas we’re able to be build very specific and targeted backlog items.”

Things to know before you become a manager of managers

Lena Reinhard, engineering coach and former VP Engineering at CircleCI

Enjoyed reading Lena’s list of “30 things to know”, which has helpful reminders like this one: “More actively “pushing” and “pulling” information will become important. You’ll need to “push” context, updates, and information to your boss and stakeholders, and “pull” information from the broader business to make sure you get the context you need.”

---

That’s it for this week! Know someone who would enjoy this newsletter? Consider sharing it with them.

As always, reach out with thoughts about this newsletter on Twitter at @abinoda, or reply to this email.

-Abi