On this blog, we cover a lot of topics about how to break into programming. So that practically begs us to answer the question, “what makes a good software engineer?”
Well, let’s answer that question today.
What Makes a Good Software Engineer: The Short Answer
In fact, let’s answer it briefly, right out of the gate. This will set the stage for the more detailed answer below, where I’ll offer 13 different traits that will help you become a good engineer.
A good software engineer is someone who is not only competent at writing code, but also competent in everything else required to build, deliver, and ship valuable software. A good software engineer is someone that their company can trust to help them make money.
Some people might disagree holistically, or at the margins, with this. They might emphasize things like algorithms and data structures knowledge, mathematical aptitude, or prodigious command of programming languages.
But I would argue that those things make you a good computer scientist, which is an academic designation.
“Software engineer” is a job title. And jobs exist to help companies grow, earn money, and deliver value to their customers.
Before We Get to the List, Who Am I to Weigh in on This, Anyway?
Now, before I go any further, I’ll offer some bona fides.
This isn’t to stroke my own ego, I promise. It’s because some of you are probably wondering who I am to proclaim these things anyway. (If you don’t care, feel free to skip to the next section where I start my list.)
So here’s a quick-hitting bullet list of my experience on this topic:
- I have two degrees in computer science (BS/MS).
- I’ve spent more than a decade working with some variant of the job title “software engineer.”
- After spending that decade-plus as a software engineer, I managed software developers as a dev manager and an executive.
- Following that, I worked as an independent consultant, training software engineers in enterprises and doing IT management consulting.
- I’ve interviewed/hired a lot of developers as well as helped companies build software departments and structure their software group’s org charts.
Does any of this make my opinion some inviolate? No, of course not. But it does tell you that I’ve seen and answered the question, “what makes a good software engineer” from a lot of different angles.
A Good Software Engineer…
So with all of that established and out of the way, let’s get to it. A good software engineer does/is all of the following.
1. Is Good at Programming (Don’t Overthink It)
In the beginning, I made a point to say that mastering countless languages, trivia, and programming arcana isn’t necessary to be a good software engineer. But don’t outsmart yourself. Don’t go too far in the other direction.
You need to be good at programming to be a good software engineer.
This doesn’t mean that you need to be great or to have 500,000 points on Stack Overflow. But you need to be able to deliver good working software, without supervision, and consistently.
So if you want to become a good software engineer, you’re definitely going to want to work early and often on your programming. This doesn’t mean you need to go get a degree, necessarily. You can attend a boot-camp, or simply self-teach.
But however you do it, start practicing.
2. Avoids Programming by Coincidence
Alright, now let’s get into some relatively philosophical stuff. (I mean, anything has to be more philosophical than “get good at software to become a good software engineer.”)
Let’s talk about something called programming by coincidence. Put simply, programming by coincidence means that you’re content with your program working, even if you don’t understand why it works.
This might seem like a strangely specific consideration for this list. But here’s the thing.
Programming is a very precise and very detailed discipline. It builds on itself as you go.
So good software engineers need to pay attention to detail and work with precision, or they make messes for themselves. Good software engineers don’t call it a day until their code works and they can explain exactly why it works.
3. Is Curious
In that same vein, a good software engineer is curious. They’re interested in new technologies, new approaches, new patterns, and new state of the art stuff.
They have to be.
The programming landscape changes unimaginably quickly. The world constantly churns out new versions of everything they work with like
- Tools and editors
- Operating systems
- The software that their code runs on
- The programming languages themselves
- All frameworks that they use
I could go on, but you get the point. It’s like being a handyman in a world where new, radically different kinds of hammers and screwdrivers come out every year.
If you’re not curious, you’re going to find software engineering to be a slog. And folks that find it a slog tend not to be good at it.
4. Loves to Build a Thing
Speaking of avoiding the slog, good software engineers enjoy what they do. Specifically, they enjoy the feeling of building a thing.
At first blush, this might seem strange. You might associate this feeling with cabinet-making or being a sculptor or something.
While many of the things that software engineers produce don’t exist in the physical world, per se, there’s still a strong analog. So good software engineers tend to feel a strong amount of drive to keep working, tweaking, and perfecting their software. They’ll also feel a great deal of pride when it’s complete.
5. Is Very, Very Good at Being Understood
Pardon my slight riffing on the HMS Pinafore song, but it felt like a good way to go. A good software engineer is, well, good at being understood. (I didn’t want to go with the eye-roll-inducing “good at communication skills.”)
Getting others to understand you is actually a fairly active concern. And it’s important for software developers to help others understand them, and not just other software developers. After all, developers interact a lot with non-technical folks.
So if you want to be a good software engineer, practice getting other non-technical folks to understand what you’re talking about. Use analogies and metaphors. Break things down simply. Get into the habit of considering it incumbent upon you to bridge the understanding gap.
There are a number of ways that you can do this:
- Train/mentor other software engineers.
- Speak at lunch and learns or user groups.
- Start a blog or a Youtube channel or something.
- Get in the habit of creating executive presentation power points.
If you manage to cultivate a superior ability to communicate, you’ll go far in your career and deliver outsize value as a software engineer.
6. Refuses to be Defeated by a Stupid Computer
Next up, you need persistence. But I prefer to think of this as “I will not be defeated by some stupid computer.”
When you get into programming at first, it’s a lot of initial sugar high. You’re writing “hello world” programs and enjoying lots of small wins as you learn.
But as you dive further down the rabbit hole, you start to encounter frustrations as well:
- Your code just will not compile and you can’t figure out why, even with Google’s help.
- A bug that seems impossible just won’t go away.
- Something in your development environment keeps crashing and you can’t even write code.
I could go on, but I don’t want to depress you or myself.
The point is that good software engineers understand that these setbacks are inevitable. They also understand that they’ll need to get used to overcoming them.
They’ll need to refuse to let the stupid computer win.
7. Constantly Seeks to Tighten the Feedback Loop
Another sign of a good engineer has to do with the so-called feedback loop. To understand what that is, I’ll lead with an example in contrast.
- First, imagine that you take a test, like the SAT. The proctor mails it somewhere and you get your results in 6 weeks.
- Now, imagine that same test, administered at a computer. You finish up, and the computer displays your score immediately.
Example one is a very long, loose feedback loop, while example two is a tight one.
A good software engineer constantly seeks to tighten feedback loops in development. To a non-programmer, the most obvious one is writing some code and then running it to see what it does. But there are a lot of others as well in software development that I won’t dive into here.
But the point is that good software engineers actively think about this and seek to tighten feedback loops to become more efficient.
8. Learns and Masters Their Tools
This next item is closely related to the tightening of feedback loops. In fact, mastering your tools will help you tighten feedback loops.
But it’s also a good goal to chase in and of itself.
Software development involves using many more tools than you might think:
- Various editors (“IDEs”) for actually writing code.
- Source control tools for keeping versions of the software straight.
- Collaboration tools for tracking work.
- Debugging tools to help you chase down defects.
- Performance profilers that tell you if your app is performing well or if it’s slow and sluggish.
And that’s just a representative sample. There are actually plenty more.
To really stand out as a software engineer, you need to make it a point to take full advantage of the tools you use. Don’t just get by. Actively look to learn about them and master their usage to make yourself as efficient as possible.
9. Can Deliver Products (So-Called “Full Stack” Engineers)
We’ve talked before on this blog about the idea of a full stack engineer. I would say that good engineers are “full stack” engineers.
What does this mean? What is a full stack engineer?
Well, to quote from that post,
A “full stack” developer is a software developer with a general enough skill set to build all required components for a working piece of software. They can handle the database, the programming logic, and the user interface, and they put it all together to deliver.
If you want to become a good, well-rounded software developer, you need to be able to deliver a product. And you can’t do that if you’re so specialized that you require other people to intervene in order to deliver software.
This isn’t to say that you can’t specialize in part of the “stack,” nor does it mean you need to master all parts of it equally. But to call yourself a good software engineer, you need to be able to, well, deliver working software.
10. Thinks About More Than Code—Cares About the Business and the Product
In a sense, delivering working software is about more than just the software. After all, someone might reasonably ask, “What do you mean by working? Who says that it’s working?”
If software isn’t useful to the people using it, then it’s not really working. And to understand and measure that usefulness requires skills that you won’t find in an “Introduction to C++” book.
Good software engineers think beyond the code. They think about the users of the software, and they think about the impact their decisions have on their team, their company, and the broader world around the app.
- Would migrating to a new database cause downtime and outages for the users?
- If we use global variables today in order to get something out the door quickly, are we hamstringing our ability to deliver features down the road?
- How are we treating personally identifying and sensitive information that we’re storing?
These kinds of questions enter the minds of good software engineers.
11. Knows When to Embrace Laziness
Here’s a fun one. Learn to constructively embrace laziness.
Relax. I don’t mean that good engineers refuse to work or come to the office hungover and read Reddit all day. It’s more about a programming philosophy that’s something of an adage in software.
Spending all morning doing data entry is hard work (and boring). Copying all of the customer records over from one database to another is hard work (and boring).
Rather than doing a bunch of lazy, boring, and thus, error-prone work, good software engineers take a different approach. They think about how to use their skills to automate the process and let a computer do it for them. Hence, lazy.
The real takeaway here is that good software engineers are always looking for automation opportunities and ways to make things more efficient.
12. Has a Good Attitude and Isn’t a Prima Donna
I’ll close with one that I think, in some senses, is the most important. And this isn’t some kind of mushy, feels-based sentiment. It’s about business.
Good software engineers have a good attitude, and they aren’t prima donnas.
This doesn’t mean they have to be chipper all the time or conduct themselves with the buttery smooth insincerity of the sales guy. It basically means they have to not be insufferable to peers and coworkers and that they should be generally cooperative and helpful.
The image of the anti-social, “tell it like it is” genius programmer is a truly unfortunate one. And it’s a canard largely perpetrated by Hollywood and popular media.
Because here’s the thing, and here’s why I say the most important thing is about business. As someone who has managed, hired, and commissioned software developers to do work, I will take a slightly less proficient software developer that isn’t a team cancer ten times out of ten.
Talented prima donnas infect their entire team/organization, making people miserable, tanking productivity, and creating employee attrition. And that’s bad business.
Good software engineers, on the other hand, combine all of their technical acumen and other skills with a tendency to make the people they’re working with better.
Skills Matter. But Delivering Value Matters More
And this really speaks to the overarching takeaway here, which is that, while skills and efficiency matter, participating in value delivery matters a whole lot more.
Unless you’re writing software as a pure hobby, it’s a business. And if you have a title like “software engineer,” then you’re ipso facto engaged in business. And business is all about value delivery.
So if you want to do well as a software engineer, first and foremost, learn to program. But you should also adjust your mental model of what programmers do and how they help.
Good software engineers take programming skills, and they leverage them into collaborating well with others to build cool stuff. And to do all of that requires a good, well-rounded, business-friendly skill set.
This post was written by Erik Dietrich. Erik is a veteran of the software world and has occupied just about every position in it: developer, architect, manager, CIO, and, eventually, independent management and strategy consultant. This breadth of experience has allowed him to speak to all industry personas and to write several books and countless blog posts on dozens of sites.