Getting It: What Makes a Great Software Engineer

Introduction

I’ve been writing code for a while now and for about the last 2 years there’s been a nagging question in the back of my head:

What makes a great software engineer?

Call them “rockstars”, “ninjas”, “submarine pilots” or any other catchy title you’d like. They exist, and they’re dangerously good at what they do. Let’s emphasize dangerous there, because right next to them is a second bucket. You’ve probably hired them, or worked with them - there might be one sitting right behind you. These guys know what they’re doing but seem to be lacking something; somehow, everything they work on seems incomplete.

For lack of better semantics, my friend Michael Dwan and I have always said that the ninjas just “get it.” In suit, I think it makes sense to refer to them, collectively, as the “get-its” and the latter as the “get-nots.”

Wait, Why Engineer?

engineer |ˌenjəˈni(ə)r|, noun: a person who designs, builds, or maintains engines, machines, or public works.

After reviewing the attributes I identified that make up a great software engineer, I realized that they are in many ways common to all engineers. And although software is my trade, I thought that abstraction warranted exploring.

Code for Codes Sake

Car analogies work really well to conversationally describe software applications, but I’m going to use the metaphor of a carpenter to describe our quintessential developer.

Initially, you have your newbie, who barely knows how to hold a hammer properly. If you told him to build a house, he’d have no choice but to defer. But an experienced carpenter, someone whose built a few houses in his day, would be comfortable taking up a spot behind the table saw and getting right to it.

But there’s a third category - let’s call him “qualified.” He’s just as comfortable as the expert behind the table saw. But he doesn’t quite get it. He lacks the mastery of the expert and as a result mis-measures, recuts, rebuilds, and so on until he’s got his shoddy house standing.

Software is exactly the same - only worse. It’s way easier to type rails superfluous-app than to fire up the saw and cut a piece of wood. And there’s a lot of get-not’s in the workshop, just keystrokes away from leaving 100’s of lines of scraps strewn about the floor.

The master knows that the best cut is no cut.

Drawing a Line Between Done and Done Right

Now you’ve got your house built. Maybe it looks a bit like Ned’s after the Simpson’s neighborhood chips in and rebuilds it, but hey, at least it’s standing.

As with the carpenter, a software engineer can fall anywhere on the skill ladder. Just go to your local Borders and spend a minute walking down the “Computers” aisle. There’s no shortage of well written, opinionated instructions on how to write code.

This is where many of the get-nots thrive. They’ve got a site up, but instead improving the experience, they migrate databases. They boast that their application has 100% test coverage, but it’s not live. Their server clusters are capable of handling gagillions of requests per second, yet actually respond a few times per day.

The get-its, in contrast, focus on the finished product. A get-it will systematically and holistically tackle each problem in the way of that goal, tactfully embracing the constraints and imperfections along the way.

Changing the Future

Think about the last time you saw a master at work. Someone that’s just qualified goes through often obvious and intuitive steps to get the end goal. But the masters ways are much more enigmatic, maybe skipping steps or starting with something that seems like it logically belongs at the end.

That’s how the get-its work. They’ll read a simple feature request and think through the ramifications it has on the whole project. A get-it will think through a problem and solve it quickly with an eye for what else is going on and what might be soon to come. I read somewhere that the most successful people don’t manage their time, but their priorities. A get-it can always answer the question: what is the next most important thing?

Get-its don’t just challenge the products their working on. They also challenge their tools. If it sucks, they build a new one. If they don’t like the way so-and-so library handles bla-bla-bla, they make it better and then share it with their peers. They’ve got their heads up, listening to other get-its, and are always a little uncomfortable because they understand that the only definite is that something’s about to change. The best of them are the catalyst for that change.