In 1826 Marc Isambard Brunel and Isambard Kingdom Brunel, a father and son engineering team, sought to build a tunnel under the Thames river in London. Their plan was fairly straight forward. They used screw jacks to push a giant, square, steel plate with holes in it through the mud. The muck oozed through the holes of this “tunneling shield” and laborers scooped it up and hauled it out of the tunnel. As the steel plate inched forward at only 10 inches per day, they laid a square, brick tunnel behind it. At this rate, it took the team 15 years to finish their 400 yard tunnel.
James Greathead and Peter Barlow came along in 1869 to attempt the same feat. They used a similar method, but instead of a flat, square, steel plate, they build a rounded stub-nose tunneling shield. Instead of digging a square tunnel lined with brick, they laid segments of cast-iron tubing behind their muck-pusher. It took them only 11 months to tunnel under the Thames.
The crucial difference in this design was the engineers' response to the resistance of the mud and water. The Brunels responded to resistance by pushing harder. They got more men and bigger jacks to push that square plate harder and harder into the mud. Greathead and Barlow pushed smarter. Barlow thought about himself swimming through the water and imagined the new tunneling shield design. He realized that as he swam, the shape he took on was essentially a tube. That identification led him to the stub nose tube shape that now criss-crosses London's underground.
Like Brunel, Greatheat, and Barlow, craftsmen of all kinds eventually find themselves stuck in the muck, slowly thrashing at 10 inches per day. The Software Craftsman's muck is the obscure compiler or runtime error; The code that just doesn't do what's expected and the hours lost trying to finding a solution.
In these moments, you can be like the Brunels and just keep pushing harder until you eventually come out on the other side of the river or you can take your cue from Greathead and Barlow and recast the problem, identify with the resistance, and then press forward again.
Richard Sennet, who wrote about the Thames tunnels in The Craftsman, identifies the two skills that craftsmen of all types need to overcome resistance in their trade: Recasting the problem and identifying with the resistance.
In my years as a software craftsman, I've been stuck in the muck a lot. Here are ten steps I've learned for recasting the problem and identifying with 'resistance' in order to keep pushing forward.
1) Read the Error Message
2) Seriously, Read the Error Message.
Too often, your eyes glaze over when you're confronted with a long stack trace or mounds of debug data. You start frantically trying all kinds of ridiculous things. You guess and you try again when all along your tools were telling you what was wrong. read the f-ing error message (rtfem!)
3) Check your notes of previously solved problems
When you encounter a weird or obscure problem, write it down in some kind of searchable tool (I use Evernote). Then check those notes. Maybe you've come across this before.
4) Google the “error you are getting”
Put the heart of the error message in quotes and google it. Be sure to remove anything that is specific to YOUR code (filenames, line numbers, classnames, etc.)
5) Read the results you find
6) Seriously, read the results!
Here's the thing about Google, it already finds the best results for you. It already, in the search results, provides a summary of the result. Read the summaries of the results. And when you find one that looks promising, read the entire article. Don't skim it. It will take “longer”, but if you slow down enough to actually read the result, you'll also slow down your frantic search for an answer. Maybe, just maybe, that will create the space between yourself and the problem that might allow you imagine yourself swimming across the Thames in a tube shape.
7) Ask your rubber duck.
Set a small rubber duck on top of your monitor. Explain your problem to the duck out loud. Yes, out loud. When you speak your resistance, you reframe it. You engage the language and listening parts of your brain. That might be enough for you to see an easy way through your muck-tunnel.
8) Ask a peer
If the duck doesn't have an answer, ask someone else on your team. Find a person in your particular tunnel who faces the same kinds of problems you do but sees them differently. Their perspective might help shift yours.
9) Ask an Expert
If your teammates haven't been able to clear your way, reach out to someone who has years of experience. Ask a mentor or post to a specialized forum, user group, or email list. This means humbling yourself, but humility is one of the core tenets of lifelong learning. Admit what you don't know.
10) Record your solution.
Write down the problem and resolution in your searchable notes. Better yet, blog about it and let the Googles do the indexing for you. Not to mention, it's also fun to google an error and see your own post on the topic from years ago.
Happy tunneling!
