A Developer’s Thoughts on Developer Productivity

Oftentimes, we don’t hear from developers when we’re talking about developer productivity.  Most experts on developer productivity seem to be selling something rather than looking at how developers really work. 

At the end of the day, developers are system thinkers. They model and build systems, and often draw out diagrams to illustrate how those systems work. Why not take the same approach when looking at developer productivity? 

Starting with direct developer experience and using dev’s mental models of how they work is a much better approach. 

Developer Inner Loop and Outer Loop

While the traditional software development lifecycle (SDLC) does a good job of highlighting the numerous stages involved in bringing code to production, it leaves out the critical step of how the code is understood and written. 

For many, work as a developer is nested in two loops: 

1. An outer loop that roughly maps to the SDLC and happens at the level of sprints, projects, or releases. 
2. An inner loop that is read-write-run and happens many times per day when you’re in the middle of writing code, running tests, and iterating until you’re happy with your code.

Developers enter the inner loop when you get “close to the source” in the develop process, which happens at multiple points when they’re working in the outer loop, such as: 

• Onboarding to the code you’re about to change.
• Authoring a bug fix or new feature or bug fix.
• Fixing a test that broke in CI.
• Reviewing a patch or responding to a review.
• Debugging what went wrong in a failed deployment.
• Remediating an incident in production.

It’s important to talk about the inner loop; it’s the heart of software creation, after all. 

The Flow State

Laying within the inner loop is the golden state: Flow. Flow state refers to the state of focus and productivity anyone can attain when they have the perfect mix of inspiration and motivation. It’s when work becomes fun. 

In development, reaching the flow state accelerates the inner loop, but it takes uninterrupted time to achieve. Things like context switching and other interruptions can quickly take devs out of this state. 

Flow interruptions can be internal or external. An external interruption can include a scheduled meeting or impromptu question from a teammate. An internal interruption can be triggered by a necessary side quest, such as learning a library or tool, or resolving a blockage.  Sometimes they can’t be avoided. 

GitKraken’s Git tools are designed to keep developers in the flow state by reducing context switching and empowering developers to work in the tools they love. Try all of GitKraken’s tools free today: GitKraken Client for the desktop, GitLens for VS Code, and Git Integration for Jira. 

How to Measure Developer Productivity

How do you measure developer productivity? Aside from developers feeling “in the zone,” there are other data points we can look at, such as lines of code or commits made, but do these really measure productivity? 

At its core, software development is an innovative endeavor. Unlike physical manufacturing, the goal is to produce something that’s never been produced before. The automatic unit of innovation is iteration, which involves cycling through the inner loop. 

What if productivity was measured by one interaction of the inner loop? The unit we should be measuring is iteration frequency, not code quantity.