I have worked with engineers who could explain the internals of a B-tree index from memory, who spotted race conditions in code reviews before the rest of us had finished reading the file name, who understood cryptographic primitives the way most people understand a light switch. Some of them were the most frustrating people I have ever collaborated with.

Not because they were wrong. Because being right was the whole point for them.

"It's not a bug, it's undefined behavior — technically the spec allows this."

Correct & Unhelpful

There's a failure I've watched play out time and time again: someone asks a question, and an engineer gives a technically accurate answer that helps no one.

They explain the performance penalty of an unindexed column causing a full table scan. Correct, and unactionable. The PM needed to know when service would be back. Forget for a moment that you want to appear competent and recognize a human is asking for help. Help people with your gift.

A junior developer might write ugly code, difficult to read code, and request a review. The senior does not take this as an opportunity to be right that "ugly code is a smell for bad design". They lead by example, protect from real problems, help the junior do better. They do not assert the vanity of correctness: they just are correct in what they do.

The gap between "what was asked" and "what is needed" is not obvious; nonetheless closing it is the engineer's job.

Embrace the Simple & Be Shriven

Would you believe that I once over-engineered my solutions? That is why I recognize it so quickly now.

In those days, the problem was straightforward but the solution I built wasn't. It had abstraction layers nobody asked for, configurations nobody knew they needed, and extensibility for requirements unwritten. It was honestly pretty cool. Or so I thought until I learned that helping people was cooler.

Over-engineering is rarely about the problem. It's about the engineer. There's a satisfaction in preparing for every perceived inevitability, anticipating every edge, leaving no backdoor open for code-grumpkins. That satisfaction is for you. The person who needed the thing just wanted it running and stable.

Don't Be That Team Mate

This pattern is subtler and thus more insidious.

Engineers are deeply good at what they know, and they know it. The knowledge becomes part of their identity and their leverage. They are the person who understands the legacy authentication system, the one you have to go through to understand the deployment pipeline, the keeper of context that never made it into documentation.

There's a real incentive structure here. If you are the person who knows a thing, you have status. People need you. If you document it clearly and transfer it, that status diffuses. Rationally, the knowledge-holding behavior makes a kind of sense.

But heed my words, mortal. There will always be someone smarter than you who will demolish that which you have sculpted and where you once thought you had clout, you will have nothing. The only thing you will have is your good deeds, your reputation of reliability, and willingness to help others. These things are not replaceable but your technical know-how, even your institutional wisdom, generally is.

The Pull Toward Interesting

I'll be honest about the internal version of this, because it doesn't always look like ego.

There is genuine pull toward interesting problems. Not every task is interesting. A lot of engineering work is repetitive, unglamorous, and necessary. When something legitimately difficult appears, it is hard not to spend more time on it than you should, not because you're showboating, but because the problem is good and your brain likes good problems.

The interesting problem is often not the most urgent one though. The person who needed the boring fix still needed it. The customer who filed the simple bug ticket still filed it. The interesting problem you spent a week exploring with genuine intellectual enthusiasm might have been, from the organization's perspective, the fourth priority.

I'm not saying don't care about interesting problems. I'm saying notice when the pull toward interesting is pulling you away from useful.

What Asking Actually Costs

There's a habit I've been working on for years, and it's simpler than I made it for a long time: before I answer, I try to understand what the person actually needs.

Not what they said. What they need. And this can be discovered with one simple question:

"What is the problem you're trying to solve?"

They'll tell you they need an infinite scroll, a chat bot, whatever. But this is always misdirection. Go a layer deeper: what is the thing this gets you towards?

And so the junior won't ask this and pursues technical excellence but the technically correct answer doesn't move the needle. It becomes a thorough solution to a problem nobody had.

Asking "what problem are you trying to solve" costs ten seconds, some pride, but sometimes the honest answer you get reveals a secret: The impressive thing you were about to build is not useful.

More importantly this brings you closer to what you actually need to do and someone's problem will get solved. The junior developer ships the thing. The PM has an answer for the client call. The team can deploy without you in the room. The junior ascends to the olympus of engineers.

That's the difference between technical ability and technical value. After 12 years, I'm still convinced most engineers have more of the first than they think, and less of the second than they need. Maybe it is a soft skill, but a hard skill after all.