[1/2] Developer Productivity for Humans, Part 6: Measuring Flow, Focus, and Friction for Developers (Category Management)

Recently I read with great interest article From the guys at Google on the topic of flow status, focus and friction, which prevents you from working efficiently. This article is from column "Developer Productivity" in the IEEE journal. In this article, the authors describe their approach something like this:

1. The authors wanted to focus on the perception of engineers two concepts: flow and friction.
2. To do this, they collected data directly from developers, including interviews, surveys, keeping diaries by developers.
3. Then they took this data and tried to connect the perception of engineers with the data from the logs — other researchers usually immediately began from this stage.
4. The researchers were able to create heuristics to transform signals from logs to metrics, which are significantly associated with flow, focus and friction.
5. Further, the authors rejected these metrics regarding self-reports of engineers and data from logs - this led to the conclusion that the metrics are still associated with the experience of engineers that was interesting to researchers.

Now a few details:

1. Conventional flow studies have suggested that context switches between instruments break this flow. The authors went from the goals of the engineers and showed that flow is preserved if the context of the problem is preserved. Read more about Measuring Developer Goals told earlier
2. From diary studies and follow-up interviews, it became clear that flow is more versatile than the authors thought. Engineers experience flow only if they are positive about the work they do. It can be not only code, but also other activities. (writing dock design, studying documentation, writing letters / messages, ...) When the flow state is reached, engineers can remain in it even with small distractions.
3. Further, the authors say that they could not identify how to determine the state of flow from the logs, but we can highlight the state of focused work. To do this, you need to see if engineers are engaged in communication tasks. (focus) loosely (focus).
4. The conceptual model looked something like this: focused work is needed to achieve flow, but it is not enough. At the same time, you can pull focus time out of the logs when engineers were working on connected tasks, but it is not a fact that this accurately reflects on focused work. To analyze the coherence of tasks, the guys used word2vec from the data from the logs
5. What went on was validation of what engineers filled out in surveys or in diary data with what the authors calculated about flow and focus from logs. As a result, the authors’ metrics showed a good relationship between perception and these metrics.

The story of the metric friction in the continuation of this review.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes