Work on developer productity can be sorted into five factors:
For our purposes here, we’ll imagine a developer a system that performs this sequence of tasks, ad infinitum:
In step 1, developers choose a task to work on, based on their own internalized (inherently lossy) copy of the organization’s and team’s goals and values, and the imperfect tools available to them to help them understand both what tasks are valuable, and how to interact with the codebases and systems available to them.
In step 2, developers choose the some part of the task to work on, until they are blocked on feedback from a computer or another human (for example, running a test).
In step 3, developers wait on feedback from the other system, typically accomplishing very little in the meantime.
Additionally, we need to recognize the inputs and outputs of this system:
Based on the model above, we can identify five dimensions for improvement, where the goal is to maximize the value created by the developer:
Clarity is the factor that encourages developer to choose tasks that align correctly with creating value. There are three main sub-dimensions here:
Efficiency defines how quickly developers are able to solve
problems given the tools they have. For example, a developer using
nano is going to be much less efficient than one using —
and skilled with —
vim any IDE, etc.
Leverage is the amount of impact that a given task has. For example, an extremely configuration-heavy specification that a developer must write each time they want to deploy a new service might feel productive to that developer, but if tooling could be written that would infer 95% of that configuration, the developer would have more Leverage.
Continuity is reflective of the amount of time that a developer spends waiting for feedback from other systems, computer or human. It is simply the proportion of time that a developer is not actively blocked. For example, waiting for tests, code review, server boot-up, and slow API requests are all examples of degraded Continuity.
This part might seem a little abstract at first. When trying to pay attention to something, we’re incessantly pulled in a bunch of different directions at once. There’s some research to suggest that our mental activity can be analyzed as individual Attentional Cycles.
When a developer is attempting to multi-task, their attention bounces back and forth between the task at hand and the other task (with some additional penalty due to context switching).
There are myriad ways Focus can be improved. For example: