On Good Software Engineers
Abstract from 🤖
- Good engineers possess both technical and soft skills, including the ability to influence others, communicate effectively, understand organizational processes and culture, proactively embed quality into their work, adapt to changing stakeholder needs, and constantly work to reduce complexity in the codebase.
- Good engineers are reliable, have a growth mindset, and are team players, taking ownership of problems and offering solutions.
- Great engineers do all of the above proactively, taking action to fix broken processes and bringing solutions to the people who can change them.
- These expectations apply not just to software engineers, but to any good employee.
Setting expectations for software engineers is tricky for all managers. Every company has different needs and a different structure, tech stack, and culture. Whenever someone joins a team, one of the manager’s challenges is aligning the organization’s expectations with those of the new joiner. As there’s no universal guidance on this subject, I set out to find a simple definition that would help managers frame the fundamental things they expect from software engineers.
I first found definitions of 10x engineers, superstars, or rockstar developers, which aren’t definitions of good engineers in any way. Someone may produce a lot of work but it’s often at the cost of team spirit and results in low-quality code. Ultimately, the team is demoralized and the organization bears the cost of substandard code.
I also looked at different career progression frameworks or career matrices (which aim to give engineers perspective on how to map their professional development to roles) to see how tech- or product-driven organizations define good engineers. I found that all were incomplete (I wrote about the good, the bad and the ugly of these frameworks here. In general, career frameworks are helpful in defining roles, but they don’t define a good engineer. After sharing my thoughts and findings with peers, well-respected engineers and on LinkedIn, I arrived at one definition of a good software engineer.
A good engineer is one whom I, as a manager or peer, can trust to progress a project, knowing that they will deliver a solution by working with the team and producing good quality, again and again.
This definition applies to software engineers at all levels (from junior to staff+). We can’t expect a junior engineer to drive a big project; their scope will be limited. Yet, we can expect them to deliver small, unambiguous tasks with high quality again and again. We can expect good senior+ engineers to drive and deliver a feature or project. When it comes to staff+ engineers, this expectation will span over big and long-term projects with many unknowns.
It’s a super simple definition but has a lot of subtleties around how a good engineer, at any level, will approach and deliver a project by using many hard and soft skills. Let’s delve into them one by one.
Good engineers know how to influence others and the organization to deliver a solution as a team. At any seniority level, a good engineer must know how to communicate well both in written and spoken form. An engineer’s work always depends on collaboration (code reviews, pair programming, RFCs, ADRs, feedback, etc.). Good collaboration demands clear communication, giving and receiving feedback giving and receiving feedback, and listening with empathy. However, these soft skills are not enough.
Good engineers understand the processes they are operating in while taking a project from an idea to a solution. There are different approaches when it comes to doing code reviews or writing RFCs or ADRs. Each organization uses different methodologies like Kanban, Scrum, or Scrumban. Some organizations use Tech Radar to help teams make technology choices. Good engineers know the processes and guidelines so thoroughly that they know where they can bend the rules. They don’t stop there; they take their time to understand the organization as a whole.
Good engineers spend extra time learning the environment they’re in, going beyond the processes so they can independently drive the work. They learn how the organization works, about its culture, norms, and people. As they need to adapt to the organizational requirements to deliver a job of good quality, they have to develop not only hard skills but people and organizational skills. If the organization is hierarchical, they’ll have a difficult time driving a solution when they face rejection from a more senior person. If the organization works with short-lived task forces instead of long-living teams, their work style will be focused on speed and getting things done quickly. In any situation, they’ll need to find how to implement quality sustainably.
Good engineers take a proactive approach and embed quality elements into their deliverables to increase consistency and velocity. There is no need to ask for extra permission to write tests when you do test-driven development; no discussion will be needed if you consider refactoring as part of the new feature implementation. A good engineer chooses their approach wisely. If they inherit a legacy codebase, they look for ways to make it better, step by step. If they work with giving estimations, they include all these to keep a good level of quality. But above all, a good engineer needs to understand what quality means in their current circumstance.
Good engineers understand the stakeholders’ needs and fine-tune their approach so they don’t unnecessarily delay the delivery. They might need to do a proof of concept first or a full solution design upfront. Even when working in the same place, the organization evolves and changes; good engineers adapt to these changes and adjust the project’s codebase accordingly.
Good engineers constantly work on reducing complexity in the codebase to consistently provide high quality. They seek a modular design, separate concerns at every level while keeping the right amount of cohesion, and have a good testing setup and strategy. These are quality levers, and they know how to adjust them according to the organization, the situation, and the people around them. Keeping the same implementation and delivery strategies rarely works; good engineers constantly adapt and have a learning mindset.
Good engineers are reliable in constantly changing organizations. They seek to learn at every chance, even if it puts them in uncomfortable situations, such as publicly admitting mistakes, holding themselves accountable, and looking for ways to prevent the same mistakes from happening again. If a good engineer doesn’t know how to tackle a problem, they don’t avoid tackling it. They have a growth mindset and eagerness to learn. But they don’t stop there.
Good engineers are team players regardless of personality type. They recognize a problem and offer a solution. They don’t throw the problem over the fence and ask others to fix it.
I’ve covered good engineers in detail. But what makes a great engineer? Great engineers do all of the above but proactively. If they see a broken process, they don’t walk past the problem or wait for someone else’s permission. They take action to fix it. If they can’t change the process themselves, they don’t complain without bringing solutions to the people who can change it.
These expectations will not be easy for inexperienced engineers, but their scope will be limited at first. They will gain experience in time. If they keep learning, stay reliable, and improve quality day-to-day, it’s safe to call them good engineers.
I already hear some of you saying, “Well, Candost, you expect a lot of things from a good engineer.” No, I don’t. I strongly believe all that I’ve mentioned is a basic expectation from any engineer. More generally, these expectations apply to, in fact, any good employee.