The other day, I was tasked with figuring out why a particular error was flooding our logs — tens of thousands of occurrences. An interesting challenge for sure, especially given that our codebase depends on a maze of internal and external services and libraries. The error itself hinted that this was going to require some serious digging.

Down the rabbit hole#

So I rolled up my sleeves and got to work, with my favorite LLM by my side — yes, I’m talking about Claude. Not so much for the reasoning (last I checked, I can still do that myself), but for its ability to tear through massive codebases at lightning speed. It’s like having someone who can find the needle in the haystack before you’ve even finished describing the needle.

As usual, it quickly zeroed in on the interesting spots. From there, it became a back-and-forth: I’d form hypotheses and suggest leads for it to investigate, and it would come back with its own perfectly reasonable suggestions. After a while, we traced the issue to a small piece of code a colleague had added about four months earlier. The code itself was well written — no complaints there. But the approach he’d chosen (let’s call it A) wasn’t what I would have gone with (let’s say B).

“You don’t understand what I’m telling you”#

I reached out to the colleague on Slack. I gave him the full context of what I was investigating, kept things as humble as I could, and wrapped up with something along the lines of: “Based on my analysis, this code might be responsible for the errors I’m seeing. I’m guessing you considered B and had a good reason for going with A instead?”

A few exchanges followed, and then he hit me with this: “You don’t understand what I’m telling you” — with a smiley tacked on at the end.

I’ll be honest: my blood boiled for a second.

But here’s the beauty of written communication — you get a beat before you respond. So instead of firing back, I paused and thought: maybe I did miss something. I went back and carefully reread everything he’d written. Meanwhile, he was already typing out a new explanation of what I’d apparently been too slow to grasp.

When his “clarification” arrived, I could compare it side by side with what he’d originally written. And — surprise — reading the first, you’d never guess he meant the second. The thought was there; the words weren’t.

I didn’t point that out. I just continued the conversation, thanked him for the input, and told him I’d keep investigating.

It’s never about who’s right#

Here’s the thing: what he eventually said was genuinely worth considering. But the way he said it was just unacceptable.

How arrogant do you have to be to assume that you’ve expressed yourself so perfectly that it is the other person who is simply too dense to follow? And even if the other person did misunderstand — how does telling them “you don’t understand” help your case? All it does is put them on the defensive and kill the conversation.

I’ve been in that situation plenty of times — where two people are just not connecting. But I never phrase it that way. What I usually say is something like: “I probably didn’t explain that well — what I mean is … “. It’s so much easier for the other person to hear. It doesn’t put them in an inferior position, which means the conversation can keep going without tension.

Sure, there will always be people who interpret that kind of humility as weakness — who’ll think you’re clueless because you admitted you might have been unclear. But whenever that happens, I remind myself of a wonderful saying: “Being thought a fool by a fool — now that’s a rare delicacy”.

So don’t be that person: say it so they can hear it.

Before publishing this, I showed the original conversation to two other people and asked them if they understood the first version of my colleague’s explanation.

Neither of them did.