While it is difficult to quantify productivity differences between engineers, it’s very easy to observe a significant difference between the best engineers and even the average one. Attempts have been made to quantify the potential productivity difference between good and great engineers, and claims have been made that the great ones can be 10 to 30 times more productive than their average counterparts. An interesting discussion on some of these studies can be read here. There will certainly be continual contention and debate about these numbers. Regardless of the statistics of the subject, the question of interest here is what, exactly, are the distinguishing factors? In this post I’ll talk about some of the things I’ve observed from my own experience and discussions with other engineers.
I’ve divided the traits into 3 categories: foundational, skills, and mindset. The foundational traits are the ones that I consider to be the core characteristics of top quality software engineers. These are the traits that the best engineers I’ve worked with always have, and that the average ones usually lack to some degree. The skills category holds the set of skills that I have noticed every good engineer has to some degree, and that the best have developed to a high level. Finally, the mindset category is the set of personality or character traits that I have observed to have a direct influence on the competency of the engineer.
We’ll start with the two foundational traits: leadership and great communication skills.
High quality engineers almost always have great leadership skills. Those who are able to guide their teammates to solve problems and address challenges as effectively as possible can significantly improve the productivity of everyone on the team, even if they don’t write a single line of code. By having the ability to help each of their teammates overcome a variety of challenges, the engineer with leadership skills is able to guide the direction of the team as a whole, ensuring that everyone is working efficiently toward the same goal. This helps to prevent the team from moving in too many directions or from losing focus on what they need to be doing.
Additionally, software engineers who can lead are capable of handling disagreements or arguments between team members. This is important because when there is contention within the team, people start becoming less collaborative, and may even become defensive and unwilling to share their work for fear of it being irrationally criticized. Instead of using seniority or job title to enforce his influence, the engineer with good leadership skills can almost always work out a compromise between teammates involved in a disagreement. This allows the team to continue moving forward and prevents anyone from feeling like they haven’t been listened to or aren’t valued.
Finally, good leaders help to inspire, educate and motivate the team who works with them. Their presence alone allows their more junior teammates to learn from observation and encourages them to want to perform better.
By being able to guide the team in a unified direction, to resolve conflict within the team along the way, and to motivate and inspire the team toward doing a good job, the engineer with leadership skills improves the entire team’s productivity. This is what makes the leadership trait one of the most highly desirable traits to have.
2. Great communication skills
Given that the software development lifecycle requires frequent collaboration with a variety of people and teams, it is critical for there to be engineers who are able to communicate about the technical side of their project to anyone involved in the project. Additionally, it’s also very important for these engineers to understand the business value of the work they’re expected to perform. While business analysts, product owners and managers often don’t need to know all the technical nuances of a problem being worked on, it’s almost always important for them to have a solid understanding of what problem is being solved, why it is being solved, and sometimes even how it is being solved. If the engineer is only able to communicate effectively with other engineers, he will be less valuable than the one who is able to convey his ideas using a variety of approaches that can resonate with anyone. Again, this comes back to the notion that the most valuable engineers are able to enhance the productivity of the people around them. In this case, having great communication skills means the engineer will have aptitude with:
- communicating with management about the direction of the project as a whole and any of its impediments
- collaborating with other teams to help manage the dependencies they have on each other
- working within their team with other engineers who have different skills and levels of experience
As part of their communication with the variety of people they’ll need to interact with, engineers with great communication skills are often very persuasive. While it’s valuable to be able to understand and convey information relating to the software project, the best engineers are also expected to contribute ideas about how to modify processes and plans in order to increase the team’s productivity. In order to do this, a good deal of persuasiveness is necessary. Without it, the engineer may be able to understand a great deal about the project, but won’t be able to effectively address problems and concerns.
An engineer who can communicate technical topics to non-technical stakeholders, who can understand the business requirements and values as communicated by people outside of the development team, and who are persuasive enough to drive actions to improve the team’s productivity, are valuable for the same reason as mentioned above: because they can dramatically increase the productivity of the people around them.
Transitioning from the foundational traits, we’ll move into skills category by starting with efficiency. There are, of course, many ways in which a software engineer can be efficient, so I’ll just focus on the ones that seem to have the greatest impact.
One of the most prominent characteristics of efficient software engineers is that they are always aware of how they’re spending their time. This helps them to avoid going down any “rabbit holes” which suck away their time and prevent them from working on something that has a greater impact. One example is that an efficient engineer will recognize when he’s spending too much time in meetings instead of working on building the product. Another example would be an engineer spending hours to try to style a UI component just right when the product owners and users don’t place much value on the application’s style.
In the case above, the efficient engineer will spend some amount of time trying to resolve the problem, but will quickly take a step back and communicate the large amount of time that will be necessary for implementing the style to his product owners and manager. He will almost always frame his current action or activity against the scope of the project as a whole, allowing him to recognize when it’s time to move on from something. This will ensure that the engineer can either transition to a more important task and accept the styling in a less-than-optimal state, or to continue spending time on finishing the implementation, but now with affirmation that this task is the most efficient use of his time.
Another important characteristic of efficient engineers is that they know how to leverage the knowledge and experience of the people around them. When they run into issues or challenges during their work, they quickly look to have a discussion with someone who has dealt with similar challenges before (this is, of course, after doing at least a reasonable amount of due diligence on their own instead of relying on everyone else to solve their problems). By utilizing the knowledge of the people around them, they save time on their work and might even gain perspectives that they otherwise wouldn’t have gotten. An implication of this is that the efficient engineer is also good at keeping a mental note of what skills each person they work with has. This allows them to go directly to the right person when there’s a question that needs to be asked or an action that needs to be taken, instead of going to the wrong person and then having to be redirected to someone else.
As is often mentioned by advocates of the Agile methodology, the development team should be comprised of engineers who do not have highly specialized skills but instead are able to contribute to most if not all areas of the software development lifecycle. Whether your team does or does not follow the Agile methodology, it is likely that the versatile engineer is more valuable than the less versatile one, except in the cases where highly specialized skills are desirable.
The more versatile an engineer is, the more likely he is to be able to contribute to multiple areas of a project. This allows for more fluidity within the team, which is desirable since software development is usually not a linear process. For example, there may be a situation where an API has been completely written, tested and ready to consume, but the UI that needs to plug into this API is more challenging and is taking a lot longer to finish. If some of the engineers on the team were “the UI guys” and the others were “the backend guys”, then the feature would be bottlenecked by the UI work. Not only does this delay the particular feature being delivered, but it might even cause the backend engineers to be idle for some period of time.
On the other hand, if each of the engineers on the team was able to contribute both to the API side as well as the UI side, they could swarm on the UI tasks and complete them more effectively. Doing this ensures that the feature is being delivered as quickly as possible and that nobody is sitting around waiting on someone else before they can move on.
The skillset of a versatile engineer isn’t just limited to what technologies they’re comfortable writing code in. Because writing code is only part of the lifecycle of a software project, it’s important that the engineer develops a good level of aptitude in the other areas of software development. The most versatile engineers are able to competently do the following:
- Contribute to the requirements planning process and/or help write acceptance criteria for user stories
- Able to document technical requirements, solutions to technical problems, and anything that will be worked on by other engineers or used by other teams
- Able to perform code reviews and provide feedback on code that their teammates have written
- Able to contribute to QA efforts by writing test cases, performing manual QA testing, and writing some QA automation tests
5. Ability to multi-task
As an engineer becomes more knowledgeable and develops his skillset, more and more people will begin asking things of him on a day to day basis. People will begin to want to tap into this engineer’s knowledge, so he’ll need to be able to work in different contexts and areas throughout the day in order to help each of these people. For example, he might be writing code to shape and store data in a database, then get pulled into a meeting to discuss the technical details of a feature that the product owners want to see a few months later. When he gets back to his desk someone might ask him a question about how to implement some functionality in AngularJs. Someone else might ask him to review their code.
These types of interactions are inevitable for a valuable engineer, and this is precisely the reason why most high quality engineers are very good at multi-tasking and context switching. If this type of engineer cannot learn to do this, their productivity will suffer and the people who need things will have a harder time getting what they need.
Another element to this is that because the valuable engineer will have many different things going on concurrently, they need to know how to prioritize all of the tasks that they are being requested to perform. For example, if an engineer is requested to help one of his teammates who is stuck when building a feature that needs to be delivered within the next few days, but someone else wants this engineer to join a meeting to discuss something coming in the future, the engineer will likely prioritize helping his teammate over joining the meeting.
6. Knowledge of system design
It is a practical skill for an engineer to have a good knowledge of designing systems. This is because the vast majority of professional engineering projects are ultimately scoped to be large and complicated. Designing a system for dozens of concurrent users is not a trivial undertaking and is certainly not the same as designing for a single user. Building an application where people provide personal data such as credit card information requires a very solid understanding of security at multiple levels of the application. Setting up an architecture such that multiple engineering teams can work on the same product requires an understanding of the pros and cons of different architectural design patterns.
The point is that at least one engineer must be able to design important parts of the application that is being worked on; at some point, someone has to come up with a design. The highest quality engineers are able to take a business requirement and translate it into an engineering design that: (1) is sufficient to meet the specifications of the business requirement (2) has the smallest number of tradeoffs that might cause problems in the future, (3) can be understood and implemented by almost any engineer on the team, and (4) is as simple as possible (i.e. does not contain any unnecessary components, also known as “gold plating” or “future proofing”).
The thing to keep in mind here is that, given the high level of complexity of a typical application, it’s highly unlikely for a single engineer to have sufficient knowledge of all areas of application design to perform the design by themselves. So the key is that the engineer is at least cognizant of most of the different areas that they need to keep an eye out for. This allows them to reach out for help from more knowledgeable people about the areas that they are less familiar with.
For example, an engineer might not be an expert in security, but he can be relied upon by stakeholders to reach out to people more knowledgeable about security and come up with a secure design if he is at least knowledgeable about the importance of security. In contrast, an engineer who doesn’t recognize the importance of security in system design cannot be relied upon because he won’t even know to ask for help when security-related issues come up.
By being able to design system-level components and modules – both from his own knowledge and from knowing who to reach out to and what to ask about – the high quality engineer provides the translation from business requirement to implementation, a necessary step in the delivery of any product. Because it is not an easy skill to acquire and because it’s a necessary skill for any non-trivial engineering project, having good knowledge of system design is typically a trait of the highest quality engineers.
7. Knowledge of design patterns
The best software engineers have a handbook of design patterns stored away in their brains, ready to be utilized when a problem comes up. The value of this is very simple to understand. It allows the engineer to solve complicated problems by leveraging the knowledge and experience of other people who have already solved the problem. This significantly reduces the amount of time that the engineer needs to spend on working out the problem because they will already have a good idea of how to solve it.
Compare this to the engineer who does not have knowledge of design patterns. The less knowledgeable engineer will spend time reasoning about and researching the problem while the other guy will have already started implementing a solution. Additionally, the engineer who doesn’t know the patterns is much more likely to come up with a poorly optimized solution that will be hard for other engineers to understand and will need to be refactored later on.
While experience alone can help an engineer learn design patterns, you certainly don’t need to have 10+ years of experience to have a good understanding of them. Many engineers will use a design pattern but do not make any attempts to understand it, which will put them behind the engineers who use and study the patterns. This allows an engineer with fewer years of experience to be more knowledgeable and therefore more valuable in cases where these problems arise. Whatever the case is, engineers who have a good set of design patterns in their toolbox will be more valuable than those who do not.
8. Offer solutions to problems
Engineers are typically hired to solve complicated technical problems for businesses, and the highest quality engineers will consistently offer solutions to problems that show up. While it would seem that this particular characteristic is a given for any engineering job, in practice it’s very common to find people who never actually solve problems on their own. These people are often referred to as “code monkeys” since they are capable of writing some code, but are often incapable of actually coming up with their own solutions to the problems being addressed. Instead they rely on other engineers to devise the solutions.
Unsurprisingly, the engineers who can write code and solve problems are significantly more valuable than the ones who just write code. Additionally, the problem-solving engineers typically write higher quality code to begin with.
The key thing to recognize here is that you can be a valuable engineer solving problems at any level. You don’t necessarily have to devise the architecture for your team’s entire solution to be a valuable problem solver. For example, refactoring a section of your codebase to make it more testable demonstrates that you can solve a problem, even if it’s a relatively straightforward change.
Another element to this comes about when you are communicating to your team or management about any issue you come across. Less skillful engineers will often talk about an issue without offering any suggestions toward its resolution. While this is understandable in the cases where the problem is difficult or outside of the engineer’s skillset, it is often better to spend a few minutes thinking about a number of different resolutions to the problem and their tradeoffs. This way, when they discuss the issue they can offer up some solutions for management or other engineers to consider.
9. Always looking to innovate
Now we transition into the mindset category. The first mindset characteristic of many high quality engineers is that they have a strong interest in wanting to innovate. Whether the innovation is in process, technology, or some other area of work, high quality engineers typically don’t just accept the status quo but instead question it and try to find ways to make it better. This is important because it ensures that decisions are always being made not because “it’s the way we’ve always done it,” but instead because they provide the greatest benefits with the fewest downsides.
One example of this is the introduction of a new technology into your team’s development stack, or even just using a technology in a new way. For example, on my team one of the most innovative engineers introduced AngularJs components to our team. Even though we had already been using AngularJs for our client-side development, none of us had any experience using components, so we used the older paradigm of controllers and views being separated. Switching to using components significantly improved our development speed and made our code easier to test. If we had not had any innovative engineers on our team seeking to improve, we might never never have explored this part of the framework.
Having an innovative mindset allows you to always keep an eye on making yourself and your team better. And again, because this mindset usually results in the improvement of the team as a whole, the engineer who has this mindset is much more valuable than the one who just does things out of habit.
10. Willingness to share and document knowledge
Some engineers will guard their knowledge, fearing that if they start to share it then they will be less valuable. This is why it is common at many companies to find “information silos” where only one engineer knows how to work within a particular part of the code base because they never documented or shared their knowledge. While it is possible that doing this does in fact increase the value of that engineer, this is far from desirable when you consider the alternative. The engineer who guards his knowledge will usually arouse resentment within the other engineers who need to interact with him. This leads to people only interacting with this engineer out of necessity. When this engineer decides to seek out a new job opportunity, his unwillingness to share knowledge will cause significant harm in this endeavor. He will have very few coworkers who can recommend him.
Conversely, the engineer who generously gives away his knowledge (while expecting nothing in return) will be valuable, but in addition people will seek out this engineer because they know he has nothing to hide. When a new position within the company opens up, or when looking for a new job, which of these engineers will have more positive references backing him up? The answer is clear.
The engineer who shares knowledge is not the sole beneficiary, of course. Anyone who he works with will benefit from his willingness to share knowledge. Therefore, an engineer who openly shares his knowledge and experience is typically a high quality engineer and sets both himself and his team up for success.
Finally, the last mindset trait is being opinionated. This is slightly more difficult to quantify than some of the others. What is clear is that being opinionated is linked with having passion, which is typically a desirable trait to have. Engineers who are opinionated are valuable because they have ideas to offer and reasons for their actions, instead of just doing things for arbitrary reasons (or no reasons at all).
Additionally, being opinionated often means that these engineers can be trusted to make good decisions independently. This is because most engineers who are opinionated about their work have established their opinions through experience, discussion, and learning. In contrast, it is often very unclear whether an engineer who is not opinionated is capable of handling certain things on their own, since a lack of opinion can often be construed as being the result of a lack of experience or care.
This, then, is the final benefit of being opinionated: it demonstrates that the engineer actually cares about their work, not that they’re just there for a paycheck. It goes without saying that you’d probably rather have an engineer who cares about his work than one who doesn’t. While it’s wise to avoid being opinionated in an untactful way, expressing opinions on your team’s work will often put you in a more favorable light to your teammates and to management.