
The Number One Trait of a Great Developer - elainejgreen
http://www.engineyard.com/blog/2011/the-number-one-trait-of-a-great-developer/
======
mekoka
This post just listed traits very prominent in hackers - deep fascination for
technology, perfectionism, need for deep focus and few distractions, concern
for efficiency - and wrapped this package under the label of "lack of
judgment".

The problem I have with such generalization is that these scenarios are always
a bit caricatural and are usually presented in a way that nicely fit the
argument.

The experimental developer is required to build simple stuff, but goes to
extremes just because he wants to toy with new technology, while the great one
is praised for her conservative approach. It also helps that she asks exactly
the right questions and receives the right answers.

“How many devices do we expect to have?” “Well, we hope to sell 500 in 12
months.” “How often will they need to report in?” “Roughly once an hour.” “How
reliable is the network?” “It’ll use WiFi, so fairly reliable.”

In reality, sometimes you ask these questions, you get very accurate answers
and based on that, you pick some technology that you believe will spot on
address the problem. You might even make the judgment call that you have
enough wiggle room to include one or two new concepts you've been curious
about, that are yet still very relevant to the task at hand.

Then something happens mid-project and it turns out that what was originally
_requested_ wasn't actually what was _needed_. How many times has that
happened?

Two possible conclusions in these situations, for either developers:

\- the "rockstar" either looks like a god, for having foreseen some problems,
or he'll be the guy who brought a tank to a knife fight.

\- whereas the "great developer" will just look incompetent, or she'll just
be, well, great.

Judgment is a nice trait for a good developer, but it is subjective. There are
some hits and some misses.

What I believe makes a _great_ developer is the fact that they might work to
push their own boundaries, which is the reason you're interested in them in
the first place, but most importantly, when they do, they stand by their work.

I can't embrace a definition of a great developer, where the primary quality
is to avoid causing trouble for the company, the project, the team or their
boss. That has almost nothing to do with the discipline. You're describing a
"great employee" or a "great team player".

The exact description of a great developer given in this article might
absolutely not work in other environments, where developers are required to
push the envelope and think outside the box. In such context, your great
developer might be thought of as mediocre at best.

~~~
buff-a
_the "rockstar" either looks like a god, for having foreseen some problems, or
he'll be the guy who brought a tank to a knife fight._

Fights over. The guy with the knife killed you while you were putting the
treads on. Meanwhile, the guy with the knife discovered that his customers
actually wanted something else _because they could run the first iteration of
the actual product_ while you were worrying about scaling to a million
customers. Maybe the customer is in the steak-house business, but you just
stopped reading at "customer wants knives", got a hard-on and started building
tanks.

 _Then something happens mid-project and it turns out that what was originally
requested wasn't actually what was needed._

So you advocate over-engineering a just-in-case tour-de-force, instead of
agile, iterative, responsive development. How are you getting up votes????

 _This post just listed traits very prominent in hackers - deep fascination
for technology, perfectionism, need for deep focus and few distractions,
concern for efficiency - and wrapped this package under the label of "lack of
judgment"_

Not so. The post listed traits found in very prominent in hackers but also
found in ineffective, inexperienced hackers. And advised that to focus on just
those traits is wrong. The key trait that separates these two groups is
judgement. A "prominent hacker" will use the right tool for the job, right
now.

~~~
einhverfr
"So you advocate over-engineering a just-in-case tour-de-force, instead of
agile, iterative, responsive development. How are you getting up votes????"

There's a time and a place for heavy engineering, and a time and place for
agile, iterative development, and sometimes both have times and places in the
same project.

One element of good judgement is realizing what the tradeoffs between older
and trendier development methodologies are, and then navigating them
intelligently.

For example, the direction LedgerSMB is moving is towards a heavily
engineered, intelligent database with a well-engineered API, and a more agile
application built on this framework. The database engineering (esp. in an
accounting app) needs to be done _right_ and account for a lot of "just in
case" while the actual application running on the database should be able to
be customized relatively easily.

~~~
buff-a
Its funny, because the only code I write that is 100% TDD is the stuff that
_has to be done right_. "Heavy Engineering" without agile, iterative
development is actually just "Heavy Wishful Thinking", or "Heavy Waterfall".

------
axiom
This article is totally true, but almost impossible to act on.

It's very very hard to differentiate people who have a passion for doing good
work and people who just like to play with the latest trendy technology.
Especially since the latter is often just an immature stage of the former.

~~~
mechanical_fish
You can look for someone who works with non-trendy technologies.

This is actually a big reason why non-trendy technologies persist - indeed,
why they often thrive in the larger marketplace precisely at the moment that
they become least sexy and fall off the geek radar. Non-trendiness is a market
signal of its own. There's a lot less noise in the backwaters, and those
products which survive to become boring have demonstrated staying power.
People obviously aren't using them for fun, or because they're easy to promote
on popular blogs, or because VCs can impress each other by dropping their
names. They must have survived for another reason. Perhaps they are...
pragmatic, useful, or cost-effective?

This strategy must be used in moderation, of course. The final stage of
nontrendiness is obsolescence and death; You don't want to hire those who are
expert only in obsolete things. (Oh, my IE6-CSS-hacking skills will soon have
no market value. _Thank goodness!_ )

~~~
pyre
There is a fine line. Sometimes people work with non trendy tech because they
have no interest in developing their skillset.

------
danso
This essay seems to beg the question. A "good" developer, by its definition,
is the who picks the most reasonable, easy to maintain technology, because she
knows anything "much more complex would be beyond her current skill." Yet, if
she is lacking in skill, how can we be sure her judgment is sound on what a
"reasonable" and "easy" technology is? Doesn't the basis for that judgment
require superstar-like experience and curiosity?

~~~
grannyg00se
I would say that once you reach a certain level you are able to determine
which technology is reasonable based on things like language familiarity,
community support, and documentation.

~~~
danso
Sure, but I wonder if two years in Ruby, or any language, is enough?

A superstar dev might go out and try a lot of the new, cool stuff, even when
it is needed. But it seems that that developer would also have a grasp of the
common characteristics of bad technology.

So I think there are at a minimum _two_ good traits of a great developer. The
rockstar-like quality of having the skill, curiosity, and breadth of knowledge
to handle being on the edge. And the maturity and thoughtfulness to know whey
he/she has failed in the past.

~~~
tjsnyder
Two years? I think you can learn everything you ever needed to know about a
language in a much shorter time period than that.

~~~
ysilver
Totally agree. For example, if a web dev wants to try a new
language/framework, he or she can be competent in a few weeks and well-versed
in 3-6 months. No?

------
6ren
HN has a lot of link bait titles these days, making you click just to find out
what they are talking about. How about

    
    
      Judgment is the number one trait of a great developer

------
drawkbox
What this article is saying is you need someone with experience to make the
right judgement. This means you need to find someone that has already gone on
the 5-8 year roller coaster that a developer goes through. This from the 'just
get something working', to astronaut over-architecture, to practicality that
might come with running many projects and being through many successes and
failures.

A good developer might be at any stage in that process and it is really a
timing thing. Typically after 10 years most developers have this as long as
they have not become too pessimistic and have experienced many platforms, not
religious to any of them.

Experience with a beginners mind that is willing to innovate still, is the
perfect balance of a 'great' developer.

~~~
wallflower
A very smart developer who I respect once said something like: when you are
young, you have lots of energy and want to learn/use the latest technology. As
you get older and gain more experience, you start to see the patterns. It's
not about the technology, there are repeated themes and solutions. But when
you start realizing this and have accumulated 7 years of experience, you may
be transitioning out and wanting to begin starting a family. So the people who
might be most qualified might be wanting to leave the intensity of coding for
the relative stability of management.

So perhaps n years of experience is a cludgy filter for the relative
graybeards who understand that technology is just a tool, not an end in
itself.

------
jjguy
I find the volume of defensive comments a little amusing, since three times a
day we all vote up and universally agree ideas are cheap and execution is
king. The author is drawing the same parallel to characteristics of
individuals.

Unlike most of you, I read that and found myself saying "yes!" It's the
tortoise and hare argument: good dev teams are disciplined, focused and
stable. I suspect the backlash is because it stung a bit, since many here saw
themselves in flighty Jack, versus measured Diane. I was there too, but have
learned from a few failed projects and disappointed clients. I encourage you
to reflect upon yourself a little more carefully; good execution is decidedly
unsexy and needs more Diane than Jack.

------
elliottkember
Seems a bit pigeon-holey to me. I'd think twice before applying such broad
stereotypes.

------
arctangent
The article is a good example of a false dichotomy.

<http://en.wikipedia.org/wiki/False_dilemma>

~~~
mechanical_fish
What dichotomy?

Are you being misled by the fact that the article uses only two examples?
That's a rhetorical shortcut, not a proposed dichotomy. The article does not
actually claim that "those who use Sexy Tech X tend to have bad judgement" or
anything like that. What it says is that folks with good judgement use
appropriate tools for appropriate reasons, which may be situational.

~~~
arctangent
I'm not making a rhetorical argument. You should take me seriously.

The article stereotypes "rock star" developers as being obsessed with using
the latest tools and compares them to more "average developers" who (it is
claimed) better know their limits and ship more maintainable products.

I believe that this is a false dichotomy.

There are plenty of "rock star" developers who ship maintainable products
which use appropriate technology. There are far more "average developers" who
ship awful, barely-functional code because they're only able to use a limited
set of technologies.

~~~
mechanical_fish
So, though it isn't entirely unambiguous, when I read the article closely I
see that it agrees with you.

Let me see if I can make this boring enough to understand. Let's draw a
classic management-consulting two-by-two matrix:

    
    
      GENIUS-JUDGEMENT       GENIUS+JUDGEMENT
    
      AVG-JUDGEMENT          AVG + JUDGEMENT
    

The author's argument is that the column on the right trumps the column on the
left: Judgement is important, even if the genius-with-poor-judgement is some
kind of CS demigod. However, he doesn't actually say that lack-of-genius and
lack-of-judgement are correlated, or that he'd turn down a wise genius if such
a rare and precious being fell on him from the sky. You've gotten the
unfortunate impression that he's saying that, but that's an artifact of trying
to use two examples to describe a fuzzy multidimensional space. (I mean,
really, even two dimensions is a painfully naive approximation, except of
course to a management consultant. ;)

Of course, if the original blog post used my four examples it would be as dull
as... management consulting. The moral of this story is that writing is hard.
You have to leave some ambiguity, and trust the reader to fill in the gaps,
and hope the gaps are not too large, and that your sly invocation of the
trendy-yet-pragmatic NoSQL user in the penultimate paragraph helps people take
the hint. But sometimes the whole thing just doesn't work. C'est la vie.

~~~
dingfeng_quek
If clarity was one of the design goals, the author should have included the
2x2 matrix. Sometimes, the best opinions aren't those that corrects our
wrongly-held beliefs, but those that don't create them, which is much more
silent.

------
ryanto
I agree with the gist of this article, but there is an opposite side to this
piece as well.

We do need those developers that pick the most wild, crazy, and bleeding edge
technologies. New technologies shouldn't and certainly don't solve every
problem out there, but they often tackle a couple of really interesting areas
quite well. At the very least they allow us to question and rethink our
current development stacks. Also, being one of the first to adapt to a
technology has it's benefits, not saying that it justifies the risk, but it
should be considered.

Also I think node js and cassandra are pretty easily maintainable, but thats
not really what this is about :)

------
azov
Judgement is indeed an important part of being a great developer, but I don't
think the article is doing a good job of explaining why, or what kind of
judgement.

First of all, the story about Jack & Dianne doesn't illustrate much. Why Jack
ended up with unmaintainable code and Dianne didn't? And what does it have to
do with the tools they've chosen? You can write unmaintainable code in any
language.

It sounds like Dianne did a better job of understanding requirements. Okay,
fair enough, understanding requirements is important (though I wouldn't call
it "judgement"). But requirements change. They always do, that's why software
has to be maintained - to reflect changing requirements. Which means that
whether the code is maintainable does not depend on the code per se - it
depends on _how_ requirements change (unless the code is so bad that it can't
be changed at all).

Say, if tomorrow the new requirement is to add a new API to the backend,
Dianne's solution is probably more maintainable because it's simpler. But if
the new requirement is to scale to 10K users, Dianne's solution might have to
be rewritten from scratch, and thus completely unmaintainable.

So, to write maintainable code developer has to anticipate future changes in
requirements and make tradeoffs based on those predictions. Now, that's a hard
problem, that's where we need judgement and experience. This kind of judgement
makes a great developer - mere conservatism in selecting tools and
technologies does not.

------
SeanNieuwoudt
I would say a great developer should have the followed waxed:

1\. Accurate time estimation & communication skills

2\. Not suffer perfectionism

3\. Know where to find the right answers

4\. A good understanding of general programming concepts and when to apply

5\. Ability to write code in a way that it's easy for future dev to understand

6\. A good understanding of tasks other than programming and how they all fit
together in a business environment

7\. A good dose of enthusiasm - things can get tough, how are they going to
deal with it?

I'll end my comment by saying that you won't know the extend of the damage
caused by a bad developer until it's too late.

------
johnrob
I agree wholeheartedly with this concept. I previously used the term
"instincts", but I think "judgement" is better. A solution is more than a
technical implementation: it should address the actual requirements of the
product as well as the characteristics of the maintainers. A combination of
familiarity + ease of development + enough scalability.

------
pg_bot
I think that for any type of problem solving there is a clear workflow you
must go through in order to efficiently come to a solution. 1.) Break down the
problem to see what you are actually required to do. 2.) Think of ways in
which you have solved previous problems and check whether you can do something
similar to what you have done in the past. 3.) If you need to do something
that you haven't done before do some research and find the tools that you need
to solve the problem; if there are multiple paths to solution apply Occam's
Razor. 4.) If step three didn't work, you haven't looked hard enough or you
have found a problem that no one has solved before, it is most likely the
former. 5.) Implement your solution; if it works great the problem has been
solved. If it doesn't work retrace your steps and then take a break and come
back to the problem when you have a clearer head. 99% of your problems can be
solved in this manner

------
lian
I think the truth of this article depends on the size of your team.

If you're hiring only one to a few developers, it's likely that you need your
employees to self manage. They need to strategize, have realistic
expectations, and fulfill them to the best of their abilities. "Dianne," the
good developer, demonstrates these skills. So, judgment is important from this
kind of developer.

However, I think that "Dianne" would be best suited to a more managerial
position, focusing on her strategy skills and ability to relay needs to other
developers. Handing off the implementation details to a team of rockstars,
with deep and varied proficiencies, would make for a spectacularly
complementary team.

And in the latter case, your best developers are - and should be - rock stars.
You need to consider not only how you want your code to scale, but how your
company will.

------
einhverfr
I think the fundamental problem exposed in the article is actually not the
hiring criteria, but rather that resumes are usually screened by HR
departments who have no clue about what a job entails. So the hiring managers
have to provide hiring criteria that the HR resume screener can understand.
The HR resume screener is not a programmer and has no way to judge the
capabilities of programmers. The hiring manager may not be either.

As seen in a Slashdot sig some time ago, "Light travels faster than sound,
which is why some people appear bright until you hear them speak."
Unfortunately appearances win to those who cannot understand what is being
said.

------
petercooper
_When I look around at other companies hiring Ruby on Rails developers, I see
them focusing on three major traits: Super-smart; Large community following;
Deep Ruby knowledge._

I definitely agree with the thrust of the article, but I run community sites
and have run Ruby job ads for a few years and I can't recall seeing anyone
looking for a hire with a "large community following."

In aggregate, across all the listings I've run, companies are most usually
looking for experience, team working skills, familiarity with Agile practices,
TDD experience and, sadly, the ability to commute to a certain location.

~~~
davidhansen
_I can't recall seeing anyone looking for a hire with a "large community
following."_

 _companies are most usually looking for ... team working skills_

I believe there is an operating assumption here that active membership and
following in a given community is a solid indicator that the individual in
question has very good team interaction skills, as well as working knowledge
of the community's domain focus.

~~~
petercooper
Maybe, although I think that assumption would be erroneous (not that you
suggested it wasn't :-)).

I can only speak for the Ruby and Rails community but I think there are many
developers who have a strong "following" on blogs, Twitter, at events, and
even on GitHub but who aren't necessarily good "team players" (To be fair, I
include myself in this bracket ;-)).

------
jgh
When I do my first interview (as the interviewer) one day, I'm going to ask
"Do you read blogs by software developers?" and if they answer "Yes", I will
not hire them because these blogs are a bunch of horse shit.

~~~
Milagre
You'd be smart to ask "Which ones?" before you dismiss all dev blogs as 'horse
shit'.

Blogs like Coding Horror and Object Mentor should gain your respect, not your
disdain.

------
rbranson
Remember when Sinatra and Ruby on Rails were the new, hot, trendy
technologies? I'm sure EY was humming a different tune back then.

------
jorangreef
Judgement:

For it to be judgment, it must be living and active in a programmer's mind. It
can't be switched on some of the time, it must be switched on all of the time,
for the mundane and the monumental. It must be sharper than a double-edged
sword; it must discern the thoughts and attitudes of the heart.

------
va_coder
One fallacy in this article is the portrayal of the typical "regular
programmer". The reality is that many regular programmers would pick something
horrible but established in the enterprise like Java Struts or Oracle Web
forms, not Rails, because that's "what they know".

------
ysilver
I agree with this article and have a proposal for another trait of a great
dev:

A great developer is not necessarily one who writes the most elegant code, but
one who knows how to walk the line between elegant code and speedy dev time.

Thoughts?

------
tlammens
How do you know/decide what a "good" solution is?

It all depends on what you already know and what your team is best at.

And although a "simple" solution may look like the best choice, it too can
have the same problem of maintainability.

~~~
ysilver
I agree with the first point. Development is usually a team effort. Effective
teams generally play of their strengths. This is probably more important than
having a rockstar on board.

Isn't simple code inherently more maintainable. I can see it having the
problem of lacking scalability, but prematurely building in scalability is the
root of all evil...

~~~
wladimir
I agree that premature _anything_ is bad, especially in extreme form, however,
your other point needs some elaboration.

 _Isn't simple code inherently more maintainable_

Verbose, over-simplified code can also be unmaintainable because you lose
track of the bigger picture.

The only really simple code is small projects, and code that was just written.
In the longer run, as features are added, there is always complexity being
added.

In that phase it becomes important to separate concerns, prevent accidental
complexity, factor out repeated code, and so on. This can mean that some parts
of the code have to make use of more powerful constructs of the programming
language, and thus are less trivially "simple".

Also, opinions differ greatly on what is "simple code" and what is not. After
all, all code is simple once you understand it.

~~~
einhverfr
That's why I have come to define "elegance" as "simplicity perfected."

The best solution is the one which makes use of a number of clear, easily
understood, simple solutions in combination to solve a problem. But the wrong
approach to simplicity can be as bad as complexity.

------
sliverstorm
This hearkens back to what one of my professors used to tell us- "Always draw
a conclusion (from your data)".

Don't just routinely foist gobs of data off onto others; you were hired for
your brain. Use it.

------
ww520
Great developer is relatively easy to identified. Three things: 1. get shit
done, 2. good decisions on trade-offs (cost, performance, etc), 3.
maintainable work.

------
harichinnan
The awesome ruby developer following all tenants of Martin Fowler vs the
curious Joe who hacks with nosql and clojure.

The story ends with OMG!!! Ruby is still awesome.

------
andrewingram
I like to think that I don't try to solve hard problems, instead I like to
rephrase them as easy ones.

------
_grrr
I always go by the maxim: "(build) the right thing at the right time". I think
John Bentley said that.

------
CPlatypus
The real fallacy in the article is an unstated assumption - that developers
should be homogeneous. Why not have a "rockstar" Jack _and_ a "sensible"
Dianne, in dynamic tension? Teams of one are the exception. In multi-person
teams, focusing on the same attribute not only misses an opportunity to hire
developers who complement one another but often leads to outright conflict as
multiple developers lay claim to the same decisions or assignments. The
author's point is _slightly_ more applicable to choosing a lead developer,
where judgment is at even more of a premium and many people would make the
mistake of promoting Jack over Dianne because of his higher profile, but even
then I think the article does more harm than good.

------
freemarketteddy
Straw Man is the name of the fallacy!

~~~
einhverfr
One might think that it ceases to be a straw man when someone rushes to defend
it.

