21 Rules for Great Engineers

A few days ago I read one of those "how to be a great engineer" lists. Twenty-one rules. Here's the thing: I'm not an engineer. I'm a PM. I can read code, but I've never lived the life where you're hugging a server at 2 a.m. during an outage. (I have stayed up until 2 a.m. building this blog. Different kind of crying.)

So I scrolled through it expecting to visit someone else's neighborhood. And then I caught myself nodding. Repeatedly.

Halfway down, I realized why: there's almost no code in this list. Not a single line about "the fastest algorithm." Instead it keeps circling back to the same words—people, politics, alignment, ambiguity. The best engineers aren't the best programmers. They're the ones who learned to navigate the mess of humans standing around the code.

That's when it clicked. This wasn't a list about engineering. It was a list about being good at work, full stop. So I pulled out a few and rewrote them in my own language.

"Being right is easy. Getting there together is the actual job."

This one hit me square in the face.

Early on, I loved winning meetings. Say the logically airtight thing and you've won—that was my whole model. Then the list pointed out something I'd paid a lot to learn: you can win every technical argument and still lose the project.

I know this one intimately. I once worked on something that was technically solid and genuinely nice to look at. It just didn't line up with where the company was going. It got killed before launch. And that's when it landed—being "right" doesn't move anything on its own. Direction, interfaces, priorities. Get those wrong and you've just built a very well-crafted piece of scrap.

(That experience is roughly half of why I'm prepping for an MBA now. The other half... let's save that for another post.)

"Ship with a bias to action. A bad page is editable. A blank page isn't."

I want to frame this one and hang it on my wall.

I built this blog in three days knowing almost nothing about code. Did I spend weeks agonizing over the perfect architecture? No. I threw up an ugly prototype, shipped an embarrassing version, and fixed it while watching it run.

Perfect solutions don't come from your head. They come from contact with reality. One week of real feedback beats a month of theoretical debate. Analyze forever and you build nothing—because you can't edit a blank page.

Honestly, this blog is the proof. This very post isn't perfect. But it exists.

"Your code doesn't advocate for you. People do."

Reading this line, I went: oh. That's why I run this blog.

I used to believe good work would speak for itself. That strong output announces itself. It doesn't. Output sits quietly in a repo, in a Notion page, in a folder nobody opens.

If nobody in the room you're not in can describe your impact, that impact is basically optional. This isn't a pitch for self-promotion. It's about making the value you create legible—to everyone, including future you.

That's exactly what this blog is. It's me making myself readable in a way a one-page résumé never could. I think the way we prove "who we are" is shifting in the AI era. So I write.

Bonus: "The best code is the code you never had to write."

This one stings for PMs specifically. We tend to prove we exist by adding features. But the list said it plainly: nobody gets promoted for deleting code, even though deletion improves the system more often than addition does.

Before building, ask the boring question first: "what happens if I just... don't?" Sometimes the answer is "nothing bad." That's your solution.

Nobody claps for the feature you didn't ship. But not shipping it is often the actual skill.

So, wrapping up

After all twenty-one, one thought stuck: most of what we call "technical work" is people work wearing a lab coat.

Writing clearly. Getting aligned. Saying "I don't know" out loud. Asking whether the thing needs to exist before you build it. None of that is syntax.

I'm not an engineer—but maybe that's exactly why the list read so cleanly to me. I can't write the code, but working in the space between people is the same job in every role.

So today I'll ship another ugly page. Editing comes later.