The joy of debugging... ourselves Laurent Bossavit Twitter:@Morendil Hi! My name is Laurent. 

Life would be so much simpler if only we had the source code I'm currently working as an Agile coach for the French government. Primarily though, I think of myself as a programmer. Even though it's been a while since I was paid explicitly to code, I think about what it means to be programmer all the time and I think about pretty much everything in terms of programming. Here's a joke I like because it captures that attitude: "Life would be so much simpler if only we had the source code." 

Programming, especially as something you do for a living, has a light and a dark side. 

Like many, I discovered programming when I was a kid, decided that was my life, and never looked back. Programming opens infinite worlds. It can be a lot of fun, and many of us are happy not only to code all day long, but to keep coding when they get home, evenings and week-ends. 

But programming can also have its dark side. Like many of us here, I have also experienced frustration, pain, and some periods of burnout and even outright depression. 

If you have experienced this, you must have wondered why. (A lot of this talk will be about asking "why".) 

Many of us tend to blame the pain, with some justification, on stupid processes like the big bad Waterfall, or on bad pointy haired management. 

We've tried to come up with answers, such as Agile and Craftsmanship and Test-Driven Development. 

I have a simpler explanation: much of what makes programming painful is - bugs. Bugs are one thing people really don't understand about programmers, as this story that popped up recently on my Twitter shows. 

Why do we spend so much time getting the bugs out, why can't we just not put them in to start with? 

Theory 1. write code, putting bugs in it 2. remove the bugs 3. profit To get an answer, we have to start by not calling them "bugs". This has all sorts of bad connotations, starting with the notion of insects that creep into our programs when our backs are turned. And more fundamentally, the notion that a bug is a "thing". 

Reality It's more useful to ask about actions, about processes: programming and debugging. 

“Bugs in the code start as bugs in the brain” The theory that works for me - sometimes I dare refer to it as "Bossavit's Law", because as far as I can tell I'm the first to put it that way - is that bugs in the code come from bugs in the brain. 

Notice what debugging involves: • history (how things got the way they are) • models (explanations) • beliefs, hypotheses about causes and scenarios • ...i.e. what we do with our brains. Debugging often takes a lot of time because we must investigate how we got into a particular state; have some theory of how things were supposed to work; search for assumptions that may have been incorrectly made; formulate hypotheses about how we got into an unintended state; test these hypotheses. We do all those things by running some software, which we call the mind, on a wonderful piece of hardware, which we call the brain. So my conclusion is, you can't understand the process of debugging if you don't know a few things about the brain. (When people marvel about the wonders of "computers", they don't distinguish software and hardware, so to keep things simple I'll refer to "the brain" meaning both mind and brain.) 

• “Confirmation bias” - the tendency to seek evidence which confirms our beliefs and dismiss that which challenges them • Well-known to testers; one of the justifications for the (invalid) “axiom” that programmers shouldn’t test their own code For instance, one thing which is well attested to complicate the debugging process is confirmation bias. This is our tendency to seek evidence which confirms our beliefs and dismiss evidence which challenges them. Or to put it in even simpler terms: we tend to believe what we want to believe, not what is true. Testers tend to be well aware of this as an issue, sometimes to the extreme extent of suggesting that programmers "shouldn't test their own code". 

Confirmation bias in the industry Our industry also suffers from confirmation bias, by the way. I wrote an entire book about how the software profession is riddled with myths, such as the 10x programmers, the cone of uncertainty, the exponential cost of defects curve, or the history of waterfall. 

Let's ask why again, then. Why are our brains built that way? 

The source code? It turns out that getting an answer required the surprising insight that - in a way - we do have the source code to Life. Darwin first figured out the algorithm, and Crick and Watson later completed one of the grandest insights in science by discovering the implementation. (By now you know I wasn't kidding when I said earlier I think of pretty much everything in terms of programming.) 

Evolutionary psychology is the scientific discipline that studies how natural selection and evolution explain features of the brain. One fantastic book to get introduced to that discipline is Kahneman's "Thinking fast and slow". Kahnemann distinguishes between the "fast and frugal" System 1, which tends to jump to conclusions and stick to them; and System 2, which is our deliberative reasoning system, the one we are supposed to use when we code. 

Some of you may know the evolutionary story explaining the history of System 1: the cliché is that you're walking through the Savannah, when out of the corner of an eye you spot an ambiguous shape in the grass. If your first thought is "It's a lion, drop everything and RUN!" the worst that happens is losing the rabbit you caught for dinner. If you stick around to enumerate all the possible animals it could be, zebra, gazelle, and so on and come to a careful reasoned conclusion that - well, too late, you've been eaten. Evolution therefore favored the first kind of behaviour. 

Mercier and Sperber, “Why do humans reason?” It's less well known that System 2 also has a fascinating evolutionary explanation. People tend to assume we have this high-level reasoning system just because we're very smart. That's a mistake. Mercier and Sperber (an American and a Frenchman, respectively) say that we evolved deliberative reasoning - the explicit construction of conclusions based on premises - essentially to defend ourselves against liars. As soon as communication and language evolved, basically, people would have started going around telling you "Give me that rabbit you got for dinner, I need it more than you do." If you always agreed, you would starve, so people whose genes weren't programmed to counter-argue tended not to pass on those genes. 

Two surprising insights Reasoning is more often a bug than a feature. Depression is a feature, not a bug. Here are two depressing conclusions. First, our capacity to reason isn't always good news. Mercier and Sperber point out that we are not programmed to use our reasoning capacity to find the truth: we are programmed to use it to justify decisions we have already taken, like keeping that rabbit. Their research suggested that reasoning doesn't help people when deciding; it directs people to the decisions that will be easily justified, not to the best decisions! And the smarter you are, the better you are at justifying bad decisions. This may remind you of some problems you've had with management. 

Andrews and Thompson, “The bright side of being blue: depression as an adaptation for analyzing complex problems” Another bit of bad news about System 2 comes from research in the psychology of emotions. It suggests that analytical thought is enhanced in people with depression. It's basically how your brain copes with a very, very complex situation: it tells you to stay in bed to save energy, to spend all your time thinking about just one problem, and to not have fun with anything because that would distract you from thinking. 

I'm telling you this not just to share my excitement with these fascinating insights. It has affected me personally: when I was researching biases and why there seemed to be so little rationality in how the software community adopted practices, I ended up seriously depressed. I'm not saying there was a cause and effect relationship. But in any case it got me curious about one more thing; what makes programming fun? What would contribute to my being happier? 

Hurley, Dennett and Adams' theory of humor is the latest evo-psych insight that blew my mind completely. 

“We adore babies because they’re so cute.And, of course, we are amused by jokes because they are funny?.. This is all backwards! It is. And Darwin shows us why.” -- Dennett In that view, much as it's a mistake to think that babies are intrinsically cute, it's a mistake to think of anything as intrinsically funny. Rather, we are programmed by evolution to see babies as cute, because the genes that prompt us to care well for babies get passed on more readily than genes that don't. Evolution rewards taking care of babies even though it's often a dirty jobs, as all parents in the audience will know. In the same way, humor is a positive emotion that encourages doing a specific job. And that job, surprisingly, is debugging. When you tell a joke, you introduce lots and lots of unseen assumptions. The hearer of a joke endorses these assumptions. And then, just as the saying goes, "when you assume, it makes an ass of u and me" - the punchline replaces one or more assumptions with an equally valid alternative, which makes you feel foolish for believing the initial assumptions - but at the same time, you get this kick of reward from your brain. We get a kick, evolutionarily programmed, out of debugging ourselves - noticing our own mistakes. There's a whole range of positive emotions associated with things we tend to shun: being wrong, failing. 

In that view, much as it's a mistake to think that babies are intrinsically cute, it's a mistake to think of anything as intrinsically funny. Rather, we are programmed by evolution to see babies as cute, because the genes that prompt us to care well for babies get passed on more readily than genes that don't. Evolution rewards taking care of babies even though it's often a dirty jobs, as all parents in the audience will know. 

A senior citizen was driving down the freeway when his wife called his cell phone. ''Herman, be careful! I just heard on the radio that there was a madman driving the wrong way on Route 280!'' Herman: ''A madman? It’s way worse! There’s hundreds of them!" In the same way, humor is a positive emotion that encourages doing a specific job. And that job, surprisingly, is debugging. When you tell a joke, you introduce lots and lots of unseen assumptions. The hearer of a joke endorses these assumptions. And then, just as the saying goes, "when you assume, it makes an ass of u and me" - the punchline replaces one or more assumptions with an equally valid alternative, which makes you feel foolish for believing the initial assumptions - but at the same time, you get this kick of reward from your brain. We get a kick, evolutionarily programmed, out of debugging ourselves - noticing our own mistakes. There's a whole range of positive emotions associated with things we tend to shun: being wrong, failing. Whether we experience them as positive may be a matter of framing: seeing the humor in what we get wrong; enjoying our debugging episodes. Also, they may well be a matter of taking care of the human side of ourselves. Enjoying being around people. Exercising, sleep, eating better. Better self-care is how I recovered from depression. I'm experimenting with meditation, which, as I understand it, seems to be a sort of debugger for the brain. 

So: what have we learned? 

Practical tips & take-aways See a doctor if it’s bad. Sleep more. Exercise. Spend time with friends. Meditate (maybe) And... You may be a little disappointed with this, because in a way this talk has been a big build-up of the question "How do I make programming more fun?" And the answers I just gave you are quite mundane, ordinary. But isn't debugging often like that? After hours of chasing down a bug, the ultimate answer is often a little trivial. The fun is mostly in the chase. But there’s one more thing. 

Be ever curious, ever the explorers The one somewhat surprising conclusion I've come to is that I value the fun and the exploration at least as much, perhaps more, than I value being right. I'm still a big fan of Test-Driven Development, but I now know that it cannot completely replace debugging, ever - because debugging is just another name for what we also know as the "scientific method", but in which we should really recognize a primary evolutionary drive: curiosity, the urge to learn about the unknown. It is curiosity which drives us out of our comfort zones, helps us respond with humor when we recognize our mistakes and wrong beliefs. 

So, let's just debug all the things. 

Merci! Thank you. 

You must have questions ;)