Good Engineers
When people think about a good engineer, the thought that comes to mind is probably of a quiet genius in a dark basement typing frantically into the terminal. This vision of software engineers as lone hackers, never interacting with other people if they can avoid it is reinforced over and over in popular media. Yet in reality, nothing could be further from the truth. The sort of programmer that you see in movies would be a disaster to work with, no matter how smart they think they are. Technical skills are important for an engineer as we’ll discuss later in this article, but they’re only one aspect of being a good engineer. Just as important are communication skills, and working productively with others. An engineer that cannot do these things is not worth hiring, no matter how technically skilled they may seem. In this article, we’ll look at several key aspects of good engineers, and we’ll discuss as well how non-engineers can help cultivate these skills on their team.
It’s also worth noting that in addition to these attributes, the domain of the role matters immensely as well. It’s possible for a good engineer in one domain to struggle in another domain. Every role has unique requirements from every other role, so it’s possible that an engineer that would thrive in one environment, like a huge corporation, might struggle in another, like a small startup.
Brilliant disaster artists
Technically gifted engineers who don’t communicate are not good engineers. Engineers whose work is not communicated to the rest of the team tend to leave small landmines throughout the codebase for other engineers to step on, since the rest of the team isn’t aware of how their code works or why.
For example, I once worked on a project where an engineer had set up a trigger in a project database such that whenever any data in that database was updated, the trigger would run a bunch of code in other places across related products. Nobody except the author knew this trigger was there, so when a coworker went to do some minor database changes that involved updating some data in the database, the trigger ran and clobbered a huge amount of user data unrelated to the change.
Good engineers communicate what they’re doing and why, so knowledge is shared with other members of the team. Code that only 1 person on the team understands is a liability, no matter how elegant that code may be.
Working well with others
Beyond just communicating what they’re building and why, good engineers work well with others. They empower their coworkers, and ask for help when they need it. There’s no place for egos on an engineering team. Good engineers don’t always know the right answer to every technical problem, but they can work with their team to bring out a better solution from the group than any single engineer could on their own. Bringing other members of the team together to work out solutions also has the benefit of sharing knowledge across the team, so that everyone has an understanding of how the code is built and why.
One of the teams I’ve worked on had a great practice where before building a feature, engineers would first explain how they’re thinking about the feature and how to build it on a shared document. Then, they would ask for input from some other engineers on the team in a quick meeting before they started. The results of this collaboration were almost always better than what each engineer would come up with on their own, since the full experience of the team could be leveraged to arrive at better solutions.
Constant learning
Software engineering is always changing, and good software engineers need to be willing to change with it. This means that engineers are constantly needing to familiarize themselves with new technologies, and that the knowledge an engineer has will quickly get out of date. A good engineer should be willing to do this learning with humility, understanding that they will not have all the answers, and what they’re an expert at now will likely become irrelevant in a few years.
Learning new tech doesn’t mean always jumping on the newest, hottest thing. Learning about new tech is necessary to know when that tech is not a good choice for the team. There are times when new tech will save a ton of effort (ex using Auth0 or AWS Cognito rather than building your own auth system from scratch), and when it should be avoided (ex setting up a Hadoop cluster to process your product’s 1 GB of data). Knowing which is which requires staying up to date with new tech as it comes out.
Going outside their technical comfort zone
Software engineering is an eternal struggle against code and systems that just don’t work the way they should. Debugging is perhaps the largest portion of most software engineers’ time. Code never works right the first time, and sometimes getting things to work requires really digging deep into the dark underside of systems and code that the engineer themselves, or even their team, didn’t write. A good engineer should be willing to take this plunge when needed, rather than throwing up their arms and prematurely saying it’s impossible.
Knowing when to say “no”
Like Karate, sometimes the best solution to a coding problem is to not write code at all. Engineers often are drawn to complex solutions and flashy systems, but sometimes the right answer is to cut out a feature entirely, or simplify the solution dramatically so there doesn’t need to be much code written. Saving months of coding time by de-scoping a feature or architecture to be simpler is worth more than any amount of coding. The easiest code to maintain is the code that isn’t written.
Creating good engineers
Nobody starts out being a good engineer. These skills are learned over time, and can be brought out by other members of the team. Often an engineer will learn humility after an overly complicated feature they build causes problems, or after lack of communication causes downtime. It takes time to become a good engineer, and engineers tend to get better with experience. An engineer who is smart, humble, and has a willingness to learn will almost certainly become a good engineer with time.
If you’re working on a team with engineers, it’s worth it to help them grow and improve.
As someone in a leadership position, you can help build an environment where this learning and growth can happen. For instance, you can set up brown bag knowledge sharing sessions where engineers can share new tech with each other. Or you can run internal hackathons where engineers can collaborate on any idea they want to explore. You can work on creating a non-threatening team culture where it’s encouraged to ask for help, and engineers aren’t punished for not having all the answers immediately. You can encourage pair programming to help more senior engineers work with more junior engineers. You can encourage the engineers on the team to go to conferences and present their work to their peers. You can create processes where communication between engineers becomes the norm, like having engineers propose how to build a feature with other engineers first before they start coding. The list goes on and on, and I’m sure you can think of even more creative ways to help your engineers get better. The payoff of helping to create good engineers is worth it!