Why I Finally Stopped Believing My Code Speaks for Itself

A year ago, I shipped a system that cut our API response time by 40%. I was genuinely proud of it—the architecture was clean, the queries optimized, the caching strategy elegant. I mentioned it once in standup and moved on. Six months later, during promotion discussions, I realized nobody remembered I'd built it. Someone else had written a blog post about their smaller optimization and somehow ended up being the one everyone talked about.

That's when I started thinking differently about what "good engineering" actually means.

I just read an article that crystallized something I've been experiencing in production work: the vertical bar in your T-shaped skills is no longer your competitive advantage. It's table stakes. What actually moves your career forward is everything else—and I've been underestimating that severely.

The Uncomfortable Truth About AI Commoditizing Depth

Here's the part that stings: my core technical skills, the things I spent five years building in Islamabad through late-night debugging sessions and architecture deep-dives, are becoming commoditized. Not by senior engineers or architects—by language models with API keys.

I'm not being cynical. I tested this myself last month. I gave Claude a moderately complex database schema optimization problem. It didn't just solve it—it explained three different approaches with tradeoffs. Would it replace my judgment? No. But it made the gap between an expert and a competent engineer much smaller than it used to be.

This means the thing that used to carry careers—being the person who could hold complex technical systems in your head—isn't enough anymore. The engineers I see actually advancing aren't the ones with the deepest technical knowledge. They're the ones who can move that knowledge. Who can explain it. Who can connect it to business impact.

What Actually Stays Your Advantage

The horizontal bar of the T is what can't be replicated by a model. Noticing that the VP checked out of your technical presentation two slides ago. Understanding enough about product strategy, data, and design to ask the questions that matter. Reading a tense Slack thread and knowing whether to respond or let it breathe.

Most critically: the ability to make people feel heard when you tell them no.

I've watched junior engineers with solid skills stay stuck because they treated feedback like criticism. I've watched mid-level engineers with mediocre technical chops keep getting promoted because they could translate between product, design, and engineering without ego.

The maintenance work is slower to compound than code. That's exactly why impatient people skip it.

Building the T on Purpose

I'm being intentional about this now. My vertical bar is backend systems and query optimization—that's where people ping me at 2am. I'm deliberately slow there, reading papers, staying current, being genuinely deep.

But I'm spending equal energy building the crossbar. I sit in product meetings I don't technically need to attend. Last month I asked our finance partner what metrics actually matter to her. I drafted my project proposals multiple times until a VP with thirty seconds could understand the impact.

And I'm treating writing and communication like production systems. If my status update needs scrolling, it needs editing. I explain my work at three different altitudes—to an intern, to a peer, to leadership. If I can only do one, I'm not T-shaped yet.

Where I Disagree (Slightly)

The article nails the core insight, but I'd push back on one thing: soft skills aren't about making people like you or climbing the ladder. The ones that matter are the genuinely useful ones. Can you actually think clearly in a room with conflicting opinions? Can you disagree without defending territory?

I've seen too many engineers optimize for "being agreeable" and end up unable to make real decisions. The crossbar should make you more effective, not more palatable.

What This Means for My Work

I'm using AI aggressively now to practice the parts I'm weak in. I paste my design docs into Claude and ask it to rewrite the summary for a VP with thirty seconds. I practice defending my projects against hard pushback—literally roleplaying with a model before real meetings.

An hour of practice, a few cents of compute. It's cheaper than most coffee.

The original insight from that brewery conversation still holds: depth gets you in the room. The crossbar keeps you there. Everything else is whether you actually move careers forward or just get deeper in your own diary.

Source: This post was inspired by "Burn After Reading" by Dev.to. Read the original article