I've been a software engineer for nearly 24 years. That’s almost a quarter of a century! It doesn't feel like a long time, but when I say it out loud, even I think, "That’s a long time." Yet, here I am, after all these years, pondering a rather fundamental question:

What is a Software Engineer’s job? And how do we know if we’re doing a good one?

What is a Software Engineer's Job?

A cheeky answer might be, "To write code".  The more abstract and pompous answer might be, "To solve problems".

Neither feels quite right.  "To write code" is too narrow -- it can't be just any code, it needs to be the right code.  But even then, our job isn't just about code.  Plus, our users don't care about our code, so focusing solely on code is missing the boat.

What about "to solve problems"? Beyond being grandiose this is also too vague.  It doesn't even mention software! And I don't like the word "problems" either. But at least this does nudge us toward focusing on outcomes rather than output.

So here's where I landed: A Software Engineer's job is to build software solutions for users.

Yeah, I know, that's not earth shattering. But I think it's accurate and might be about as specific as we can get. One of the things about Software Engineering is that it is a field of people who are all clearly doing similar things, but doing those things in wildly different domains.  I've noticed that this makes it easy for us to talk past each other because what is important to someone building embedded systems in C is probably not at all important to someone building web applications in TypeScript. But both are doing Software Engineering, and I think this definition captures that.

How do we know if we're doing a good job?

Ah, well, this is where it gets really interesting.  I tried to distill this down as far as I could, and here's where I ended up:

We're doing a good job if:

1. Our software does what our users need
2. Is affordable

Let's break it down.

Does What Our Users Need

This encapsulates a lot:

1. It's done. We shipped something!
2. It's the right thing. We solved the actual problem.  
3. Users like it. If they don't like it, that has to mean it isn't really what they need.
4. We can change it. User's needs change and we must change the software to match.

If all of that is true, some other things must be true too:

1. Good UX. So users can use it, and like using it.
2. Robust, reliable, and not buggy. So it's not erroring or failing on users all the time.
3. Good performance. So users don't want to throw their laptops against the wall.
4. Secure. So users don't get hacked.

Is Affordable

We can't be professionals and ignore costs.  We have to be able to afford to build the software, and users have to be able to afford to purchase it, or we're out of a job. So this one's simple.

Why Does This Matter?

Our industry is full of arguments and conflicting advice about best practices, processes, tools, libraries, system design, and on and on. How are we supposed to figure out what WE should do? What advice is best for OUR projects?

Maybe this can help gives us a good lens to look through when making these decisions. I like this is user-focused, not engineer-focused. That forces us to prioritize what users need rather than what we want. For instance, "code quality" didn’t explicitly make the list. That’s not because it’s unimportant—it clearly underpins maintainability, reliability, and affordability—but because it's not the end goal.

But I’m still testing this idea in my own work. Can it help me decide where to focus my time and energy? We’ll see. For now, it’s given me a new way to think about what I do—and if I'm doing it well.