The experience you've built over your career is what helps you make decisions and identify trouble quickly. But experience has a cost. In this issue, you'll explore how you might undermine your expertise, and what you can do to be more effective when offering it to others.
Your Experience Makes You Answer Too Quickly
The longer you work on technical problems, the faster you get at spotting what's wrong and coming up with solutions based on what you've seen before.
Someone starts describing an issue, and you've been in this situation plenty of times before. Your experience starts pattern-matching and you start thinking of an answer before they've finished their explanation. You're also doing something dangerous; you're answering a question you only partly heard. The part you skipped is sometimes where the details live.
You've likely experienced that from the other side. You describe your symptoms to a doctor, and before you reach the second sentence, the doctor gives you a diagnosis. Lose some weight. Get more sleep. Drink more water. Come back in six months if it doesn't clear up. The diagnosis fits the category you appear to belong to, and they made it before they looked at you specifically. Sometimes it's correct, but you still feel like nobody was listening to you.
The real risk is that the expert reputation you built for yourself can get torn down quickly if you become dismissive and provide wrong answers. To keep yourself from doing this, you'll first need to understand why that reflex forms, and why nothing at work will correct it for you. Then you'll explore a few habits that keep your speed and still leave room for the details you're skipping.
How the shortcut forms and gets reinforced
Every time you solve a problem, you add it to your personal knowledge base you can draw from later. You remember what the logs looked like, what the person said, and what you experienced right before you found the cause. Build up enough of those experiences, and you start recognizing problems instead of working through them from the beginning.
Reasoning from the ground up every time is slow, and most problems are not new. Your experience is valuable because you can fix things more quickly. This is a big part of why a senior costs more than a junior, and why the money makes sense.
And when everything around you rewards the fast answer, the behavior gets reinforced.
First, fast answers feel good. The person who brought you the problem walks away relieved, and you were the reason. They're unblocked quickly, and they keep coming back to you for help.
Second, many people perceive confidence as competence. That works on almost everyone watching, including the people who can't evaluate whether the answer was right. "Ask Sarah, she'll know" comes with status.
Speed is easier to measure than accuracy, so organizations measure and reward the thing they can count. You're helping people get things done faster, and you're making quick decisions yourself. As a result, you create an expectation that you'll answer quickly, which you then try to keep meeting.
Finally, every time you pattern-match correctly, you trust your experience a little more. Nobody keeps score of the times you were wrong at first, because a wrong fast answer looks exactly like a right one until much later.
Danger lurks ahead.
The Einstellung effect describes how a familiar solution, once it comes to mind, blocks you from finding a better one. The familiar answer doesn't only arrive first. It crowds out the search for anything else, and it does that whether or not the answer is right.
A few things end up happening as a result.
You diagnose before you have evidence.
Someone is three sentences into describing the problem, and you're already assembling the answer instead of listening to the rest of it. Or worse, you cut them off and state the solution. The details that didn't arrive because you stopped listening are often the ones that matter, because those are the details that make this problem different from the one you're thinking of.
And nobody likes a know-it-all, especially one who does not, in fact, know it all.
You miss what changed.
Patterns expire, and nothing tells you when. You're prone to solving last month's problem instead of this one. Last month's is fresh and well-worn, and the new situation looks pretty similar, so you reach for what worked before.
The database timeout you always traced to a slow query starts happening after the move to managed hosting, and now it's a connection pool limit. The onboarding question you always answered the same way stops making sense after the signup flow changed. The match feels exactly as certain as it did back when you formed it, but it's not the same problem anymore.
Overconfidence kills your curiosity.
Certainty is comfortable, so you stop asking questions that used to come naturally, like "what am I missing here? What would I have to see to believe I'm wrong?" When you were new, you were curious. Maybe you felt you couldn't function properly without asking curious questions, so you asked them constantly. Now you have answers, and they feel like they fit patterns so clearly that asking questions feels like a waste of time.
The curiosity you had as a junior wasn't supposed to be a personality trait you outgrew on the way to getting good. It's what helped you get good and will help you continue to level up.
Losing your curiosity can have real costs that aren't immediately obvious. Approaching every problem that looks the same with the same fix means you'll innovate less and be less open to optimizing things further.
The reputational cost of being wrong and fast
Being wrong once in a while costs you nothing. Everyone is wrong once in a while, and most people will forgive you. Being wrong fast and often builds distrust and resentment, and it happens slowly enough that you won't notice it happening.
Look at what the fast answer costs in practice. "It's always DNS" became a joke because it's right often enough to be worth saying out loud. When it isn't DNS, you spend the next hour on the resolver while the real failure still affects people. The wrong diagnosis costs you and those affected.
This shows up anywhere you handle the same kind of request over and over.
"We already have an answer to that question in our documentation" is another version of this. Sometimes the answer is in the docs, but nobody can find it, or it sits ten paragraphs down in a guide nobody reads. Sometimes the words are identical, but the reason underneath them isn't. Two readers ask how to configure a timeout. One is tuning performance, and the other hit an error and is guessing, and the answer you have only serves one of those readers. Without digging deeper, you're failing to address a completely different problem than the one you thought you had.
The end result is that people start hedging around you. They stop coming to you first, or they bring you in later for a second opinion. Or they take your answer, spend a day on it, quietly verifying it themselves. You keep getting asked questions, but you stop getting the hard ones, which are the ones you find more interesting. And. you stop growing.
In Issue 40, you saw how your career has a permanent record. If you're quick to answer and end up being wrong a lot, you're building a reputation that could follow you from one job to the next.
The fix is to slow down just enough to inspect the problem.
Build habits to be curious and fast
You should continue to pattern-match, but with curiosity. Be less reactive and more interested in the problem than the solution. You need to force yourself to turn off your internal autopilot and rebuild the habits you had when you were more junior. When you were less experienced, you asked questions to help shape your mental model.
There are three things you can do to make that shift:
-
Say the match out loud as a guess, and name the check. Instead of "it's the cache," try "sounds like the cache. Look at the cache logs and find the hit rate for the last hour and see what you find." That costs you one sentence. You still answered in fifteen seconds, you still look like the person who knows, and now there's a step between your instinct and someone's production system. It also leaves you correctable in public, which is worth more than being right.
-
Ask what changed. If you've solved this issue before, ask what's different now. Is there a new dependency? Is there a new customer involved? Is there a new version? When nothing changed, your pattern is probably fine. When you can name three things that changed, treat the match as a first guess and then take a deeper look.
-
Treat strong confidence about an unfamiliar process as a reason to slow down. Feeling certain about something you've handled a hundred times is earned. Feeling that certain about a system you've touched twice borders on hubris and arrogance. Pattern-matching is one of your strengths, but if you don't have enough context, you're only guessing. Ask questions that will help you get more information to determine if the pattern you see actually fits the situation you're in.
Your experience needs to shorten the investigation, not end it before it starts. That's the difference between being fast and being closed, and it costs about one sentence per problem.
So the next time someone brings you a problem, answer as quickly as you normally would, then add one sentence about what would tell you you're wrong, and suggest people look into that before anyone acts on your answer. It keeps you in check, keeps you curious, and will strengthen your reputation overall, because you'll be genuinely more approachable.
Things To Explore
- shiki is a note-taking app for your terminal. Each notebook is a Git repository, and each note gets versioned. While this is all something you can do with your regular text editor, shiki gives you a three-pane interface to navigate and view your notes quickly.
- https://feelingswheel.app/https://feelingswheel.app/ is an interactive version of a Feelings Wheel, or Emotions Wheel, that helps you think through your own feelings. This can be a great tool for managing stress or emotions.
Parting Thoughts
Here are a couple of things for you to think about before next month's issue:
- Think of the last time someone described a problem, and you knew the answer before they finished. Did you verify it, or did you move on?
- Is there someone who used to bring you their hardest problems and stopped? When did that change?
As always, thanks for reading.
You just read issue #55 of Code, Content, and Career with Brian Hogan. You can also browse the full archives of this newsletter.