Every so often someone asks me what software engineering actually is. A kid thinking about majors, someone considering a career switch, a relative who's genuinely curious and not just being polite.
It's a harder question than it should be, because every other profession gets a clean sentence. A doctor treats patients. A lawyer interprets law. A botanist studies plants. Four or five words and you basically get it.
We don't have that sentence. "Writes code" is wrong the same way "a surgeon holds a knife" is wrong — technically true, completely missing. "Solves problems" is worse, because it describes literally everyone.
Here's where I've landed, both on what the job is and on the part nobody mentions: who it's good for, and who it quietly makes miserable.
The word we skip
The answer's been sitting in the job title. It's engineering.
A civil engineer looks at a river and a town on the other side and builds a bridge. Nobody calls that person "someone who works with steel." Steel is just what's around. The engineering is looking at the gap and deciding what should span it.
Same deal for us. Code is our material. Look at a problem, build a system that solves it, live with how you built it.
This is why beginners get confused about what to learn. They think learning React is learning engineering. It isn't. React is this decade's steel.
Why our version is strange
So if we're just engineers, why is our job harder to describe than a bridge builder's?
A civil engineer has physics and a river that's actually sitting there. A doctor has a body. A lawyer has a legal code somebody wrote down. All of them have a referent that existed before the profession did. It pushes back. It tells them when they're wrong.
We've got nothing like that. Gravity is never going to tell you your service boundaries are bad. Every system is invented, and every constraint on it is one we made up, or inherited from someone who made it up on a Tuesday in 2019.
The object of the work doesn't exist until you make it exist. Which makes it very hard to point at.
What the job actually is
Take the tools away and four things are left:
Decomposition. Someone says "we need better fraud detection," and you have to find the seams. Where does this fuzzy thing cut into pieces you can reason about?
Modeling. Deciding what things are. Is a user the same as an account? When an order is cancelled, does it still exist? These sound like philosophy-class questions. They are. And they cost years when you get them wrong.
Tradeoffs. No correct answer, just positions on a curve. Token bucket or leaky bucket isn't about which is right. It's what you're willing to give up.
Entropy. Things you wrote last quarter are wrong now. Nobody broke them. The world moved.
So if a doctor diagnoses and a lawyer interprets, an engineer decides. Constantly, with bad information, in ways that pile up.
That last part is what I couldn't see starting out. A doctor makes a bad call and one patient is harmed. You make a bad modeling decision and it shapes every feature built on top of it for five years. That's why "it works" is a low bar, and why senior people fuss over naming things. It looks like fussiness. It's blast radius management for decisions nobody's made yet.
"So... problem solving?"
Not good enough. Plumbers solve problems. Chess players solve problems. If it describes everyone, it explains nothing.
What's actually different:
The problem usually isn't handed to you. A chess player gets a board. You get "the dashboard is slow," which might mean the query is slow, the network is slow, their expectation is off, or they need a different dashboard entirely. Half the job is figuring out what the problem even is. Most bad software is an excellent solution to the wrong one.
Your solutions become other people's constraints. Decide a user and an account are the same thing, and you've built the room fifty future features have to fit inside.
So: figure out what to build, structure it to survive change, decide what to sacrifice, then make it precise enough to run. Junior work is mostly that last step. Senior work is the first three.
The skills nobody interviews for
Tenacity. Not intelligence, and not quite discipline either. Sitting with something you don't understand, past the point where it's comfortable, without knowing how long that will last.
Selective rigor. Caring about everything equally is a liability — those people can't ship, because they can't tell what matters. The skill is knowing which three details are load-bearing and being immovable about those while relaxing about the other twenty.
A relationship with complexity. Not a fight with it. Not something you'll resolve after the refactor. It's ongoing and unresolvable, and it isn't in the way of the work — it is the work.
That last one explains most of what follows.
Who this job quietly doesn't work for
None of this is about being smart enough. Everyone below could do the work. The mismatch is what they need to find it nourishing.
People who need closure. A case gets closed. A patient gets discharged. You ship, and it starts rotting into maintenance. There's no finished. There's only stopped.
People who need visible work. You spend three weeks eliminating a whole class of failure and the result is: nothing happens. The best work you'll do is an incident that never occurred, and you can't show it to anyone.
People who need to be right. You can prove a function correct. You can't prove your architecture was, ever. Six months later you'll find out if it hurt — not whether the alternative would've hurt more.
People who need clean things to stay clean. Then you meet the workaround that has to stay because a customer depends on the bug. The gap between how it should be and how it is never closes. The people who last make peace with living in the gap.
People who flee discomfort. Careful with this one, because the obvious version is wrong. "Lazy people shouldn't be engineers" is wrong — some of the best engineers I know are motivated almost entirely by not wanting to deal with things. That's where automation comes from.
The real thing is narrower: discomfort tolerance shallower than the problem is deep. They hit "it works, ship it" and stop. Not lazy about effort. Just done being uncomfortable. The tell isn't how hard someone works, it's what they do when they don't understand something. Fix the flaky test with a retry, or ask why it's flaky. Both are working. Only one is engineering.
People whose discipline depends on the discomfort being finite. The one I find most interesting, because these are often genuinely disciplined people.
Think about how most discomfort works. You study for an exam — brutal, but there's a date and then it's over. You do a hard workout — the last reps hurt, but you can count them. Humans are remarkably good at suffering when we can see the end of it. That's most of what discipline is: borrowing against a known finish line.
Software doesn't give you the finish line. You don't know if the thing you're stuck on cracks in an hour or three days, or if the approach you've spent two days on is a dead end. There's no bell. There's no "just get through this part," because there isn't a part.
So people arrive with real discipline — the kind that got them through hard degrees — and they're confused when it doesn't transfer. It's not that they can't endure. Their endurance was structured around an ending, and this doesn't have one. The muscle is the wrong muscle.
The botanist problem
The one I think about most.
A botanist learning their 500th species has an easier time than with their 5th. Taxonomy is still true. Morphology is still true. Twenty years in they're fast, because everything they've learned still applies. Same with law.
We're not like that. Some of it compounds: data structures, distributed systems, how to model a domain. But a lot is lateral — true only inside this decade's framework, this vendor's abstraction. Your 500th tool isn't easier than your 5th, because tool 500 has nothing to do with tool 5.
I felt this hard when I joined AWS. I'd spent grad school with Maven, Gradle, and the usual open-source deployment stack. I could build and ship software. I was comfortable. Then I got here and AWS runs on its own internal tooling, and almost none of that transferred. The concepts overlapped — it's all still builds and pipelines and dependency graphs — but knowing Maven cold bought me surprisingly little. I couldn't lean on any of it. I had to learn the internal versions from scratch, like I'd never built anything before.
That's the shape of it. Not that the old knowledge was useless, exactly. Just that it was a lot less load-bearing than the years I'd spent earning it would suggest.
So you put in the years and it doesn't feel easier. It feels like running to stay in place. If you came expecting the botanist's deal — foundation, accumulation, mastery — that's a broken contract nobody warned you about.
Here's what took me a while to see: it does compound. Just not where you're looking.
Learning AWS's internal tooling was slow and humbling. But it was still faster than learning Maven had been, and I didn't notice that at the time. I wasn't learning "how builds work" from nothing — I was mapping a new thing onto a shape I already had. The overlap I couldn't use directly was still doing quiet work underneath.
That's the compounding. A senior picks up a new framework in a weekend, not because they know it, but because they've internalized the shape of frameworks and the new one is mostly a rearrangement. It's real. It's just invisible, and it feels like "huh, I've seen this before," which is much quieter than being a master of something.
If your sense of yourself needs to rest on being an expert in a named thing, this field will keep dissolving the thing.
The thing underneath all of it
Closure. Visibility. Correctness. Cleanliness. Expertise. A finish line.
Same root: this job punishes people who need the work to resolve. It rewards people who can sit in an unresolved state indefinitely without it eating at them.
The botanist accumulates. The doctor discharges. The lawyer gets a verdict. You get a system that's never done, knowledge that half-expires, decisions you'll never know were right, and a mess you're expected to be at peace with.
That's a real ask. And it's not a character flaw to want the botanist's deal instead. Most professions offer it. This one doesn't.
Who it is for
The people who love this share one thing, and it isn't raw intelligence.
They find the complexity itself interesting rather than obstructive. Not that they enjoy suffering. They just don't hear "this is tangled and unclear" as an insult. They hear the job.
The mess isn't in the way of the work. The mess is the work.
Which is why it's a relationship. Like any relationship, the question was never whether the other party is difficult. It's whether you find the difficulty compelling or exhausting.
The sentence, finally
A doctor figures out what's wrong with a body. A lawyer figures out what the rules mean for your situation. A software engineer figures out what a problem actually is, decides how to build something that won't fall over when everything changes, and writes it down precisely enough for a machine to follow — knowing every choice narrows what's possible next.
We're engineers. Code is just the material. It's the last five percent, and it's only the part anyone can see.
How do you explain this job to someone outside it? Curious whether anyone's landed on something better.
