Programming, Fast and Slow


In 2012, Daniel Kahneman published “Thinking, Fast and Slow”. It’s one of those books that most Agile coaches and thinkers own, but very few have read. Because it’s not an easy read. It’s long, for a start. But it also goes into a lot of economics and psychology which, even for a popular science book, is hard. And it’s a book summarising a lifetime’s ground breaking, Nobel-prize-winning research. 

I read it over several months, and it was difficult. But I was already intrigued by these ideas. My brother lent me Julian Jaynes’ amazing “The Origin of Consciousness in the Breakdown of the Bicameral Mind” many years ago, and the idea that we function in a largely non-conscious way has been rattling around my head ever since. 

The central hypothesis of “Thinking, Fast and Slow” is that our minds have distinct subsystems that work In very different ways. Our conscious mind is System 2. It can reason, plan, learn. But it is expensive. It uses up lots of energy, so our minds avoid using it. Instead, we use System 1, which uses heuristics, is fast, irrational and full of shortcuts. It’s a great first-response mechanism to a complex rapidly evolving world. But it’s rubbish at making good long-term decisions.

When I read the book, I’d already been Mob Programming for a few years, and I knew there was some sort of connection, but I couldn’t put it into words. It’s really hard to think about thinking. 

If you’re driving, and you’ve been doing it for years, it’s System 1 that does the driving. If you’re driving home from work, you can probably do it on autopilot. You’ll be home before you know it. And if someone pulls out in front of you, System 1 shouts out “What an idiot? What were they thinking!”

But, if you come to a shared use junction, where no-one has priority, and pedestrians are allowed to walk across whenever, System 2 kicks in. You’re forced to think, to negotiate, to be aware. 

So, back to software. When I code by myself, I can stick my headphones on and code for hours. I zone out, and get into flow. I’ve been coding for decades, and I can do it using System 1. But System 1 is lazy and sloppy and does things that are just “good enough”. 

But when we Mob, we are forced to verbalise our ideas. To discuss them. To analyse them. We don’t get to just hammer out code. We have to be deliberate. We have to pay attention. And if we don’t, then someone else in the mob does. 

When we code solo, and we come across some badly written code, our first reaction, our System 1 reaction, is often “which idiot wrote this??” That would be bad enough, but System 1 lives in the moment. It doesn’t consider end-users of our code, or people that will be reading and maintaining our code. 

Deliberate practices such as TDD can help with this. They help to create high quality, maintainable, readable software despite System 1. 

But when we Mob, we engage System 2. We can empathise with people who wrote the code. We have a copy of Norm Kerth’s Prime Directive up in our mob area:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

And we get to remind eachother if we forget. That interaction helps us to empathise. And we are also better-places to empathise with our end-users, and with the people who will have to read and understand our code. 

Empathy

Mobbing encourages deliberate interaction and discussions about our code. This engages System 2. This in turn allows us to empathise more with the people who interact with our code and our product. 

We want our end-users to be able to use our products without thinking. Without having to engage their System 2. We want other developers to be able to read our code without having to think too hard. We want to reduce the cognitive load of the people who interact with our software. And the best way to do that is for us to activate our System 2 now, to write better software, and help others in the future. 

We empathise more when we are mobbing. We write better code when we are mobbing. We write empathetic code. 

Comments

Post a Comment

Popular posts from this blog

We always start from where we are

Image
Earlier on in this year, I had a really interesting discussion online with Duncan Hothersall about Scottish Independence, and Brexit. I support independence, and Duncan very much doesn't. Scotland is currently about evenly split between supporters and opponents of independence, with a small number of hardcore unionists and nationalists on either side. But many people are in the middle, and weigh up the decision based on the perceived pros and cons. In itself, this disagreement between Duncan and myself is interesting. We share a similar world-view and similar hopes for the future. We agree in many ways on the kind of future we would like to see. But we disagree on how we want to get there.  This is of course a common pattern. We often share a purpose with other people, but we disagree on the tactics or maybe even the strategy for how to achieve it, and there is a wealth of literature on how to resolve such disagreements.  But what I found fascinating was how we both responded to B
Read more

Mobodoro

On our mob, we have started using the “ Mobodoro ” technique, which I picked up from Willem Larsen at Hunter.  The idea is based on the “ Pomodoro ” technique, where you do 25 minutes of solid work, then take a five minute break. And repeat.  But with Mobodoro, we have a couple of minutes to plan, then we do repeat mob rotations of 2 or three minutes, adding up to 25 minutes. Then we do a quick retrospective on the previous 25 minutes, have a quick break, and then repeat.  And for the break, we have a rule that we have to leave the mobbing area. Even if we just walk a few feet and back.  The retrospectives have been great. Often we have nothing. Because we’re only retrospecting on the previous half hour. But quite often we find something small we can change: a better way of using our whiteboard; a new chair; changing the mob rotation time; buying some Lego to keep track of our work.  The day seems to go much more smoothly, and at a much more sustainable pace. Two or three minutes brea
Read more

Gilded Rose Katas

Image
Introduction Last Summer, I had the pleasure of bringing Amitai Schleier into my company for a few days, as part of his coding tour . One thing that really inspired me was his emphasis on a Learning Hour each day, and on using katas.  Katas are a short set-piece practices. The word “kata” comes from the Japanese martial arts tradition (形 - literally, "form") and is used to describe a regular repetitive, choreographed practice. Wikipedia gives a good description here  https://en.m.wikipedia.org/wiki/Kata . In software, there is a good collection of these set-pieces. Implementing FizzBuzz in a new language is a good example.  So, after Amitai’s visit, I started running katas every day. It took us a while to establish them, because we don’t have set starting or finishing times. But we now do half an hour of katas every day after lunch. We have used the time to look at TDD, TCR , Haskell, and we have used several well-known katas.  But the one we spent the lo
Read more