Beyond Imposter Syndrome

A lot of companies print their values on a poster and mention them at all-hands. If that is the only place they live, they are decoration.

I see a lot of resumes that claim ten years of experience across five companies, two years each. I always wonder: is that ten years of growth, or two years repeated five times?

Everyone in tech talks about Imposter Syndrome — the fear that you are one bad pull request away from being exposed. We talk less about the mirror image: the engineer who is sure they are under-leveled, overlooked, and six months late for a promotion nobody else can see. That is Protagonist Syndrome.

In research and writing you don't so much finish as find the right stopping point. The same trick applies to a feature that looks too big to ship.

I’ve given every team I lead the same advice: the best way to get the job is to do the job. It sounds like a catch-22. It is not. A promotion is usually the title catching up to work you are already doing.

You’re graduating into a job market that is already arguing with itself about whether your degree still matters. AI is not a distant threat. It is already chewing on the entry-level work that used to be the on-ramp — including in computer science, which was supposed to be the safe bet.

We are getting better at creating systems that almost no one can understand, maintain, or repair. The gap between what we can ship and what we can still own is the real risk.

The way you talk about a recursive function with another engineer is not the way you explain progress to a stakeholder, and it is not the way you talk to a frustrated customer. Same brain. Three audiences. Three jobs.

I’ve spent most of my career leading engineers who were smarter, more accomplished, and more technically impressive than I will ever be. For a long time that was a quiet problem. I would sit in an architecture review and think: what do I even bring?

“That’s not my job” is a wall. Deadline, extra pair of eyes, a small fire — and you get a job description instead of a teammate.

A cluttered workshop still works, at first. You think you know where the wrench is. You shove things aside. Then simple jobs take longer. Finding a tool becomes a dig. Eventually you spend more time navigating the mess than building anything.

Every engineer has been there. Late. Caffeine. A feature that does not fit the app. You invent a path through the code that should not exist, and it works. Relief. Pride.

As a manager, I have started handing junior engineers work I would have reserved for seniors a few years ago. The problems are harder. The first pass is often better than it should be. The reason is not that we suddenly hire geniuses. They are using AI.

You describe the feature in a paragraph. The model writes a few hundred lines. The tests pass — at least the ones it also wrote. You merge before lunch. That loop has a name now: vibe coding.

There's a line from Severance I cannot shake: "The work is mysterious and important."

A couple of years ago, every new AI demo put a knot in my stomach. I write software for a living. The models were getting faster at the part of the job I had spent years getting paid for. The question was ugly and simple: if they can write the code, what am I for?

I spent a lot of my young life on a baseball field. I did not know it then, but the habits I learned between the foul lines are the same ones I still use at a keyboard.

One of my favorite new tools is Mage AI, an "open-source data pipeline tool for transforming and integrating data." What I appreciate the most is their first-class documentation. They make it easy to get up and running in no time with extensive help and support for multiple platforms and providers. However, the reason I’m sharing this write-up is that the current version of the Mage docs does not cover key aspects of what it took to implement my scenario.

I needed to implement a queueing solution for my enterprise notification services that live mostly in Google Cloud Platform. The requirements were relatively simple and GCP offers a couple services that fit some of three specific points in one way or another.

When building applications, managing sensitive information like API keys, database credentials, and other secrets is a critical security concern. Hardcoding these values or storing them in version control is a significant risk.

I’ve sat on both sides of that table for two decades. I’ve asked gotcha questions that were trivia, not skill. I’ve been on the receiving end of the same. I have also run interviews I knew were worse than they should have been.