What Makes a Great Developer?
What makes a great software developer? Integrating programming, engineering, and leading. Find these three elements in the same person, and you have someone to hire immediately, someone to collaborate with indefinitely, someone to become.
The Programmer
The programmer writes code. The programmer gets excited about making things, things that work. The programmer is the barest outline of a developer: necessary but incomplete.
The Engineer
Development is no more limited to programming than programming is limited to typing. The engineer makes things that last. They’re written cleanly, with an eye to future maintenance. They have the necessary test coverage to survive refactoring. They’re capable of scaling, just in case the project succeeds beyond anyone’s expectations.
The Human
All developers are humans. No cliche jokes about robots here. But some of them are better at being humans than others. Any software project with any users is a team activity, or needs to be if it’s going to last beyond a single person’s interest / ability / attention span in maintaining it. Developers are categorically better developers when they can build trust, resolve conflicts, and take care of themselves and their teammates.
Programming + Engineering = The Robot
Here’s the robot cliche. The developer who can program and can engineer is quite useful, but not great. They need support dealing with ambiguities or gaps in requirements. They’re at best mediocre on multi-developer projects, unless they get a specific, well-defined role, again likely needing support to be effective in their lane.
Programming + Human = The Hero
The hero is deceptively amazing. The hero builds fabulous features. The hero is a pleasure to work with. The hero has great hair. The hero is there to take care of things when they fail…and fail they do, because the hero fights fires instead of preventing them in the first place.
Engineering + Human = The Pillar
In a non-startup, a good portion of the team can be pillars: developers who build code to last and are stellar team members. But in a non-hobby project with deadlines, there are times when the pillar can’t hold their nose long enough, or take enough shortcuts, to slap together a demo that just needs to make it through the afternoon.
Programming + Engineering + Human = The Unicorn?
How rare is it to find these three skill sets in one developer? I haven’t the foggiest idea, because it doesn’t matter. All of these are learnable skills. Programming is the easiest by far, but the others are achievable. Know what to value, and you can make yourself [into] a unicorn.
Epilogue
Two books heavily influence these thoughts: Software Engineering at Google1 and Effective DevOps.
The software engineering book had me from hello, when the first chapter drew a distinction between software engineering and programming. The authors frame the difference in terms of time, scale, and computing resources. Time is the framing that most resonates with me: programming is about the short term, while software engineering is about the long term:
Programming is certainly a significant part of software engineering: after all, programming is how you generate new software in the first place…It is just as reasonable to think of code that needs to last for a few minutes as it is to imagine code that will live for decades. Generally, code on the short end of that spectrum is unaffected by time….As we expand that time to allow for longer life spans, change becomes more important…This distinction is at the core of what we call sustainability for software.
Chapter 1
But software development isn’t just about code any more than it’s just about typing. This is where Effective Devops offers a lot to think about. I’d likely have never picked it up based on the title, given that I do little devops work, but the subtitle caught my eye: “Building a Culture of Collaboration, Affinity, and Tooling at Scale.” The foreword commands,
My strong advice to readers: do not make the mistake of thinking that technology is not about people and process, first and foremost.
John Allspaw
I was tempted to refer to this attention to people and process as “leadership” because regardless of their role, someone demonstrating these skills – especially in engineering, where they’re undervalued – is likely leading their team forward. But the word “leadership” is tied too closely to management roles, plus it isn’t expansive enough, so I went with the extremely expansive “human.”
- I am very loosely connected to two of the authors, so this is a slightly biased recommendation. ↩︎
North on Quincy 
You must be logged in to post a comment.