• Rayhan Memon
  • Posts
  • #35 - Graduating from “Programmer” to “Software Engineer”

#35 - Graduating from “Programmer” to “Software Engineer”

“Programmers” obsess over writing optimal code. “Software Engineers” obsess over accepting the right set of trade-offs.

They consider the lifespan of their code, how often that code is likely to be revisited, and the performance/reliability needs of the systems for which that code applies.

Simply put: Software Engineering is Programming integrated over time.

For me, the transition from Programmer to Software Engineer wasn’t some watershed moment I can pinpoint, like a caterpillar turning into a butterfly. It was more like a Sapling growing into a tree—There’s a long period of time where you’re like, “Is that a sapling or a tree?” until eventually it grows so big that everyone agrees, “yeah, that’s a tree.” (Rough analogy, I know).

I spent a few years with a foot in both worlds, until recently when I noticed a few signs that I’d fully crossed over into “Software Engineer” territory:

1. “That’s a clever solution” started sounding like an insult.

When I was starting out, I lived for clever solutions. Every time I shaved a few milliseconds off a loop, I felt like I’d just split the atom. But after revisiting one too many Rube Goldberg functions I’d written months earlier, I realized “clever” often meant “cryptic”. These days, I aim for boring code—predictable, readable, and dull in the best way.

Like choosing an unsexy, fuel-efficient Toyota over a flashy, unreliable sports car. You won’t turn many heads, but it’s a smart move for your daily commute.

2. I started “shifting left”.

I used to treat security, extensibility and performance tuning as afterthoughts—stuff I’d deal with later if it became a problem. Then I had to clean up enough of my own messes to know that “later” always costs more. I learned to spend the extra hour upfront, triple-checking what I was shipping and welcoming thorough code reviews instead of dreading them.

I’d much rather take a few minutes washing dishes while I cook dinner than spend an hour chipping solidified grease off of a baking sheet the next morning.

3. I began treating cloud dashboards as “read-only”.

I’ve participated in one to many late-night firefighting sessions trying to recover the state of my prod environment to never again want to flip a switch or turn a knob in my cloud provider’s UI.

Nowadays, if it’s not in version control, I don’t trust it. Environment variables, Database migrations, resource configurations—they’re all committed now.

If it’s not reproducible, it’s not real. Terraform is your friend.

4. I stopped looking for perfect solutions.

Prepping for job interviews with LeetCode taught me that there’s a right answer to every problem. Working a real job taught me the opposite—there are no right answers, only acceptable trade-offs.

Every decision—every line of code—is a negotiation between speed, simplicity, scalability, and sanity. Now when I design something, I ask: "What’s the right trade-off for this moment?"

I’m not building for the highest score on LeetCode; I’m building for people—my colleagues and our users. And people need systems that work, not that impress.

5. I realized all my problems are human problems, not software problems.

I used to think bugs were my biggest enemy. Then I started leading projects both at work and at my startup, Wednesday Waffles. Now I know the hard part isn’t the code—it’s the collaboration.

AI can write my code for me, but it won’t stop me from merging an untested PR the night before launch if I want to. It won’t stop me from wasting time on low-priority tickets if that’s what I want to work on. It’s not going to make sure every engineer on my team understands how that new feature works if I don’t dedicate some meeting time to telling them.

That stuff’s on me.

Great engineering is about great systems, strong habits, and exceptional character. The hardest problems I face today aren’t technical. They’re social, emotional and organizational.

Programming is about getting things to work. Software engineering is about keeping them working. It’s about building in a way that respects time—yours, your teammates’, and your future selves’.

If you found yourself nodding along, congrats! You’ve graduated. Welcome to the long game.

Quick reminder - If you appreciate my writing, please reply to this email or “add to address book”. These positive signals help my emails land in your inbox.

If you don't want these emails, you can unsubscribe below. If you were sent this email and want more, you can subscribe here.

See you next week — Rayhan