Code Isn't Engineering Until You Stop Thinking It Is

Someone asked me last week what I actually do for a living. Not in the polite "oh that's nice" way—genuinely curious. I said "I'm a developer" and watched their face go blank. They nodded like I'd said "I work in an office." It hit me that I couldn't explain my job any better than they could understand it.

The thing is, I've been building software professionally for eight years. I should have a clean answer by now. But every time I try, I sound like I'm avoiding the question. "Write code"? Sure, technically. But I spent last month arguing about where to draw service boundaries, not actually coding. "Solve problems"? Everyone does that. The plumber who fixed my sink last month solved a problem too.

I realized the issue isn't that I'm bad at explaining—it's that I've been using the wrong word entirely.

We're Engineers, Not Programmers

Here's the distinction that changed how I think about this work: code is the material, not the job.

A civil engineer doesn't get described as "someone who works with steel." Steel is what they use. What they actually do is look at a gap and decide what spans it. Same with us. We look at a business problem and decide what system solves it. React, Node, PostgreSQL—these are just this decade's steel.

I had this conversation with a junior developer on my team last month who was panicking about learning the "right" technologies. He thought if he mastered enough frameworks, he'd become a "real" engineer. I had to tell him: learning frameworks is learning tools. Engineering is learning how to think about the problem before you pick the tool.

That's a harder skill to teach, and honestly, I'm not sure we teach it at all.

The Four Things That Actually Matter

When I strip away the syntax and the frameworks, I'm doing four things repeatedly:

Decomposition. Breaking fuzzy requirements into pieces I can actually reason about. "Make the dashboard faster" becomes "measure the query time" and "measure the render time" and "test under load."

Modeling. Deciding what things are. Is a user the same as an account? Does a deleted order still exist in our audit log? These feel like philosophy questions because they are. And I've seen them cost years when someone modeled wrong in 2019 and built five features on top of a broken foundation.

Tradeoffs. Choosing positions on curves where no answer is right. Token bucket versus leaky bucket. Consistency versus availability. Cache invalidation strategies. None of these have winning moves—only different costs.

Entropy. Managing the fact that last quarter's decisions are wrong now, not because anyone failed, but because the world changed.

Senior developers spend most of their time on the first three. Juniors mostly do the fourth step—making things precise enough to actually run.

What I Actually Disagree With

The original article nails most of this, but I think it undersells one thing: the need to be comfortable with ambiguity isn't a personality trait, it's a professional skill you can develop.

I used to be someone who needed closure. Every project felt incomplete until it was literally perfect. I burned out twice before I realized I was fighting the nature of the work. Then I learned to define "done" clearly and actually stop. That's not a personality change—that's just learning a skill.

Same with the visibility problem. Yes, the best work I do is bugs that never happen. But I've learned to make that visible to people who care. I document decision trees. I show the incident severity curve that would've happened without my changes. I learned to quantify the invisible.

I don't think you need a certain personality type to last in this job. I think you need to choose to adapt if you don't have one naturally.

What This Actually Means

For me, this reframes how I hire, mentor, and think about my own growth. I'm not looking for "smart." I'm looking for people who can live with incomplete information, change their minds about architecture at 2pm on Thursday, and not need their code to be beautiful if it needs to be fast.

I'm also more forgiving of myself when I make bad decisions. They're not failures—they're constraints for future work. The skill isn't perfection. It's noticing what's load-bearing and where you can let things bend.

My next question for myself: What decisions am I making today that I'll regret in five years? And more importantly: which ones matter enough to slow down for?

Source: This post was inspired by "What Makes a Software Engineer: The Essence of the Job" by Dev.to. Read the original article