From stage fright to the symphony; the master class and code review anxiety

This is a sales pitch. It's also about learning cultures, some very strange communication and classical music, so it will take a little while to get there.

If you can spare a few minutes of your day for something really interesting, take a look at this video of legendary music teacher Seymour Bernstein and Ben Laude spending 40 minutes drilling into the first three notes of Beethoven's Moonlight Sonata. 

I promise it will be worth your time. It's beautiful, surprisingly accessible, and for me at least, really difficult to watch. It's a particular, very specific feeling, and it's hard on the soul. 

If you've never seen one before, the "master class" instructional format can be bewildering. It has its roots in the traditions of music and theatre schools, the Royal Conservatories, Berklee's, and Julliards of the world. While they're attended by the entire class, sometimes the whole school, the typical format is just one or two selected students on stage, starting with a performance, then exploring and elaborating on the piece and the practice of music in conversation with the invited Maestro. 

These conversations are always interesting. Sir András Schiff asking a student who's just finished playing Bach's Italian Concerto "what is Italian about this?" before explaining that he'd like more colors, specifically primary colors. Maxim Vengerov explaining that you should play Mozart as though it is like psychology but also poker, that you shouldn't show your emotions in the opening hand. Rena Shereshevskaya explaining how a d-major chord is a golden color but if you approach it from a two-tonal direction, you should "play it as a different color". 

At their best these classes turn into protracted conversations about the shape and colors of music, the playfulness of cadence and flavors of emotion, the directions of energy emerging from subtle changes of posture. On first listen they seem like barely-comprehensible fits of multi-disciplinary synesthesia, right on the verge of being absolute nonsense. But somehow these conversations make so much sense that you can often see these wide-eyed students' moment of revelation, hear how these conversations change and grow the students' understanding and performance of the work.

There really is a sales pitch in here, but I bet you can see where this is going. We're getting there.

That "particular, specific feeling" I'm talking about, of course, is envy. 

We have no equivalent for the master class in the teaching or management of computing today. I deeply wish we did; I can see the signs of its absence everywhere.

And it's really strange that we don't! Patch review, stand-up, scrum, all of these and dozens, maybe hundreds of other parts of the software-creation process are almost the same shape, partly about the text and partly about the thoughts and feelings of the people around it. Have you ever felt nervous speaking about your work in a meeting full of senior engineers? As a novice or junior developer, how often did you hear senior engineers talking about the beauty or elegance of different approaches or solutions, about their favorite tools and the felt experience of using them? 

Programming is a performative, apprenticeship field. So why don't we have this? Why isn't this part of the routine? 

If you're still with me this far, you've probably guessed that I have a theory about that.

There are so many core skills in this field that we resolutely refuse not only to teach but believe are teachable that I suppose it's hardly a surprise that we have no equivalent for the master class experience. It's rare to see courses focused on debugging, testing or change management, for example, but approximately nobody is explicitly teaching students or junior engineers how to run meetings, give and receive feedback or review code. 

I don't think it's an accident that the skills we're avoiding are mostly the parts of the developer experience where people interact with other people. Not human-computer interaction, but human-human interaction with a computer in the room; the conversations that get past the decisions about algorithmic efficiency and deployment/recovery costs and into your entire sense of self-worth, the respect of your peers and leaders, the identity-threat problems.

You know; the part where someone you admire gets to tell you you're not up to par and show you specifically where you've screwed up. The part where you might be the reason somebody you enjoy working with quits the project or the company that day, where somebody you respect might be the reason you quit the field.

The terrifying part. 

My colleagues Dr. Carol Lee and Dr. Cat Hicks of our Developer Success Lab have recently published our Code Review Anxiety Workbook, and the findings are jaw-dropping. You can read the research backing up their intervention approach here. Part of what's surprising about it are the participants' stories of anxiety as the default setting of this industry. People talking about going their whole careers - in one case 65 worth years of career! - feeling anxious every single time they sit down to give or receive feedback.  

But the more surprising thing is how quickly the situation can be improved. A single workshop-style intervention can significantly reduce anxiety and improve self-compassion among its participants.

"Statistical analyses conducted by both Dr. Carol Lee and co-author Dr. Cat Hicks showed that the workshop was highly effective in lessening developers’ code review anxiety. It increased participants’ beliefs that they have the ability to face and manage their feelings of anxiety, and it increased participants’ self-compassion in the face of challenging code review situations."

So a default setting, but only a default setting. Maybe we don't need to live like this. Because what is code review anxiety, if not the developer's version of stagefright?

Ok, the sales pitch, here we go. Finally! 

I've talked about some of the joys of Flow before:

By starting with empirically- and morally-defensible metrics and measuring what really matters, the most interesting thing about Flow isn't seeing the data day-to-day. It's the cultural change that becomes possible by having real data day-to-day.

But one of the secret joys of Flow isn't about data driven change; it's about using Flow to decide what not to change.

With the tools we have today we can already say, we see a weakness here we can improve, we want to respond faster to review requests, we want to push for smaller patches or spend more time on requirements analysis to minimize rework, those are all on the table and easy to see. 

But it's possible that if we can change how we feel about how changing code - if we find the language and empathy we need to recognize our review-anxiety stage fright and put the worst of it behind us - then the next thing we can talk about is process, about how we make the music. 

Today - through Flow - an engineering leader can say, we would like to attempt this change, but if it comes at the cost of something else we value, we will change back. And these changes don't need to be all or nothing - we can get specific: "We are making this change to improve cycle time, but if this increases rework by more than 10% we will revert." 

This is pretty basic stuff, if you want to be deliberate about your culture informs your processes. It's table stakes, but it's a start.

But there's a possible future out there where we can see the processes that create the software in the same light as the software itself. Where we can put big-bang cultural changes behind us, the same way big-bang software releases are a thing of the past, and start talking about the continuous improvement of process and culture, about data-illuminated pathways and values-informed safety rails and regression tests. 

It's a ways off, but it's there. And maybe there's room on the far side of anxiety for conversations where our most experienced leaders can talk about the shapes and colors of our processes, the emotions of the people living them, and how we can measurably improve the lived experiences of both. Maybe by adding some more color to it; primary colors, you know? Maybe something golden. It's psychological, like poker. 

Carol's research is great, and if you click over to see it you'll find the Code Review Anxiety Workbook there so you can try it out yourself. It might take more than 40 minutes to work through, but if you'd like a team and maybe a life with a bit less anxiety in it, it will be worth your while. And if you want to talk about Flow, and maybe about data-driven cultural leadership and how we can help you can build safety rails around the changes you know you need, we should talk.