Check your assumptions

In Computational thinking and life skills I asked myself how to generalize this touchstone principle from computer science:

Focus on understanding why the program is doing what it’s doing, rather than why it’s not doing what you wanted it to.

And here’s what I came up with:

Focus on understanding why your spouse or child or friend or political adversary is doing what he or she is doing, rather than why he or she is not doing what you wanted him or her to.

I’ve been working on that. It’s been a pleasant surprise to find that Facebook can be a useful sandbox in which to practice the technique. I keep channels of communication open to people who hold wildly different political views. It’s tempting to argue with, or suppress, some of them. Instead I listen and observe and try to understand the needs and desires that motivate utterances I find abhorrent.

My daughter, a newly-minted Master of Social Work, will soon be doing that for a living. She’s starting a new job as a dialogue facilitator. How do you nurture conversations that bridge cultures and ideologies? It’s important and fascinating work. And I suspect there are some other computational principles that can helpfully generalize to support it.

Here’s one: Encourage people to articulate and test their assumptions. In the software world, this technique was a revelation that’s led to a revolution in how we create and manage complex evolving systems. The tagline is test-driven development (TDD), and it works like this. You don’t just assume that a piece of code you wrote will do what you expect. You write corresponding tests that prove, for a range of conditions, that it does what you expect.

The technique is simple but profound. One of its early proponents, Kent Beck, has said of its genesis (I’m paraphrasing from a talk I heard but can’t find):

I was stumped, the system wasn’t working, I didn’t know what else to do, so I began writing tests for some of the most primitive methods in the system, things that were so simple and obvious that they couldn’t possible be wrong, and there couldn’t possibly be any reason to verify them with tests. But some of them were wrong, and those tests helped me get the system working again.

Another early proponent of TDD, Ward Cunningham, stresses the resilience of a system that’s well-supported by a suite of tests. In the era of cloud-based software services we don’t ship code on plastic discs once in a while, we continuously evolve the systems we’re building while they’re in use. That wouldn’t be safe or sane if we weren’t continuously testing the software to make sure it keeps doing what we expect even as we change and improve it.

Before you can test anything, though, you need to articulate the assumption that you’re testing. And that’s a valuable skill you can apply in many domains.


Assumption: The URL points to a calendar.

Tests: Does the URL even work? If so, does it point to a valid calendar?

Interpersonal relationships

Assumption: You wouldn’t want to [watch that movie, go to that restaurant, take a walk].

Tests: I thought you wouldn’t want to [watch that movie, go to that restaurant, take a walk] but I shouldn’t assume, I should ask: Would you?

Tribal discourse

Assumption: They want to [take away our guns, proliferate guns].

Tests: ?

I’ll leave the last one as an exercise for the reader. If you feel strongly about that debate (or another) try asking yourself two questions. What do I assume about the opposing viewpoint? How might I test that assumption?

Posted in .

4 thoughts on “Check your assumptions

  1. interpersonally, I try quite hard not to make too many assumptions because I hate so much being on the end of them. Asking the meta question of what are you trying to achieve (&sometimes why) gets more interesting and usually more optimal results…

  2. I had an in depth conversation with my wife (who’s a child psychologist) about this post as psychology is increasingly moving to evidence based techniques. The essence of the conversation was around having unit tests during counselling sessions, e.g. check you’re assumptions that the client wants to be helped with their depression: “do you feel ready to talk about the emotions that are depressing you?”… Psychologists have had these types if unit tests in place for years, they just aren’t as quantitative as we’d like (yet).

    Being a computer scientist myself it often strikes me how we are continually trying to engineer brains in our systems, metaphorically. While psychologists are trying to reverse engineer the brain. Bare with me, a question is coming (apologies).

    This also brought our conversation onto the topic of your fourth ‘R’ pRogramming. Perhaps your interest for children gaining programming skills, needs to be considered alongside the skills they need for emotional intelligence, e.g. Reasoning their emotions, which psychologists are increasingly seeing a need to put into the curriculum instead of more route knowledge like reading, writing and arithmetic.

    In short, do you feel that pRomgramming is more significant than emotional Reasoning, if we are going to have a fourth R or should we be looking to combine theses two R skill sets, as they offer in programmatically reasoning our ‘brains’?

Leave a Reply