What You Think Vs. What You Know

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.
7. Trust, but verify.
8. Smart people test what they think to determine whether it is true.
9. 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 =) But 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 Things^tm!

Things go wrong when confidence transitions into a need to be the smartest person in the room. Who among us has not endured a person joining an ongoing conversation with, “Well, actually, it’s (fill in the blank).” Even when the statement is technically correct, it’s often missing the point. Or someone drawing a conclusion that, while being amusingly logical, is incorrect due to being based on incorrect or incomplete data.

Another danger in thinking you know everything is that you lose the appetite to learn and improve. Knowing that we cannot know how much we don’t know keeps us reading, keeps us experimenting, and keeps us pushing for even better ways to do things. Deceiving ourselves into thinking that we’ve learned all there is to learn keeps us stuck doing whatever we’ve done before. 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.

Remember that we’re trying to be helpful, not trying to waste your time or patronize¹. - Me

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 lose ten seconds while opening a closet. In the best case, you find your shirt and move on with life.

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 vision², 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.

So much effort and time could have been save 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. There are plenty of old sayings around this point, 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 think³. 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 called⁴. 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 some may find this annoying, but I feel that it’s helping the team to build a more accurate shared context. It’s very often followed by “Oh…”, and then that person is never annoyed by it again.

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.