

What Makes Great Programmers Different? - hutteman
http://www.drdobbs.com/architecture-and-design/240001472

======
dmbaggett
I've hired and worked with hundreds of programmers, most good. The
observations in the post are all true, but another correlate I've seen is
patience: willingness to slog through difficult, boring work to achieve a
great outcome.

All of the very best programmers I know work incredibly hard and never allow a
massive boring task to derail them. It's an interesting combination of
confidence ("I can solve this insanely hard problem") and humility ("I am not
above doing this crappy work").

Sometimes the solution is to automate the boring stuff; other times it's
literally just getting through days of grunt work. The very best programmers I
know are willing to do both, and know when to do which.

------
Xurinos
Am I the only one who feels like commentary that categorizes "good" and "bad"
programmers is unhelpful? One can make a good case for somebody having more
appreciable traits than another, but I would be loathe to call either "good"
or "bad", even in comparison to each other. This kind of labeling is just
namecalling, more harmful than helpful, a stroking of egos.

The reality is that different people have varying strengths and weaknesses for
specific tasks; people have different rates of personal development in
different areas. It is not a matter of "good programmer" vs "bad programmer";
it is a matter of "That person can do that task in a better way than I can" or
"That person can do that task more efficiently than I can" by some perceived
measure of "better" and "efficient". The comparisons between people are
relative, not absolute, and divided across many kinds of traits.

However, this article does bring up a number of traits that many of us can
probably agree with as "goals to achieve in personal development". For that,
it has great conversation value. Personally, I like the notion that memory
might be correlated to some quality of design and output.

If I were to pick a trait of importance for a programmer, it would be
"Consistently improves bottom line growth." Things that factor into that might
be "Writes maintainable code" and "Knows his tools well", but it is debatable
that these subtraits have a clear correlation with "bottom line growth". Has
anyone actually measured these things?

~~~
gfosco
The most important trait for me would be Passion.

------
ericb
I know one programmer who I would call great. Here's what I've observed from
him so far:

1-A serious amount of fucks are given both via attention to detail, polish,
and no corners are cut. I have been lazy comparatively and often accepted
"good enough." I'm working on changing this so that my priority is what is
awesome for the user, not easiest for me to implement.

2-At the micro level, before setting out with any new technology, he tests its
properties thoroughly. For example, benchmarking each part of the setup on its
most intensive tasks before building with it. No "assuming it will work" based
on breathless blog posts. Using his intuitive sense of what is expensive, he
also optimizes expensive operations in loops by hand (like mysql complex
queries).

3-A well thought out, and well practiced tool-chain for development. Ex: Using
vim and knows it well, pays for tools to make life easier, has easy backups
with time machine to easily go back, etc.

4-Diverse range of skill, and eagerness to dive into something new at any
point.

5-An ability to rapidly debug problems. I haven't pieced together how this
skill is built, except it involves the usual logic combined with a better
memory than mine (so remembering what to rule out) and a pattern recognition
that comes from remembering similar problems.

~~~
nostrademons
Point 2 is something I've heard Jeff Dean strongly suggest. Write
microbenchmarks for all the basic operations of the "black boxes" you'll be
using to build the system. That way, you can do quick back-of-the-envelope
calculations to estimate the performance of the system before actually
building it. You can explore the problem space much more quickly when you can
simulate the important characteristics in your head instead of having to
actually type them out into an editor.

Point 5 is something my former manager once told me. He'd done RoboGames or
something like that as a grad student, and he found that invariably, the teams
that won were the ones who had built the best debugging infrastructure into
their robot, so that when it didn't behave as expected, they knew exactly what
was wrong.

This is as much a property of the program as of the programmer. The best
programs usually have debug information built into the structure of the
program itself, along with an easy UI for viewing that debug info so you don't
have to stare at log lines all day. Once a couple programmers start doing this
and everyone else realizes how much time it saves, it becomes part of the
culture of the organization, and everybody starts designing programs with an
eye toward "Will I be able to figure out what's wrong if this doesn't work?"

~~~
delian66
Please, would you give an example of an open source program with such
infrastructure built in ? I'm eager to study such programs to pick up
insights.

~~~
nostrademons
The closest open-source example I can think of is --verbose mode on many UNIX
utilities, though that wasn't really what I had in mind. Developer Tools in
Chrome is another example of the principle - think of how much easier it is to
debug Chrome than IE6 - but again, not quite all the way. Imagine using
Developer Tools to debug all of _Chrome_ , eg. Webkit rendering (overlaid on
the rendered page itself), resource parsing & scheduling, JS JIT compilation,
etc, and not just the pages that execute within it. (Maybe this is possible,
I'm not familiar enough with the Chrome project to know all the debug flags
available.)

------
jakejake
I've found that just about everybody, myself included, thinks they're at least
a good, if not great programmer. Obviously a lot of us are wrong!

I tend to think that being great can be a relative term as well. There's
different needs. A great programmer who is a genius at coming up with
innovations can't always focus to actually get any real work done. A
programmer who isn't very creative may plow through tasks like a steamroller.
One may be great at intuitive designs, another is great at hard-core
algorithms. Which one is the greatest? Depends on what job they're supposed to
be doing. Of course a terrible programmer can wreck any of these scenarios.

~~~
mightybyte
You're spot on about different needs. I used to work for a guy who was a
genius at managing programmers and providing an environment for them to thrive
(at least he did that for me). He once told me that for an innovative multi-
year software project, he needed a small team of really good programmers to
spend several years building and refining the core system (on R&D dollars).
Then, several years down the road when the contract dollars started coming in,
he'd need a much bigger group of average programmers to handle all the humdrum
tasks of moving the right bits to the right places, supporting the right
formats and protocols, etc. He understood that the average programmers
wouldn't be capable of the former, and the great programmers wouldn't enjoy
the latter. It was a significant realization for me.

------
stiff
The only way you can be a great programmer in a meaningful sense is by putting
in your best effort every single time you do some programming work, always
looking out for ways to improve your work and always looking for feedback from
other people, basically cultivating a "beginners mind". Once you start
thinking of yourself as a great programmer, you start paying less attention to
what you are actually doing and start being over-confident in your decisions
on the ground of your "greatness" and it is very easy to delude yourself - I
know from my own experience. Being great is not a permanent trait you have to
gain and will from that moment keep on having forever.

In other words, there really are no great programmers, there is only great
programming.

~~~
beersigns
The man who knows he's not wise is in fact wise?

I actually agree to some degree. Though it could definitely said that it's
easier(less time & struggle) for some to create great programs than it is for
others.

My entire life as a programmer has been about consistent and constant
improvement. A little bit of improvement every day, every project. Committing
to the craft(reading, exploring new langs/tools) will definitely allow you to
create better and better code as the years go by.

------
nadam
"being capable of quickly shifting registers from the large picture to small
details and back again — relies on the strong memory" Something like that,
yes. Just huge memory and fast processor. And unfortunatelly it is just
talent, after 10-15 years in the profession you will see your limits: your
programing skills can be developed further and further to be very good, but it
cannot be developed to be really great. I am a good programmer, but not a
great one. When I was young, I thought I am great (winning some small math
competitions when I was a child helped to develop this false belief), but now
I know I am just good: I don't have that incredible brain power (memory +
speed). But I am not depressed: being good is also fun, and anyway programming
is not my identity: my identity is more a combination of software product
design + programming.

~~~
pcopley
I would hope your identity was more closely linked to friends, family and
hobbies than your career, regardless of how much you enjoy what you do.

~~~
waterlesscloud
I can by the friends and family portion, but why would it be better to have
your identity linked to your hobbies than to your career?

~~~
AlexandrB
Because you have more control over your hobbies. At the end of the day, the
success of your career is (at least in part) dependant on luck and the
decisions of others.

~~~
nostrademons
Not in programming, which is one of the few lucrative careers where you can do
it just as well as a hobby.

------
roguecoder
I would phrase it slightly differently. I would phrase it as "able to consider
multiple levels of abstraction simultaneously".

When I see code execute I almost unconsciously understand what the code is
doing at a procedural and sometimes assembly level, as well as what it is
doing at an architectural level. It's the skill you need if you are going to
work on intentionally undocumented code. It means when I encounter a bug, I
know what construct I'm looking for: "ah, yes, there it is." When I architect
something it is as simple as it needs to be to do the right thing and I don't
have to put any extra effort in to have it communicate meaning through
structure. My challenge is to provide guide posts to other programmers coming
later to help them swap between those levels, because I don't need them
myself, or do what I do now and work with other people who's minds also work
this way. If I come back to code I wrote five years ago I still grasp exactly
what is going on, and the chances are pretty good I remember the exact code.

I'm still not one of the greatest programmers I know, though. Those can both
simultaneously consider multiple levels of abstraction and leave that aside to
consider tiny pieces. I can sit down and carve away marble to leave a program;
they can sit down and merge tiny chips of marble into something that looks
exactly like I would have created out of whole cloth.

For them, unit testing is easy. For me it is challenging and a necessary
chore.

On the other hand, at least 40% of my job doesn't benefit from this, mostly
because of missing tools. Moving into CMake was fantastic, because finally I
could apply the same approach to release engineering I applied to writing
code. There are definitely roles for which this is massive overkill, and lots
of people who work this way spend all their time building tools to support it
rather than producing software used by consumers.

------
mberning
They spend time building useful things rather than getting caught up in online
discussion forums.

~~~
TazeTSchnitzel
I'm not a good programmer, because when I tell myself I will be programming,
2/3 of that time is spent reading Hacker News instead.

------
altrego99
> The other group, the reckless, consists of those who have the skills but
> don't have the discipline. They are the cowboy programmers of yore. They
> code according to their own desires, do nothing to integrate their work with
> that of others, scrimp on basic discipline, and cause work for other team
> members.

It is worthwhile to note that Steve, Linus, Feynmann (last one in physics, not
coding) all belong to this category. These are the people who do programming
(or whatever else they like) for their own pleasure - to derive fun out of.
They are unafraid to challenge the status quo - and they are exactly the ones
who cause disruptive changes in the world.

If at all, the slowness with which their reputation is dying makes me happy -
because though they are capable of having highest success rate in creating
start ups, unfortunately not all of them will succeed in building their own
company. And it will be a sad world if these people are not allowed in
established companies to make the changes that can swing the world in the
organization's favor.

~~~
gfosco
I've never understood the hate for cowboy coders. A great cowboy coder can do
the work of an entire team. It's so typical for people to cry that the cowboy
causes work for others, but I've never seen it myself, and I expect the great
many who claim it are just following the group-think they've had drilled into
their heads.

If you inherit a program from some other maintainer, there is a learning curve
no matter what. A good programmer quickly learns how it's put together and
plays the field they're on.

~~~
grlthgn
The problem is when your cowboy coder leaves your company, you are fucked. The
code is undocumented, and incomprehensible. It works but you have no idea how
it works and neither does anybody else.

~~~
gfosco
I think that may just be a straw-man argument. It should not be difficult to
figure out how it works, the logic is laid out right in front of you.

There is _always_ a learning curve when taking over a project.

------
smoyer
I think a good memory is important as is a broad knowledge of their tool-set,
but how did they get that way? I think curiousity is probably a programmer's
biggest asset ... the desire "to know".

------
asto
Is memory really that important? I'm just starting out with programming right
now and I have rather poor memory.

~~~
re_todd
It's important, but I don't think it's crucial. I've seen a couple programmers
that are really good that do not have good memories. They always have apis and
cheat sheets open in their browsers they are constantly referencing, along
with frequent searches on google.

~~~
asto
I'm quite relieved to hear it. Constantly referencing is what I do to get
around my inability to remember things too!

------
tikhonj
I think what's really interesting here is not what makes a good or great
programmer but rather how everybody has different criteria for "greatness". I
found this thread more enlightening about the commenters than about greatness.

This isn't that surprising: different people do different things, and their
ideal programmer is relative to what they do. Somebody more business oriented
would value more maintainable software and good team-working; a hacker type
would value "getting things done" and "worse is better"; a more academic type
would value novel and nontrivial work. Of course, in reality, what different
people value is more nuanced, but the core point remains: there is no single
definition of greatness.

------
jhawk28
50% of programmers are below average.

~~~
ebiester
50% of programmers are below median. It is quite possible that programmers do
not follow a normal distribution.

~~~
fusiongyro
Interestingly, there is some research to support the idea that ability to
learn programming is a bimodal distribution. One interpretation of this was
that people fall into three basic categories: those who cannot do the
reasoning, those who can, but find it very unpleasant, and those who do it
with some ease. Presumably most professional programmers would fall into the
third category, but if there were some in the second category, that could
perturb the distribution.

<http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf>

------
simonbarker87
So, how do you know if you are a bad programmer? It seems that a programmer
could be bad but think they are great....

~~~
lee
It's really hard to know how competent you are in any field, if you are
incompetent.

There are known knowns, known unknowns, and unknown unknowns. The problem with
really bad programmers, is that the unknown unknowns for them are really
large... so they have no ability to gauge just how incompetent they are.

<http://en.wikipedia.org/wiki/Dunning-Kruger_effect>

~~~
ifewalter
On the contrary,when you get better at coding, just like mathematics,whe you
compare your codes with others programmers and are comfortable with the
similar code patterns and habits, thats one of the indications that you're
becoming a great programmer, just like mathematics.

------
wissler
Ayn Rand's opinion on genius was similar. She said that what was unique to
genius was the ability to very easily shift between different levels of
abstraction.

I would not refer to this as "memory", but as understanding. Memory is of
course involved in understanding, but it is not sufficient for it, and does
not by itself enable the ability to shift.

------
wissler
One of the great things about working in software is that if you want to work
at the frontier and push the limits of what has been done before, you still
can. Your peers may deride you as a "cowboy programmer", but they can't stop
you.

Many other fields have been so heavily regulated by government that truly
pushing the boundaries is either far more painful or impossible, therefore the
pace of improvement in them is far slower than it is in the world of software.

