"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. The answer seems to depend on people and their attitude – managers think that good engineers are those who understand tasks well, meet deadlines, and have the required skillset. Mid/senior software engineers always start with "passion," tooling, framework knowledge, "hard work," etc. QA engineers see them as engineering gurus who can create bug-free code. Team leaders begin their description with a combination of soft/hard skills, their ideal software engineer should do everything on time and report any problems he or she encounters.
Some (even mature engineers or architects) start by saying, "Oh, this is a very broad question..." No, it isn't. The purpose of this question is to be personal; it focuses on the thoughts of the people you are asking 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 about solving problems 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 a little bit about "the right problem". The most productive engineers I have ever worked with are not engineers who work 80 hours a week. Nor are they engineers who can effortlessly create elegant five x86 assembly lines. They are the engineers who always solve the right problems 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 actually get paid to solve business problems, support business operations, make things more efficient, or prevent failures. Code is a byproduct of solving those problems, but the business problems we need to solve are the primary ones.
They have the willingness to learn
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 to be competitive.
All the time! Just now I had to look up how re.split() works with optional capturing groups in the regex.
— Guido van Rossum (@gvanrossum) December 11, 2018
It also made me more comfortable in my engineer skin when I realized that geniuses still struggle, get frustrated, feel uncomfortable, forget, learn and make mistakes. The difference is that genius keeps going, keeps making mistakes, admits them, and learns from them. Failure is an opportunity to be used, not to be afraid.
They go to the source
Documentation, tests, people – all these things lie. Not intentionally, but if you want to know exactly how something works, you have to look at the source yourself.
Do not be afraid if it is not a language with which you are familiar. If you are a Python engineer and you suspect there is an error in one of the Python C libraries, open it up and take a look. Yes, you may not understand it. But who knows? You just might. And you'll have a better chance than if you didn't try at all! If you are in a proprietary environment, unfortunately, it becomes much more difficult, but the principle still applies.
Bad engineers have little interest in looking at the source code and trusting a third-party opinion, a blog post, and as a result, problems take them much longer than those who want to do some research.
They want to be good engineers...
...and make company better.
My point here is that they have this drive for excellence, always not for themselves, but for their team and their company as well. Despite television and Hollywood movies glorifying the lone hacker, the reality is that all development in all companies happens in teams.
The earlier you start writing code with others, the better off you will be. You can start by pulling code from open source projects, contributing, and getting feedback from the community. Participating in trainings, pair programming, and code reviews is a good way to get some experience.
...and make others better.
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. They also want to know the product, the business plan, the direction of the product, the company to help.
...and make product better.
Deal with it. pic.twitter.com/2NfQTvHTHl
— Nasser (@Nasser_Junior) January 23, 2020
I see a common disease among software engineers, the "Not My Problem" disease, where the engineer finishes his tasks from here to there, and he goes home. It doesn't matter to him that it's a bad interface or an obviously bad design, or that the function arguments are confusing. It's not his problem. But it is. There is the quality gate, the definition of done, linting, documentation, test coverage, etc. A good engineer understands that any problem with the product is his problem to fix.
These are my answers to the question of what makes a good engineer. What do you think makes a good engineer? Let me know in the comments.
Buy
me a coffee