"What is the definition of a good software engineer" - I like to ask this question everybody who somehow connects to software development. And I always got different answer. It depends on the people and their positions: managers see good software engineers to have a good understanding of the tasks, respect deadlines and soft skills. Middle/Senior software engineers always start with the words passion, good tools, hard skills etc. QA engineers see them as a programming guru which can produce testable, bug-free code. Team leads start their description with the mix of soft/hard skills, their ideal software engineer should do everything in time and report any problems they face.
Somebody(even mature engineers or architects) starts with words: "Oh, it's a very wide question...". No, it is not. This question's aim is to be personal, it focuses on the thoughts of the people you're asking it.
I will show you my thoughts in this post.
They do really think("Measure twice, cut once")
"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 all about solving problems and a software engineer should have problem-solving skills. At first, I thought that maybe " Problem-solving skills" will be the right heading for the first feature of the good software engineer but it carries a different meaning. I wrote - "They do really think", and I include here not only the fact that they solving problems but also how they solve them and whether they solve the right problem. It is the sequence of logical reflections, the problem decomposition, the digging in the documentation and the final architecture of the solution that shows how good they are.
And the final word about "the right problem". The most productive engineers I’ve ever worked with aren’t the engineers who pull all-nighters or clock in 80 hour work weeks. Nor are they the engineers who can effortlessly craft an elegant five lines of x86 assembly to succinctly and efficiently solve a problem. They are the engineers who always seem to be solving the right problem in the first place. To borrow an idea voiced by Tyler Treat, Phil Haack, and likely many others, software engineers aren’t paid to simply produce lines of code. If we take a step back, we’re really paid to build features, make things more efficient, making them scale bigger and bigger, and fix issues or prevent outages. The code is a byproduct of solving these problems, but the problems we need to solve are primary.
They have the willingness to learn
They go to the source
Don’t be afraid if it’s not a language you’re super familiar with – if you’re primarily a Python engineer and you suspect there’s an error in one of Python’s C libraries, go crack it open and have a look. Yes, you might not get it. But who knows? You just might, and you stand a way better chance than if you didn’t try at all! If you’re in a closed-source environment then this becomes a lot harder, unfortunately, but the principle still applies. Poor engineers have little interest in viewing source, and as result problems flummox them much longer than those who are willing to do some research.
They want to be good engineers...
...and make company better.
Here I want to tell that they have this strive for excellence, always not for themselves but for their team and their company as well. Despite a lifetime of TV and Hollywood movies glorifying the lone hacker, the reality is all development in all companies happens in teams.
The sooner you begin writing code with others, the better you’ll become. You can start by pulling code from GitHub on OpenSource projects, contributing and getting feedback from the community. In training, participating in team challenges and code reviews is a good way to get some experience.
...and make others better.
So good software engineers don't work in a vacuum, they try to communicate with others to get new knowledge or to share their experience. 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 where the development of the product is headed in order to help.
...and make product better.
Among software engineers, I see a common disease per se - disease of "Not my problem" where engineer 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.
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.
These are my answers to what makes a good programmer. What do you think makes a good programmer? Let me know in the comments.