Having good engineers on your team can make the difference between a project's success or failure. Good engineers are able to jump in and solve problems, design the solution, and implement the code to make it all work. They may be on the team from the start, or brought in at the end to help get the project on track and ready to ship. The bottom line is they get things done. Every company desires for their development team to consist of good engineers or better, however, the good engineers are not easy to find. To maximize your value, what you should be looking for are the great engineers. What's the distinction?
- Good Engineers write solid code and get the job done.
- Great Engineers make it possible for the other engineers to become Good Engineers.
A Software Engineer's Role
Before I can further differentiate between the Good and Great engineer, I think it is important to define what the industry expects from software engineers in general. For simplicity, I am going to reference the description listed from Salary.com description. This description is for the highest ranked job defined for a software engineer at salary.com. The description is most likely limited by a maximum character count for the job description. Nonetheless, these are the tasks and skills expected of a top-level software engineer. I also summarize the underlying skills and qualities that are important for each of the items in the job description:
- Perform tasks in the entire software development lifecycle
List of expected duties, no qualities
- Provides technical support to team members
- May provide consultation on complex projects
- Demonstrates expertise in a variety of the field's knowledge
- Relies on extensive experience and judgment to plan and accomplish goals
- A wide degree of creativity and latitude is expected
A Competent Engineer
The world is filled with a variety of people that all possess a diverse set of skills, talents and traits. This statement also applies towards engineers. It is inevitable that someone incompetent will find their way into a position working with you. Therefore, let's start with an analysis of what the expectations are for competent engineers to set the baseline for a software engineer. A quick review of the list shows there are only a handful of traits that are defined, in the context of computer science:
- Communication (2)
- Expertise (3)
- Good Judgment
This is one of those qualities that should be a no-brainer for any employee. Someone that does not use good judgment becomes a liability. Certainly for the design and code work they create, however they may possibly even be a liability to your company. There is much more we could say, but let's move on.
I did a cursory glance at the other skill level descriptions for software engineers one through four and communication seems to enter a level of importance around skill level three, in the form of may direct the work of others. Levels four and five add a statement about providing technical support of others. It is unfortunate that the programming profession attracts a disproportional amount of the population that are introverts, many which have a difficult time communicating effectively.
I believe you need to be an effective communicator at every level to perform competently at a job. If for no other reason than to properly articulate that you understand what you are expected to do. However, as the rank of engineer increases, so does the importance of the communication skills of the engineer. Higher ranked engineers are the mentors of the engineers newer to the profession. Many times these engineers are also the team leads of the newer engineers. Having the ability to effectively communicate expectations and have technical discussions with all skill levels of individuals is a must at the highest rank.
Expertise is gained through experience. It makes sense then that expertise is expected to help guide the engineer more and more as they rise in rank. Expertise may be deep knowledge of a specific domain, or a breadth of knowledge that spans many domains. Either way, the knowledge the engineer has gained throughout their career is an invaluable and non-tangible asset to the company. While you are employed with a company, they expect to tap in and take advantage of every bit of that expertise that you bring with you.
"Thinking Outside of the Box", it's ironic that they put us in boxes (cubicles) to work. I like to scoot my chair outside of my cube tell my co-workers, "Look! I'm Thinking Outside of the Box!" Creativity is valuable when solving problems. That is one of the difficulties of computer programming, there are so many damn ways to solve the problem. How do we know which way is the best? Trying to troubleshoot an issue, overcoming a limitation of the system. There are many ways in which creativity is valuable.
This skill seems to be the one that is difficult for many engineers to overcome, adapting to change. Our industry is moving at a dizzying speed, so many new technologies come and go, which one should I embrace, or should I stick to what I know? This is where your expertise and good judgment need to be used to help guide you. Otherwise, opportunities like Y2K for the COBOL developers don't come along very often. Change is inevitable, embrace it, with good judgment.
A Good Engineer
The type of engineer that I am referring to when I say Good Engineer is the go to engineer that can have a task thrown at them, and before you know it, the problem is solved. What your other small team of engineers couldn't solve in a week, the go to engineer solved in a few hours. You can count on this type of engineer to produce results. What traits might they possess to differentiate themselves from the others?
Let's be clear, a Good Engineer can exist at all levels of the Software Engineer hierarchy. While they may not have an extensive knowledge base of expertise to guide them, they are still able to get the job done. I have seen incidents where the entry level engineers outshine the senior engineers. Hopefully in cases like this, the senior engineers realize we are all on the same team and work for the same company; I should take note and learn from this.
Intelligence is a valuable trait, especially with respect to computers. The Good Engineer does not need to be a supra-genius or even a genius, but they are smart. They observe and soak up information, which can be applied to their knowledge bank, expertise. They learn multiple ways to solve problems, and are actually able to apply the most appropriate method to the solution.
Intuition is that background processor running in your right brain, it doesn't have a voice, but somehow it feeds you the ideas and feelings you get about something. All of your previous experiences are considered, and the similarities allows the right brain to reach an educated guess. Intuition can be a great guide, when you're right. Intuition is not always right. A Good Engineer could be less intelligent and rely more on intuition to guide them. Alternatively, a less intuitive engineer of high intelligence still has the potential to be a Good Engineer. I believe there needs to be some sort of balance between the two in order to have an engineer that just seems to have a knack for solving problems.
This is one of the most important traits to look for when hiring an engineer. Are they an engineer because they simply love their profession and have a deep love for what they do, or are they an engineer because that's how they earn a paycheck? Drive and ambition are closely related to this, and could be a possible, but they are not the same thing. Passionate software engineers educate themselves and try to improve their practice of the craft. Often, they will have hobby projects they work at home (if they don't spend all of their time at the office.)
I wanted to make a quick note about a good engineer's communication skills. They do not have to be spectacular. Many of these engineers are very intelligent and want others to know it. This can make it difficult to work with these types of engineers. They thrive in their position because they produce results. Unfortunately, they tend to safely guard the knowledge they have acquired and do not share it freely. They become knowledge silos storing away information that only they will be able to access in the future.
A Great Engineer
We have covered the Competent Engineer and Good Engineer, so what qualities make a Great Engineer? The distinction between good and great, is how the engineer's work and interactions affect the productivity of the other engineers. Great engineers make it possible for the other engineers to become good engineers. The great engineer produces results just like the good engineer, however, the total production may not be as much as the good engineer. This is because more of their time is spent focusing on outward problems and issues. This is in the form of sharing knowledge, documenting tricky procedures, or mentoring others. You do not need many great engineers on your staff, because the greatest asset they bring to the company is the positive effect they have on the productivity of the other engineers. They fit in with just about any team, and can produce like a good engineer when needed.
- Great Communicator
Communication is key. Articulating your ideas in a way that others can understand is invaluable. This requires the ability to adapt to your audience. Other engineers may be interested in the minute details for how you solved a problem, however, you will be speaking gibberish, and wasting time and testing patience if you use that much detail with an executive. Communication does not need to be limited to speaking. Visual presentations and drawing can be a very effective way to communicate as well. Pair the two together and your audiences will be repeating your clear explanations until they come back to you full-circle.
An important part of communication that many of us forget, is to stop talking and listen. No value is possible if everyone can clearly and precisely express their ideas, but no one ever listens. Sitting back an simply listening, taking a few notes when the project managers, lead product engineers, and customers are all in a room is a very valuable position to be in. Sitting on the outside of a conversation trying to understand what both sides are trying to say without arguing your own point makes extracting the messages so much simpler. Then later, you will be better equipped to know what you need to say.
Part of enabling others to be more productive is to inspire others to do better. The inspiration may come in the form of teaching a simple technique to better organize a data structure, which then saves time for the rest of development. Inspiration could come in the form of encouragement, letting others know you think they're doing a good job especially if you are in a position of visibility.
One of the most inspiring incidences that I have witnessed is when a great engineer was tasked to takeover the management of a project that was three-months behind on a project that only had three-months left until the deadline. This engineer halted development and 1) The engineers that had a negative attitude, reducing productivity were re-tasked to new projects. 2) He asked if everyone understood what the product they were building did. Almost no one understood the purpose. He went over the system and what it would be capable of when they were done. At that point, everyone was able to see where their bit of effort was going to fit into the final solution. Soon the team was hitting every milestone and the project completed on time.
Many managers say "I have an open door policy", and an engineer will say "Let me know if you have any other questions". However, when you try to hit them up on their offer, they act all put out, and you are interrupting something that is much more important than you are. Great engineers are inviting and approachable. If you have a question that you feel really stupid asking, they don't mind, in fact they make you feel good for asking. Next thing you know, your off working again, even passing on that knowledge to the next guy. Great engineers cannot share their knowledge unless other engineers want to be around them. Most other engineers are there trying to do a job just like you, and sometimes a little help is all they need to find their own way.
I have gone through a small list of qualities that you would like your engineering staff to have. The least we could hope for is that all of our co-workers are competent at what they were hired to do. The next class of engineer is the good engineer, there are far fewer good engineers compared to competent engineers. Good engineers are high-producers, and can reliably get the job done. The final class of engineer I discussed was the great engineer. The great engineer may not produce nearly as much as the good engineer, however, they make up for it by improving the productivity of all of the engineers around them. They are able to inspire competent engineers to become better and produce like the good engineers.
These are the patterns and traits that I have noticed in the people I have worked with throughout my career. These traits are the commonalities in the people I think of that inspired me to do better, or some of the compliments that I have received when I was trying to help someone else do better. I strive to be greater each day. What are your thoughts? Are there traits or qualities that you see that differentiate between the people that really inspire everyone that works around them?
I am a software architect and I have been developing software for nearly two decades. Over the years I have learned to value maintainable solutions first. This has allowed me to adapt my projects to meet the challenges that inevitably appear during development. I use the most beneficial short-term achievements to drive the software I develop towards a long-term vision.
• Consumer Products
• Computer Infrastructure Management
• DoD Contracting
My experience spans these hardware types and operating systems:
o Windows (Full-stack: GUI, Application, Service, Kernel Driver)
o Linux (Application, Daemon)
• Mobile Devices
o Windows CE / Windows Phone
• Embedded Devices
o VxWorks (RTOS)
o Greenhills Linux
o Embedded Windows XP
I am a Mentor and frequent contributor to CodeProject.com with tutorial articles that teach others about the inner workings of the Windows APIs.
I am the creator of an open source project on GitHub called Alchemy
], which is an open-source compile-time data serialization library.
I maintain my own repository and blog at CodeOfTheDamned.com/
], because code maintenance does not have to be a living hell.