Let me explain a little. By the “closed mode” I mean the mode that we are in most of the time when we are at work. We have inside us a feeling that there’s lots to be done and we have to get on with it if we’re going to get through it all.

It’s an active (probably slightly anxious) mode, although the anxiety can be exciting and pleasurable. It’s a mode which we’re probably a little impatient, if only with ourselves. It has a little tension in it, not much humor. It’s a mode in which we’re very purposeful, and it’s a mode in which we can get very stressed and even a bit manic, but not creative.

If you’ve worked on a team making software, you’ve almost certainly heard the thought-terminating cliché, “That’s impossible” hastily uttered by a programmer. I know I’ve said it; I suspect we all have. Sometimes engineers blurt this out because a product manager is asking them to do something unsupported by system APIs; sometimes they really mean “It’s hard” or “It’s not worth it” or even just “I don’t want to.” And then other times they are afraid to admit that they just don’t know how to do what’s being asked of them, even if they have a nagging suspicion that it can be done.

Software engineers reject entire product ideas, categories of problems, and persistent bugs as completely impossible to tackle. What is it about the psychology of programmers that leads to this limitation of imagination? In Cleese’s model, it would seem that programmers are spending so much time in the “closed mode” that they get stuck there. So, what’s the alternative?

By contrast, the open mode, is a relaxed, expansive, less purposeful mode in which we’re probably more contemplative, more inclined to humor (which always accompanies a wider perspective) and, consequently, more playful.

It’s a mood in which curiosity for its own sake can operate because we’re not under pressure to get a specific thing done quickly. We can play, and that is what allows our natural creativity to surface.*

Programmers are problem-solvers, spending most of their day building, a task that demands they be in the closed mode, “wired in”. Implementing features to spec, tracking down and fixing bugs, and thinking like a computer are exercises in putting one’s head down and blocking out distractions, and are therefore incompatible with the open mode. When we train ourselves to see the world this precisely, dividing things into neat boxes and clear abstractions, it can hurt our ability to accept ideas outside our mental model. It’s why many programmers I’ve worked with have stories about tracking an inscrutable bug down to an unhandled condition in their code with a comment that reads // This should never happen. And it’s for just the same reason that many brilliant engineers dismissed ideas like the internet, real time direction-routing, and digital currency as impossible for decades before they were implemented. For a coder, there’s inherent anxiety in impossibiilty, anxiety that can push them toward surrender rather than creative problem-solving.

But during the earlier design and ideation stages of projects, before we start writing code, we need to remind ourselves and our teammates to remain open. Nothing’s decided, nothing’s set in stone, and therefore many things are possible that might not seem that way at first. The Waterfall model of development forces this openness to end when building begins, but newer software methodologies like agile development promote the idea that we should expect design iteration to continue during software construction and therefore allow for open mode thinking throughout a project.

Cleese also suggests ways to avoid choking off our creativity too early. He recommends collaborators establish as free an atmosphere as possible in the open mode. Improvisational comedians have a well-known shorthand for this kind of openness to whatever ideas are presented: “Yes, and”.

And never say anything to squash them either, never say “no” or “wrong” or “I don’t like that.” Always be positive, and build on what is being said:

• “Would it be even better if…”
• “I don’t quite understand that, can you just explain it again?”
• “Go on…”
• “What if…?”
• “Let’s pretend…”

Even if an idea that a coworker proposes is truly impossible, it can still have value. In Edward de Bono’s book Practical Thinking, he writes about the value of intermediate impossibles. Sometimes unrealistic ideas are just a step on the path toward something that will work brilliantly. For example, you might design an impossible sign-up screen that magically knows the user’s name and email, and then realize later in a brainstorm that you don’t need either piece of information at all and still end up with a great user experience. De Bono calls this lateral thinking. As opposed to logical thinking, which requires a linear progression of true statements (just like most computer programs), lateral thinking allows and even encourages impossible ideas as middle steps, as they often help us get to a better end result.

The use of an Intermediate Impossible is completely contrary to ordinary logical thinking in which you have to be right at each stage.

It doesn’t matter if the Intermediate Impossible is right or absurd, it can nevertheless be used as a stepping stone to another idea that is right.

As software makers, we could all stand to be more open to the impossible, especially given that the technology we create must help solve wicked problems outside our screens, like climate change, transportation, and healthcare, problems that will require immense creativity and teamwork. To overcome what seem like impossible tasks, we first need to believe that there might be a way to do so.

The next time you’re playing around with new ideas and someone tells you that they’re impossible, remind them of what John Cleese said, ”When you’re playing, nothing is wrong.”