Doubt

Posted by bob on August 1, 2024

Doubt is both a marvelous and a terrible feeling.

When you doubt your conclusions about a problem, you are forced to go back and challenge your assumptions. You have to check your math and your incoming data. Sometimes you have to check your most sacred constraints: did the customer actually ask for this or did you interpret their request to fit your view of the world? I have certainly seen a little doubt make a project slam to a halt while every single item was re-examined and every controlling document re-read.

In some cases, it becomes important to go back and independently document (again) the general outlines and detailed knowledge of the problem.

Of course it is possible to blow up a tiny doubt into a complete panic. This is when doubt becomes terrible. You might stop trusting your experience, intuition, and common sense.

As in everything, balance and moderation are your best tools to manage doubt.

A couple of years ago, during a conversation with my son, we came to a conclusion that made me say, “Hey, that is useful. Please send me an email with what we just said.”

He sent this to me: “The less you know or are willing to find out--and the less you write down-- about a problem, the worse your solutions will be.”

I think we all know this guy. He is the cowboy who shoots from the hip without any understanding. The manager who thinks the only solution to every problem is to assign additional people. Or maybe they set a deadline without consideration for the tasks you must complete to finish your thorough review and project reboot.

Likewise, one of us could be the hardware guy who only knows how to blame the software guy; and vice-versa.

In An Engineer’s Guide to Solving Problems and these blog posts, I have suggested several steps that help with doubt, especially when it becomes overwhelming.

  • Don’t panic.
  • Write stuff down, including the basic assumptions you might need to challenge.
  • Try explaining the problem to somebody who is not involved or doesn’t care. Software engineers call this “rubber ducking” because they say that the process of explaining the problem to an inanimate object (like a rubber duck toy) can suddenly help you see something you missed before.
  • Think about ways to get better visibility of what is going on in the system with the problem.
    • If I could see it, I could fix it.
    • In hardware and in software, this usually requires “instrumenting” the problem.

Ultimately, doubt is that nagging voice in the back of your head that says, “This system could be better.”

Doubt drives us towards perfection, even though we know we will never completely get there. All of the steps we take to help remove doubt also give us the confidence to release a project when it is good enough. Or at least, the solution is good enough for now.