Paper Jam #2 Recap: Developer Thriving
Context: once a month, I meet with subscribers to the Paper Jam plan of my blog to discuss a paper at the intersection of topics such as computer-supported collaborative work, software engineering, human-computer interaction, and psychology. This post reports on Paper Jam #2.
On February 14, we came together for the second ever Paper Jam, this month discussing Developer Thriving: Four Sociocognitive Factors That Create Resilient Productivity on Software Teams by Catherine M. Hicks, Carol S. Lee, and Morgan Ramsey (2024).
From Human Thriving to Developer Thriving
In their paper, the authors adapt ideas from Human Thriving, customizing them to be specific to software developers as a framework for Developer Thriving. They also report on the results of a quantitive survey that they ran based on their framework.
Personally, apart from adding a novel perspective, I was especially interested in this framework's parallels to Self-Determination Theory — the theory of human motivation that I read about and cited heavily in my PhD thesis on how we can support developers in using good engineering practices. Turns out: the cited Human Thriving paper does mention that some aspects of it are grounded in Self-Determination Theory and its three basic psychological needs — autonomy, competence, and relatedness.
Similarly, the Developer Thriving framework mentions four factors: agency, motivation and self-efficacy, learning culture, as well as support and belonging.
In their survey, the authors explore how two other factors they identified in literature correlate with developer thriving: 1) visibility and value of work, and 2) healthy metrics use (HMU).
Correlation, Not Causation
The authors then use a mediation analysis to analyze to what degree their chosen variables influence – mediate – developer thriving and (self-perceived) developer productivity. None of us on the call were intimately familiar with the method, but it became clear that unfortunately at least in this case, only correlations — as opposed to causal relationships — could be shown.
In our discussion, we were a bit confused about some of the phrasings in parts of the paper that to us seemed to imply causal relationships, but ultimately were ruled out as part of the Limitations section at the end. From our understanding of mediation analysis, a pure survey-based setup like this one can only ever show correlations, as 1) none of the mediating variables are being actively changed and 2) there's no temporal precedence between the variables.
All that being said, none of us are statisticians, so take this with a grain of salt. 😊
Qualitative Questions
In our discussion, we noticed that some of us would have liked to understand the constructs of "visibility and value of work", "healthy metrics use", and "developer productivity" better. In the survey, these were all left to individual interpretation and estimation.
A qualitative study that digs into developers' perceptions of what these constructs mean to them personally could be a fascinating and valuable next step.
What do developers mean when they say they felt productive over the last month? What do developers themselves consider to be healthy metrics use? What is seen as unhealthy, and for what reasons? We'd love to see research on this.
The Value of Connection
Apart from the many ideas for future research, to us, one of the paper's valuable contributions were the survey questions from the supplemental material. One of us mentioned that they're good prompts when interviewing for a new job – asking these questions in interviews might be a nice way to learn more about the company culture.
Plus, they could be a good starting point for designing an internal developer thriving survey.
The most animated discussion developed, though, when we went back to talk about the different aspects of the Developer Thriving framework. Both the learning and belonging aspects resonated very strongly with everyone on the call.
These cover crucial parts of the experience of making software — such as learning new skills, being able to share what we learn with our peers, being supported by colleagues, and supporting them ourselves.
We all agreed that one of the most enjoyable and valuable aspects of being a software developer is learning and making something with others.
And, finally, we realized: in a fun meta twist, that's exactly what Paper Jams are for — and why we enjoy them.
Want to take part in the next Paper Jam? We'd love to have you. Sign up here: