Getting It: What Makes a Great Software Engineer

Written on February 08, 2010 by
Avand Amiri.
Reads in about 4 minutes.

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.

I’ve been building and designing products for a decade. Today, I’m the
Director of Product at Mystery Science working alongside
a small team of educators and creators to revolutionize how kids learn science. I was born in
Boston, grew up in Salt Lake City, spent several years in Chicago, and now call San Francisco
my home. When I’m not at my computer, I
like to ride bikes and make photographs
personally and professionally.