What is the definition of a good software engineer?

What is the definition of a good software engineer?

"What is your definition of a good software engineer?" — I like to ask this question to everyone who is somehow involved in software development. And I always get a different answer. It seems that the answer depends on people and their position: managers think that good engineers are those who understand the tasks well, meet deadlines, and have skills. Medium/senior software engineers always start with the words "passion", "good tools", "hard work", etc. QA-engineers see them as an engineering guru who can create error-free code. Team leaders start their description with a combination of soft/hard skills, their ideal software engineer should do everything on time and report any problems they encounter.

Someone (even mature engineers or architects) starts by saying, "Oh, this is a very broad question...". No, it's not. The purpose of this question is to be personal, it focuses on the thoughts of the people you ask it to.

I will show you my thoughts in this post.

They do really think

"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 problem-solving and the programmer engineer must have problem-solving skills. At first, I thought that maybe "Problem-solving skills" would be the right title for the first attribute of a good software engineer, but it has a different meaning. I wrote, "They really think," and I included here not only the fact that they solve problems, but also how they solve them and whether they solve the right problem. It is the sequence of logical thinking, the decomposition of the problem, the digging into the documentation and the final architecture of the solution that shows how good they are.


And the last word on "the right problem". The most productive engineers I have ever worked with are not engineers who drag all night or work 80 hours a week. Nor are they engineers who can effortlessly craft an elegant five lines of x86 assembly. They are the engineers who always solve the right problem in the first place. To borrow an idea voiced by Tyler Treat, Phil Haack, and probably many others: software engineers are not paid to just create lines of code. If we take a step back, we are really paid to solve problems, scale, make things more efficient, or prevent crashes. Code is a by-product of solving these business problems, but the business problems that we need to solve are the primary ones.

They have the willingness to learn

learn java

Yeah, that's the second attribute of a great software engineer to me. Technologies are constantly changing, and the skills and abilities that today's software engineer has are likely to become outdated in a few years. A good software engineer has an instinct to seek knowledge, and he knows that his area is always changing. Robert S. Martin wrote in The Clean Coder that you should give 40 hours a week to your employer and spend 20 hours reading, learning, and practicing.

It also made me more comfortable in my own programming skin when I realized that geniuses still struggle, get upset, feel uncomfortable, forget, learn, and make mistakes. The difference is that a genius keeps going, keeps making mistakes, admits — and learns from mistakes. Failure is an opportunity to be used, not to be afraid.

They go to the source


Documentation, tests, people: these things lie. Not intentionally, but if you want to know exactly how something works, you must take a look at the source yourself.

Don't be afraid if it's not a language that you are very familiar with. If you are a Python engineer in the first place and suspect that a mistake has occurred in one of the Python libraries in C, open it and take a look. Yes, you may not understand. But who knows? You just can, and you have a better chance than if you hadn't tried at all! If you're in a closed-source environment, unfortunately, it gets much harder, but the principle still applies.

Bad engineers have little interest in browsing the source code and trust a third party's opinion, a blog post, and as a result, problems beat them much longer than those who want to do some research.

They want to be good engineers...

good developers

...and make company better.

Here I want to say that they have this strive for excellence, always not for themselves, but for their team and their company as well. Despite the lifetime of television and Hollywood movies glorifying the lonely hacker, the reality is that all the development in all companies takes place in teams.

The sooner you start writing code with the others, the better you'll be. You can start by pulling code from GitHub on open source projects, contributing, and receiving feedback from the community. Participating in training sessions, participating in team challenges and code reviews is a good way to gain some experience.

...and make others better.

So good software engineers don't work in a vacuum, they try to communicate with others to gain new knowledge or share their experiences. They try to mentor and teach others if they see that they can help. Also, they want to know the product, the business plan, the direction of product development, the company in order to help.

...and make product better.


Among software engineers, I see a common disease per se — the disease of "Not my problem" where engineers finish his task from over here to over there and then he is done. It doesn't matter for him that this is a bad interface or it's clearly a bad design, or the arguments of the function are messed up. It is not his problem. But it is, there are some quality gates, some definition of done, some dev guidelines, etc. A good engineer understands that any problem with our product is our problem to fix.

Among software engineers, I see a common disease as such - the disease "Not My Problem", when engineers finish their tasks from here to there, and he is done. It doesn't matter to him that it's a bad interface or obviously bad design, or that the function arguments are confusing. This is not his problem. But it is. There are some quality gates, some definition of what's done, launch the linker, leave instructions just in case, describe the merge quest well, cover your piece with tests, etc. A good engineer understands that any problem with the product is his problem that needs to be fixed.


All of the above skills are generic – none of them are specific to any one language, framework, technology or level. If you have them, you can quickly learn a new language or tool, and write good software in any environment. Furthermore, because they are general in nature, they will not become obsolete in a couple of years. You can teach anyone how to write code — this is not an indicator of a good software engineer.

These are my answers to what makes a good engineer. What do you think makes a good engineer? Let me know in the comments.

Buy me a coffee