David Ruttka

I make computers do things

What You Think vs. What You Know

| Comments

Me: Have you checked the closet?
5yo: No, I know it’s not there.
Me: But have you checked the closet?
5yo: Nooooo. I know it isn’t there.
Me: I hear you, but I want to know if you’ve actually looked.
(wife comes back with the missing shirt)
Me: Was it in the closet?
Wife: Yep.

As a result, we had a good discussion about the differences between knowing and thinking. It boiled down to these points.

  1. You didn’t know. You thought. There’s a difference.
  2. Not knowing is OK. It’s just one more thing you can learn.
  3. Indeed, smart people don’t know everything. They know there’s more to learn.
  4. Smart people consider helpful suggestions.
  5. Being adamant that you know when you don’t really know can make problems harder to solve.
  6. Just because someone says they know doesn’t mean that they know. Trust, but verify.
  7. Smart people test what they think until they know.
  8. Again, always, always remember that it’s ok to be wrong.

Verbosity Ahead. You could stop reading here and be fine.

Smart Doesn’t Mean You Know Everything

My 5yo is incredibly smart, and there’s no parental bias coloring that statement =) The problem is when her confidence transitions into a need to be the smartest person in the room. She often joins an ongoing conversation with, “Well, actually, it’s (fill in the blank).” Sometimes, she’s technically correct, but is missing the point. Other times, she has drawn an incorrect conclusion, but it’s amusingly logical based on the data that she has. Then, there are the times when she’s just making noise, trying to avoid looking like a person who doesn’t know something. As the old saying goes, it’s usually better to remain silent and appear ignorant than to speak up and remove all doubt.

This isn’t just my five year old. Many professionals (not excluding myself) do this because they confuse being vocal with looking smart, and they conflate being silent with appearing confused or uninformed. Sometimes we even chime in with something that isn’t even relevant, but it’s a data point that proves I Know Thingstm!

The other danger in thinking you know everything is that you lose the appetite to learn and improve. Knowing that you can’t even know how much you don’t know keeps you reading, keeps you experimenting, and keeps you pushing for even better ways to do things. Accepting that you’ve learned all there is to learn keeps you stuck doing whatever you’re doing. You may be the #1 ranked expert at frobbing the wizbangs, while everyone else has realized that wizbangs don’t even need to be frobbed anymore.

Smart People Accept Help

Just as my 5yo wouldn’t check the closet, many professionals refuse to accept a suggestion because they are sure that it’s wrong. As time passes and it becomes the last possible thing to try, it turns out to be the solution.

Consider that your team is probably trying to be helpful, so they probably have reason to believe that the idea is worth a shot. Why not consider what they’re offering? In the worst case, you spend ten seconds opening a closet. In the best case, you have your shirt.

My discussion with a 5yo put it a little something a little like this

Remember that we’re trying to be helpful, not trying to waste your time or patronize1. Listen.

Do Not Present Guesses As Facts

We hear a lot about how interrupting a dev is the worst thing you can do. Let’s consider that there might be something worse. You could send them on a wild goose chase by presenting a guess as if it was a vetted root cause analysis.

Guess liberally, but be clear that you’re guessing. Do not present your guesses as data. – @druttka

What if we took my kid’s confident statement of knowing the shirt wasn’t there at face value? The shirt would still be “lost”. We professionals often present our own guesses as facts. I can think of many times that a bug report came with a full analysis of when it started happening, why it was happening now, and what we needed to change to fix it. After a few hours of tunnel vision2, it was discovered that everything we “knew” was wrong. The timeline was off, the root cause didn’t even exist, and the proposed change was impossible because the code to change didn’t exist either.

The tunnel vision could have been avoided, and time saved, if the briefing had included a simple, humble, “I think”. Then the ideas would have been considered as ideas instead of taken as facts.

Test Assumptions

This brings us to the fundamental truth that we should always test assumptions. We all know the old saying that goes with this one, but we often forget to put it into practice. I’ve been trying to incorporate the following ideas into my thought process.

First, I try to remember to say “I think” if I just think3. If I do have evidence or reasoning, I try to remember to say “because (evidence or reasoning).” This helps the other person take what I’m saying for what it’s worth, not as hard truth. I also ask them to confirm what I’m saying, since I could be wrong.

Second, I add a silent “I think” to what others tell me unless or until they say “because (evidence or reasoning).” Even when they present evidence or reasoning, I try to hold off on accepting it as truth until I can confirm it in the same way I’d expect them to confirm anything I told them.

Third, I’m getting more liberal with asking “How do we know that?” It works well in combination with the point above because it prompts a person to voice their evidence or reasoning. Then we can vet it together. For example, if I sit down to pair with someone who has been investigating a problem, they might say, “We know this is being called.” I will usually be the kind of person who asks how we know it’s called4. If the response is “Because we see this text on a button changing,” I will be the kind of person who asks “Is that the only thing that changes the button text?” I’m aware that this could come across as annoying, but it’s often followed by “Oh…”. The realization is not always directly related, but sending the train of thought down the right track is still a positive outcome.

I guess the tl;dr on all of this is that problems can be more easily solved if we are careful to separate what we know from what we think. All the rest would flow naturally in a healthy, functioning team.


Footnotes

  1. If this is not the case, you might need a new team.
  2. I’ve talked more about tunnel vision in problem solving here and here. Will covers it here.
  3. I was once given advice that “I think” is a bad thing to say. Lacks commitment, looks weak, etc. I have come to respectfully disagree.
  4. Did we log something? Set a breakpoint? Make a change and see it reflected on the next run?

Comments