Try that before reading on.
Although we’ve been talking a lot about harvesting great ideas, your ability to harvest thoughts and insights isn’t limited to Great Ideas. Your R-mode search engine can pattern match based on the merest fragment of a pattern to go on.
Cna yuo raed tihs?[67]
Aoccdrnig to rscheearch, it dseno’t mtaetr in waht oerdr the ltteres in a wrod are; the olny iproamtnt tihng is taht the frsit and lsat ltteer be in the rghit pclae. The rset can be a taotl mses, and you can sitll raed it whotuit a pboerlm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef but the wrod as a whloe. Azanmig…
Your mind is quite adept at reconstructing reality based on fragmentary patterns. It can make associations based on incomplete data, and it does so all the time, even if you’re not aware of it.
Here’s an example of patterns that you’ve probably experienced if you’re a programmer. Source code, even in its monospaced, fixed-width font, has typographic qualities to it that can help you understand the author’s intent.
Remember: source code is read many, many more times than it’s written, so it’s usually worth some effort to help make the code more human-readable. In other words, we should make the larger patterns in the code easier to see.
Code is write-once, read-many.
For instance, why do we use fixed-width fonts? The compiler doesn’t care. But we tend to want to align text, braces, and code:
| | String foofoo = 10 |
| | int bar = 5 |
to make it easier to scan and recognize. Similarly, you might tend to separate code blocks with character graphics, like this:
| | /*************************/ |
| | /** Something Important **/ |
| | /*************************/ |
That catches your attention and, when done regularly, becomes part of a larger pattern that your mind recognizes and latches on to. Reader Dierk Koenig tells us that he deliberately takes the time to “typeset” his code in this way.
Novices will start off doing this—it’s an easy rule to follow, after all. But advanced beginners may begin to push back, complaining that spending time on code layout is a waste of time. Proficients and experts will bristle at poor code if it’s harder for them to see the patterns they’re used to seeing, whatever those may be.
These visual cues may take many forms, such as alignment and header blocks as we’ve seen here, or even more subtle cues such as method size. Once you get used to seeing very small methods, with only a few lines of code, very long methods jump out at you as wrong.
Brace placement forms a visual pattern as well, which may explain why some folks will fight long and hard in favor of a particular style of brace placement in those languages that use curly braces. They aren’t being argumentative for the sake of argument; this sort of pattern matching affects their perception.
There’s a dark side to pattern matching in code, though. Consider this classic fragment from the venerable C language:
| | if (receivedHeartbeat()) |
| | resetWatchdog(); |
| | else |
| | notifyPresident(); |
| | launchNukes(); |
In this unfortunate case, launchNukes() will always be executed regardless of the value of receivedHeartbeat(). The indented code makes it nice and readable, but that’s not how the compiler sees it: only the first statement binds to the else; the indention is misleading. Typography has a powerful impact on perception—for better or for worse.
Try to aid visual perception by using consistent typographic cues. The compiler may not care, but we do. Be sensitive to this effect: if you’re at the higher skill levels and you’re encountering resistance from the rest of the team, understand that they literally don’t see it the same way you do. They won’t automatically appreciate the value; you’ll have to explain it to them.
Accommodate different skill levels.
If you don’t see the value in these patterns but more expert folks on your team do, humor them. Realize it’s not a waste of time on some foolish affectation but an important communication tool.
Many times it’s hard to see things that are right in front of you, because you get used to seeing patterns in a certain way. It’s easy to get stuck in a rut—to get stuck in certain thought patterns and accustomed ways of thinking. The trick to gaining insight is to try to see a problem from a completely different viewpoint.
The only difference between a rut and a grave is the dimensions.
For instance, here’s a question that might stump you (if you’re older than six): what do John the Baptist and Winnie the Pooh have in common? The answer[68] isn’t what you would normally think of. OK, it’s a stupid joke, but the point is that it’s an astoundingly literal answer in a context that you’re probably not used to.
The key to creativity and problem solving lies in finding different ways of looking at a problem. Different associations force the R-mode to initiate different searches; new material might now come up.
When faced with a thorny problem, Dave Thomas will often say, “Turn that on its head.” That’s one mental whack: a way to knock you out of your rut to make you look at a problem from a different point of view.
For instance, audio engineers use a well-known technique when mixing a recording. To make the sound as good as possible, they first go through and make each instrument sound as bad as possible. Make the saxophone honk abrasively, turn up the fret noise from the guitar, hum from the electric bass, and so on. Now reverse the settings: everything that you emphasized to make things sound bad, turn down or cut out to get to clean, sparkling sound.
That simple change of viewpoint, looking at the problem from the other way around, is by itself a very powerful technique. You can use that when debugging: instead of trying to prevent a difficult-to-find bug, try coming up with three to four ways to deliberately cause it. Along the way, you might discover what’s really happening. Or perhaps try the same thing with a user interface design: instead of trying to come up with the perfect layout or workflow, make the worst layout and workflow. That might help you home in on what’s really important.
Turn the problem around.
| Recipe 17 | Change your viewpoint to solve the problem. |
In A Whack on the Side of the Head [von98], Roger von Oech lists many different “whacks” such as these, including looking at something in reverse, exaggerating an idea, combining disparate ideas, and so on.
In addition to the whacks, he describes common mental locks that tend to block you from seeing alternatives. The locks include assuming there’s only one right answer, thinking that a given solution is not logical, or dismissing play as frivolous.
These are dangerous assumptions because they aren’t true, and they can actively impede your progress. Most problems have multiple solutions or multiple “right answers.” The one-right-answer idea probably was true only for grade-school arithmetic. Afraid a solution isn’t logical? Most of your brain processing isn’t logical either, but that doesn’t make it wrong. And the notion of “playing” with an idea is one of the most powerful tools we have. Non-goal-directed playing with an idea is where you’ll make connections, see relationships, and gain insights. It helps change your viewpoint.
Necessity is the mother of invention. Play is the father of invention.
➤ Roger von Oech
A great example of insight gained from changing your viewpoint appears in T. H. White’s The Once and Future King [Whi58]. In this story of Merlin the magician training the young King Arthur, Merlin transforms Arthur into different animals and birds so that he might experience the world in different ways.
At one point, young Arthur is learning to fly with the wild geese, flying high above the countryside. As a goose looking down on the landscape below, Arthur is struck with the insight that boundaries are artificial constructs: there are no painted lines on the ground showing kingdoms or countries. He begins to realize that all of England could be united under one king.
But you don’t have to actually transform into a bird as Arthur did; just imagining yourself as a bird (for instance) would have the same effect. From this different vantage point, your brain’s search engine will be forced to scrape up different ideas.
For example, imagine yourself as an integral component of the problem you’re working on: suppose you are the database query or the packet on the network. When you get tired of waiting in line, what will you do? Who would you tell?
In classical times, high priests of the temples would often consult an oracle[69] for advice. As with most fortune tellers or newspaper horoscopes, the response or message given by an oracle would typically be ambiguous, almost a riddle. You have to “interpret” it for yourself. That’s a whack on the side of your head.
It’s the same idea as in a paradoxical Zen koan, such as “What is the sound of one hand clapping?” Rationally, that doesn’t make any sense at all. The brain is forced to try to reconcile unlike patterns; this broadens the scope of material under consideration. On a more familiar note, think about playing the word game Scrabble. What do you do when you’re stuck and don’t see any obvious words to form? You rearrange the letters, hoping to see a new relationship.
Reconcile unlike patterns.
Composers Brian Eno and Peter Schmidt came up with a set of 100 oblique strategies[70] along these same lines. These questions and statements force you to draw analogies and to think more deeply about the problem. They are a great resource to draw on when you get stuck (and are available online, as a Dashboard Widget for Mac and iPhones, text versions for Palm OS, a command-line version for Linux, and so on). Here are some examples:
I particularly like that last one: perhaps your mistake wasn’t such a mistake after all. Freud would like that one, too.
Go grab the oblique strategies or some other oracle and see what it means to you today.
|
Try that before reading on. |
Some patterns are so unusual that they “wake your brain up.” That is, they actually overclock your brain (to use the CPU metaphor again) briefly to attend to this novel input.
For instance, kids make up awesome words. From active verb forms such as imaginate[71] to mash-ups such as prettiful and the curiously skewed flavoring (as in, “I’m not flavoring that food today”). It’s a pity that we adults don’t do more of this, because there’s more to these shifting word forms than meets the ear.
William Shakespeare engaged in a lot of this sort of verbal reengineering. In fact, he’s credited with coining quite a few phrases that we use to this day:[72]
In addition to adding new phrases to the lexicon, Shakespeare would repurpose certain key words to create a sense of wonder and surprise. For example, he might use a noun to serve as a verb (as in, “he godded me”). This technique, known as a functional shift, causes a sudden peak in brain activity.
Because it’s an unexpected input, the brain has to do some work to figure out the full meaning. But interestingly, researchers discovered that you’ll understand what the word means before understanding its function in the sentence.[73] This technique helps keep the text active and keeps the reader engaged—breaking the reader out of the usual rut of standard idioms and clichés. It’s a verbal whack on the head.
Although using a functional shift will create a brain burst in your readers, it will likely cause agita (that is, dyspepsia of the soul) on the part of one’s copy editor. But it’s still a very cleverful technique.