It takes me a long time to write conclusions. This is true for science writing, not fiction writing. When I write fiction, I always know how it ends before I start a piece at all.
Not so with writing science. In science, I am much faster at scoping the beginning. Science could be seen as the process of scoping the beginning. Crafting the meticulous methods, setting it in place, and then hitting the button. Go. Conclusions are sneakier; conclusions have to build. Conclusions are a place for taking a deep breath and generalizing.
But I’ve had time for a few conclusions now. It’s been a year since I shared, under Catharsis, my research & evidence science consultancy, a white paper I named "It's like coding in the dark": The need for learning cultures within coding teams.
One conclusion a year on is that I loved working on this piece back then and I love it still. It was a speculative gamble at the time, a paper I believed in but also a new form of sharing with the world. I have led a lot of projects with Catharsis and most of them have been inside of organizations and with partnerships. With Coding in the Dark I chose to spend some months pursuing a side project, no money involved, no gatekeeping, just making something to share. There is no real model for “open source, citizen social science” like there is for open source software, but I was inspired by the values of makers and builders in tech, and I’ve always wanted to be more like that.
I could’ve, probably should’ve, named this paper Learning Debt. Learning debt was a key concept that I tried to name in this study and I love that it seemed to really hit with real teams and their struggles. Over the past year, I had the chance to give several talks and podcast interviews about the concept. That interest, community, and joy in discussing work is something I have often lacked in tech, and it is truly meaningful to me that came in response to something that I wrote and shared with no expectation and just the hope that perhaps someone would also think it was interesting. Even in this loud, saturated and crowded world, perhaps sometimes you can still put what you think out there and find some of your people.
Someone working inside of an engineering transformation team told me recently: “I always knew this mattered, I always felt it, and 'learning debt' helped me connect the dots and convince other people that it existed.” That’s the highest compliment I can imagine for applied research. I always want to work on things that people have experienced and know to be important. I see applied research as putting evidence behind those things that we have already seen make changes at other times, in other places, on other teams. Especially with qualitative research, I see the goal as translation.
A year on, I reflect on what else I could contribute to learning science for software teams. There are lots of projects I can imagine. One thing, lately, is motivation: a key factor for so many software teams yet a mystery to so many managers. I think social science could help. Like fiction writing, with science one does simply have to pick a place to end, rather than the ending. There is data involved in this Learning Debt project that I haven’t written down yet. Here’s one interesting piece: learning experiences can be contagious in software teams, in a way that I believe mirrors the things we’ve seen about peer to peer learning inside of large and distributed classrooms. Here's another interesting piece: so many senior engineers tell me they spend time helping teach their managers to manage. Perhaps because I consider myself a translator, I am always noticing other translators. That's an area of research I'd like to do more in.
There are many important social science factors that are relevant to software teams. Learning is only one of them: I chose to focus on learning in this particular paper, perhaps as a challenge to take the most “social science” feeling thing I knew and show how much it mattered in an industry that has a lot of implicit beliefs about what really counts as tech, STEM, rigorous problem-solving, "being a rockstar." I fundamentally believe the weight of evidence is that learning cultures and effort-focused, growth-oriented values drive innovation. Yet learning is the least believed, and the most revelatory human behavior I ever do studies on. It is the thing that we all need and the thing we are afraid to make time for.
My final sentence in the actual conclusion I wrote for the paper is: Focusing on code writers as learners brought to the surface the ways in which their environments failed to treat learning as a meaningful activity in code collaboration, and failed to design for it.
For the past year, I have been building a research agenda entirely about software teams and how they thrive, and I still believe that sentence. I see large contradictions in the things that the world claims to need from software development as an activity and the room we give software developers–who are human beings, and therefore solve problems in the ways that human being solve problems–to grow, and share, and learn. I see gaps in whether leaders in tech understand that code work is problem-solving. I hope that a year from now I will look back and be able to note some more steps in this direction. I think an important challenge is to keep imagining “what it would look like” if our environments really, truly, cared about our learning.
The most indelible impact from publishing Coding in the Dark is that it’s created a lot of connection for me inside of tech with other people working on exactly these questions. I am inspired and motivated and frankly, really moved by how many people care so deeply about learning in this industry. I am bolstered by feeling like being “a social scientist in tech” is just a little bit more possible than it was a year ago.