What is the definition of a good software engineer?

I love asking this question to anyone involved in software development, and every time, I get a different answer. The answer seems to depend on the person and their perspective: managers often say good engineers are those who understand tasks, meet deadlines, and have the necessary skills. Mid/senior engineers talk about "passion," tool mastery, frameworks, "hard work," etc. QA engineers tend to see them as technical wizards capable of creating flawless code. Team leads emphasize a mix of hard and soft skills, describing their ideal engineer as someone who delivers on time and reports issues proactively.

Some — sometimes even mature engineers or architects — begin by saying, "Oh, this is such a broad question". But, honestly, it’s not. The question is intentionally personal; it’s meant to capture individual insights from those you ask.

In this post, I’ll share my own thoughts.

Demonstrating computational thinking or the ability to break down large, complex problems is just as valuable (if not more so) than the baseline technical skills required for a job.
– Hackerrank

Programming is about problem-solving, and a true software engineer is a problem-solver at heart. Initially, I thought the best title for this attribute would be “Problem-Solving Skills,” but it didn’t quite capture it. Instead, I wrote, “They Really Think.” This covers not just the fact that they solve problems, but how they solve them and whether they’re even solving the right ones. It’s the sequence of logical thinking, breaking down a problem, sifting through documentation, and ultimately designing an elegant solution that shows their quality.

And about solving the "right problem": the most productive engineers I’ve worked with aren’t those grinding 80-hour weeks or those who can craft five lines of elegant assembly code. They’re the engineers who consistently solve the right problems from the get-go. Borrowing an idea from Tyler Treat, Phil Haack, and others: we’re not paid just to create lines of code. We get paid to solve business problems, streamline operations, improve efficiency, or prevent failures. Code is just the byproduct of addressing those core business needs.

source

At the core, a great software engineer identifies as an engineer first, not just as a coder or a developer. This distinction is subtle but essential. Engineers think in terms of systems, structure, and longevity. They aren't satisfied with just “making it work.” They ask: Does it scale? Is it maintainable? Does it introduce technical debt, and if so, is it worth it?

Being an engineer first is about having a builder’s mindset — solving with structure rather than quick fixes. They understand the fundamentals of architecture and design patterns, know when to sacrifice aesthetics for performance, and can balance today’s needs with tomorrow’s scalability. This mindset means they’ll think through requirements, assess system constraints, and make pragmatic trade-offs before writing a single line of code.

An engineer-first mindset is also about responsibility: they see the bigger picture and recognize their role in creating software that people depend on. It’s a sense of ownership over their code, but more so over the system itself. So while they may not always be the ones "doing it all," they're always aware of how their contributions impact the stability, performance, and evolution of the entire system.

For me, the second hallmark of a great software engineer is the desire to learn. Technologies are constantly evolving, and today’s in-demand skills could easily become obsolete in a few years. A great engineer has an instinct to seek knowledge and understands that the field is always shifting. In The Clean Coder, Robert C. Martin suggests dedicating 40 hours a week to your employer and 20 hours to reading, learning, and practicing to stay competitive.

It also made me more comfortable in my engineering skin when I realized that even geniuses still struggle, get frustrated, feel stuck, learn, and make mistakes. The difference is that they keep going, keep making mistakes, admit them, and learn from them. Failure is an opportunity to be used, not to be afraid.

Documentation, tests, and even people can mislead — not intentionally, but if you really want to know how something works, you have to look at the source yourself.

Don’t worry if it’s unfamiliar territory. If you’re a Python engineer and suspect a bug in one of Python's C libraries, open it up and take a look. Will you understand it immediately? Probably not. But you just might. Even in proprietary environments, where it's harder, the principle still applies.

Bad engineers are often too quick to rely on third-party opinions, blog posts, or other secondary sources. The best engineers know that firsthand research saves time and leads to deeper insights.

Good engineers don’t work in isolation. Despite Hollywood’s “lone hacker” trope, real development happens in teams. They have a drive for excellence, not just for themselves but for their teams and companies.

The earlier you start coding with others, the better. Start by contributing to open-source projects, joining discussions, and learning from feedback. Training, pair programming, and code reviews are all great ways to grow.

Great engineers understand that software development is a team effort, and the strongest teams are built on knowledge sharing and collaboration. They aren’t just focused on their own tasks—they actively engage with their teammates, offering help, sharing insights, and learning from others.

When they spot someone struggling with a problem they've solved before, they lend a hand or share a useful resource. They’re also open to feedback, seeing every code review as a chance for mutual learning. Good engineers build up their team by fostering an environment where questions are welcomed, knowledge is shared, and everyone has the chance to improve. This doesn’t mean they’re formally responsible for teaching others; rather, they just care about team growth and recognize that when one engineer improves, the whole team benefits.

There’s a common “Not My Problem” mindset among some engineers. Once they finish a task, they move on, ignoring bad design, confusing interfaces, or poor UX. It's not his problem.

But it is.

While they’re not solely responsible for the entire product’s quality, they recognize that their part matters. They raise concerns, suggest improvements, or even take a few extra minutes to make a small fix. It’s not about owning the product’s quality alone—it’s about being invested enough to elevate their area of responsibility and work collaboratively toward a better product.

These are my answers to what makes a good engineer. What are yours? Share in the comments!