"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 a different answer. It depends on the people and their positions: managers see good software engineers 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.
Priorities (https://t.co/g3PVqokNIV) pic.twitter.com/h2noouHFOp
— monkeyuser (@ismonkeyuser) October 17, 2018
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
Yes, it's the second feature of great software engineer for me. Technology is always evolving and the skills and abilities a software engineer has today will likely to be outdated in a few years the same counts for problems engineers have to face. A good software engineer has the instinct to seek knowledge, and he is aware that his field is always changing. Robert C. Martin wrote in The Clean Coder that you should give 40 hours a week for your employer and spend 20 hours for reading, learning and practicing.
Also, that made me more comfortable in my own programmer skin when I was realizing that geniuses still have struggles, get frustrated, feel inadequate, forget, learn, and make mistakes. The difference is, a genius keeps going, keeps leaning, admits to - and learns from mistakes. Failure is an opportunity to be used, not feared.
They go to the source
Documentation, tests, people: these things lie. Not intentionally, but if you want to know exactly how something works, then you must view the source yourself. 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 a result, problems flummox them much longer than those who are willing to do some research.
They want to be good engineers...
...and make the 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 the product better.
Among software engineers, I see a common disease per se - a 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.
Conclusion
All of the above skills are generic – none of them are specific to any one language, framework, technology or even level. If you have them, you can quickly learn a new language or tool, and write good software in that 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.
Thank you for reading!
Any questions? Leave your comment below to start fantastic discussions!
Check out my blog or come to say hi 👋 on Twitter or subscribe to my telegram channel.
Plan your best!
Top comments (0)