Embed Failing in Practice

A man’s errors are his portals of discovery.

➤ James Joyce, 1882--1941

Debugging is a part of life—not just software. Lawyers have to debug the law, mechanics debug cars, and psychiatrists debug us.

But let’s not be coy about it; we’re not removing “bugs” that somehow mysteriously crept into the system when we weren’t looking. Debugging means solving problems, generally of our own making. We’re identifying errors, mistakes, and oversights, and we’re correcting them. The value lies in learning from the error, which Papert sums up nicely: “Errors benefit us because they lead us to study what happened, to understand what went wrong, and, through understanding, to fix it.”

Perversely enough, failure is critical to success—not just any random failure; you need well-managed failure. You need the support of a good learning environment so you can more easily gain and apply experience from both your failures and your successes.

Not all mistakes arise from things you do; others come from things you didn’t do but should have done. For example, you’re reading along and come across the word rebarbative or horked, and you wonder what on Earth it means. Or perhaps you see a reference to a new technology you’ve never heard of or a famous author in your field you’ve never read. Look it up. Google it. Fill in the blanks. “I don’t know” is a fine answer, but don’t let it end there.

“I don’t know” is a good start.

We tend to think of failure or ignorance in a very negative light, as something to be avoided at all costs. But it’s not important to get it right the first time; it’s important to get it right the last time. In any nontrivial endeavor, you will make mistakes.

Exploration is “playing” in unfamiliar territory. You need to be able to explore freely in order to learn. But that exploration has to be relatively free from risk; you don’t ever want to be held back because you’re afraid to try something. You need to be able to explore even if you’re not sure where you’re headed. Similarly, you need to be free to invent—comfortable in the knowledge that what you create might not work out. Finally, you need to be able to apply what you’ve learned in your day-to-day practice. An efficient, supportive learning environment should allow you to do three things, safely: explore, invent, and apply.^[117]

Create an Exploratory Environment

However, you can’t explore, invent, or apply ideas within the environment of practice (on the job) until you make it safe for yourself, for your team, and for your organization. You wouldn’t want your heart surgeon to start your operation with, “Hmm, I’m going to try doing this left-handed today and see what happens.”

That wouldn’t be safe; a live and unsuspecting patient is not the right context for experimentation.

You can experiment out of the line of corporate fire, for instance, at home on an open source project. That at least reduces the risk of negative consequences. But that alone is not enough to create a positive learning environment for you. Whether it’s on a corporate team or a solo experiment in the dark watches of the night, you need the following:

Freedom to experiment

Few problems have a single, best solution. You could implement this next feature this way or that way; which do you choose? Both! If time is tight (and when isn’t it?), try at least a prototype each way. That’s experimentation, and you want to encourage it. Consider it part of “design time” when giving an estimate. You also need to make sure this experimentation doesn’t adversely affect anyone else on the team.

Ability to backtrack to a stable state

Safety means that when the experiment goes awry, you can go back to the halcyon days of last Tuesday, before you started making those dreadful changes. You want to revert to a previous, known state of your source code and try again. Remember, you want to get it right the last time.

Reproduce any work product as of any time

Backtracking to a previous version of the source code isn’t quite enough; you probably need to actually run the program (or work with any derivative work product) as of any point in history. Can you run a version of the program from last year or last month?

Ability to demonstrate progress

Finally, you can’t get anywhere without feedback. Did this experiment or that invention work better than the alternatives? How do you know? Is the project progressing? Do more functions work this week than worked last week? Somehow, you need to demonstrate fine-grained progress—to yourself as well as to others.

In software development, it’s pretty simple to set up an infrastructure to address these needs. It’s what we call the Starter Kit: version control, unit testing, and project automation.^[118]

• Version control stores every version of every file you work with. Whether you’re writing source code, articles, songs or poetry, version control acts as a giant Undo button for your work.^[119] Newer distributed version control systems such as Git or Mercurial are well-suited to support private experimentation.

• Unit testing provides you with a fine-grained set of regression tests. You can use unit test results to compare alternatives, and you can use them as a solid indication of progress.^[120] In any endeavor, you need objective feedback to measure progress. This is ours.

• Automation ties it all together and ensures that the trivial mechanics are taken care of in a reliable, repeatable manner.^[121]

This Starter Kit gives you the advantage of freedom to experiment, with comparatively little risk.

Of course, your team practices and culture have to allow this approach to exploration and invention. A supporting environment can make or break learning for anyone. Thich Nhat Hanh reminds us of the fundamental attribution error (described in Chapter 5, ​Debug Your Mind​); the problem is more often the environment, not the individual.

When you plant lettuce, if it does not grow well, you don’t blame the lettuce. You look for reasons it is not doing well. It may need fertilizer or more water or less sun. You never blame the lettuce.

➤ Thich Nhat Hanh

Next Actions

• If your software project isn’t set up with a safety net (version control, unit testing, and automation), you need to get that implemented right away. Put the book down. I’ll wait.

• Your personal learning projects need to have the same safety net—whether you are writing code, learning to paint, or exploring a colossal cave. Put the infrastructure and habits in place to make your project safe to explore.

• Do you know what halcyon means? Anthropomorphism? Ever hear of Nhat Hanh? Did you look them up? If not, what do you need to do to make this happen? (On the Mac, you can often Control-click [or right-click] a word and have the option to look it up in the dictionary or search using Google for that word. It’s quite handy.)