For the last three years, I have thought often about why individual-level "explanations" of developers' ability, potential & productivity trouble me, and why I think they ultimately keep us from the things we most deeply want to understand and cultivate: software development problem-solving cultures
With Ana Hevesi, we came together as a scientist and an expert practitioner to propose a different model: a cumulative culture theory of developer problem-solving. Here it is written up as a preprint, which we hope can serve as an open access guide that melds scientific review with practitioner case study, a history of our conceptions of developer ability, and a call to action for a more inclusive future.
This is a wide-ranging review, because the models that we use to explain our own abilities and performance are deeply rooted in social, scientific, and industry histories, all of which mutually inform each other, not always knowingly. It's our hope that for those unfamiliar with the ideas of social learning and collective, cumulative culture, this can serve as an exciting introduction. For those well familiar, a validation of the evidence of their importance.
We propose that despite a conventional emphasis on individualistic explanations, developers’ problem-solving (and hence, many of the central innovation cycles in software) is better described as a cumulative culture where collective social learning (rather than solitary and isolated genius) plays a key role in the transmission of solutions, the scaffolding of individual productivity, and the overall velocity of innovation.
Despite a growing interest in describing software work as "sociotechnical," or otherwise adding in a social "layer" to technological conversations, there is still a chasm between what we call "technical" and what we call "social." This does not match the reality of how human beings work together to solve problems at scale. We are a species that works on the level of the planet and across generations. Software solutioning is part of this legacy and uses these abilities of ours.
I loved writing this one with Ana. AND it's a little scary to share this one. I mean, it's not every day you write a paper that you start with a Le Guin quote. :) But how we describe human abilities MATTERS, and it matters that we learn to see the implicit constraints and assumptions that trap this field, the beliefs that lead us to think we can exclude vast groups of people from technological collaboration and creativity based on the uneasy evidence of a poorly-defined laboratory task from the 1960s.
Software is global infrastructure, a pathway to economic opportunity, a symbol of human intelligence, a weapon or a tool depending on how we use it, a geopolitical force. Who gets to define what it means to be "good at software"? In my view, one powerful way forward is to begin to expand our minds to let go of old stereotypes about what programming "thinking" is, and begin to describe social as not secondary, nice to have, or distal, but as the mechanisms of our solutioning.
Science only exists if people see it. I pour time and effort into writing things like open access preprints, far more swiftly than the slow scientific publishing process, with the hope that these will reach someone who needs it. Sharing and amplifying work like this really directly helps me.
Here's our citation for now: Hicks, C. M., & Hevesi, A. (2024, November 21). A Cumulative Culture Theory for Developer Problem-Solving. https://doi.org/10.31234/osf.io/tfjyw
Oh, and if you follow me on bluesky (shoutout to the new home of online scientists!), you can enjoy some memes about it too :D