About 18 months ago, I noticed that my vertigo symptoms were changing. I brought a list of my symptoms and when things had started to change. I wrote about this and my choices in Making Difficult Choices.
If you are trying to solve a nasty problem in your code, tests or your projects, it’s the same idea. When was the last time something changed? You have an advantage over me. I bet you have version control over your sources, both code and tests. You even have a form of version control over your projects, and it’s not a Gantt chart. It’s your retrospectives, assuming you do them with regularity. If you perform retrospectives on a regular basis, you have an idea of what’s changed.
It’s a little more difficult to do version control or retrospectives on a human body. “You have the April 15 version of your gut, and the April 16 version of your eyes.” I don’t think so! If I ever manage to be the bionic woman, maybe.
If we train ourselves to observe, we can notice what has changed, and when. You might find this more difficult to do than it sounds.
In organizations, on projects, we can even purposefully try experiments, record the results, retrospect on them, and see if those experiments succeed. I like experiments. I experiment a lot in my work, for me. I suggest experiments to my clients. In my most recent book, Manage Your Job Search, I tried a different experiment with the way I brought it print. I’m very happy with my experiment.
When you try experiments and note what’s changed, you can start to solve problems in an adaptive and purposeful way. You can see what has succeeded, what you might need more data about, and what has failed.
Now the middle case, what you might need more data about, is the really interesting case. You probably need to break the problem into many smaller problems to solve. For my health, I track all kinds of data, when I work out, what I ate, my weight, when and how much I slept, and a lot more, because vertigo is such a strange condition. For debugging code, tests, your projects, who knows what you have to track? (I talk about this on Managing Product Development and in my books.)
Here’s a real example, a blast from my long-ago past. Many years ago, I tried to track down a problem in microcode. You might think this would be easy. It’s microcode, like assembly language. I had written it. I was intimately familiar with it. But no, I was stuck. In my defense, I was programming in parallel, multiple commands on one line in the microcode.
Did I ask for help? No, that would have made sense. (I was quite young, in my mid-20′s. Please excuse me for being foolish.)
Did I ask for code review? No, that would have made excellent sense. I knew everyone else was really busy. (I look back at those days and shake my head.)
Did I write more tests? Yes. I also made a chart in my engineering notebook about all the possible cases and what I tried. And, then, because this was before version control systems, I made a list of everything I tried, and everything I changed, as I changed it.
I only changed one thing at a time.
After several hours of debugging on my own, I managed to find the problem. I fixed it. Everything worked.
As I reflected on what caused the problem, I realized that I had made a small change before I left—late—the night before. Because I was still tired, I didn’t see the problem when I arrived at work that day.
It took me several more years to realize that overtime was bad for me. That mistake was not the only mistake I made due to overtime. I had a mental “ooooh” at the time. I think Jerry Weinberg calls this “ooooh” the “programmer’s theme song.” You don’t have to be a programmer to sing it. It’s also known now as a “face-palm.”
The first step is to notice that something has changed. If you then start to collect data, you can say, “What’s changed?” Now you have a place to start with your problem solving.
First, you have to notice.
So, what’s changed?