

How to recognise a good programmer (2007) - j_baker
http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/

======
patio11
I subscribe to the Build Stuff school of programmer evaluation. Why do you
hire a programmer? So you can have him build stuff. Has he built stuff? Then
he can probably build stuff. If he hasn't build stuff, he might be able to
build stuff, but it is a better idea to have somebody else pay to figure out
whether he can build stuff or not.

~~~
derefr
So, if everyone follows your philosophy, how do people get started building
stuff?

~~~
mquander
Hint: You do not have to be employed by a company in order to build stuff.

~~~
derefr
When I say "if everyone follows this philosophy," I include both VCs and
college acceptance boards in that antecedent. Then, presuming you don't have a
trust fund, the only way to get your start building stuff is to do it on the
side while being underemployed; this is a net efficiency loss for the economy.

~~~
mquander
Firstly, colleges are not in the business of making admittance decisions based
on whether you are a good programmer or not; secondly, 40 hours a week is the
standard for being reasonably well-employed, which leaves a whole lot of hours
for doing your own thing in life (not to mention the years you're in primary
and secondary school, during which many programmers build a pretty passable CV
of personal work.)

I feel guilty even typing this much, because I don't think you're being
intellectually honest at all. The vast array of open-source and free projects
in the world speaks plainly about the ability of people to build useful things
outside of work.

~~~
derefr
Okay, let me now be completely clear on how I interpreted your original
statement:

Let "an institution" be "a place where one may work on projects safe in the
knowledge that one's base needs for food and shelter will be met."

    
    
        I(x) := x is an institution
    
        S(x) := x seeks to join an institution
    
        A(x,y) := x will accept y
    
        P(x) := x has completed a project
    
        1. ∀xy( (S(x) ∧ I(y) ∧ A(y,x)) → P(x) )
    
        2. ∀xy∃z( (S(x) ∧ I(y) ∧ P(x)) → (I(z) ∧ y≠z ∧ A(z,x))) )
    
        ∴ ∀xy∃z( (S(x) ∧ I(y) ∧ A(y,x)) → (I(z) ∧ y≠z ∧ A(z,x))) )
    

Or more prosaically, "every institution that will accept a person (and thereby
let them create a project) requires that there exists a project they have
already completed (and thereby another institution willing to accept that
person.)" Obviously there's a problem with that statement :)

That being said, I agree completely with your first paragraph. I was being
half-satirical—not intending to find a _flaw_ in your argument, so much as
desiring to provoke you into strengthening your point by clarifying it (and
trying to go one step beyond the common-sense assumption of "our current
society" to see where this philosophy would take you.)

Do you think the world would be better if programmers could not transition
into the workforce until they had created something that no one had _asked_
them to create? The idea behind a company hiring you is that they need what
you have, and so they pay you for it. If you're creating something and no
one's paying you for it, then, presumably, either you aren't marketing it well
enough, or it's something nobody needs (or you've made it as an act of
goodwill, but the likelihood of Joe the Programmer writing FOSS as anything
other than a prerequisite to a job—which, therefore, means that he really
would rather have been paid, but just couldn't find a taker, again implying
that he was underemployed—is slim to nil.)

~~~
mquander
I admit that I smiled when I saw a big response to me with chunks of predicate
logic in it.

 _Do you think the world would be better if programmers could not transition
into the workforce until they had created something that no one had asked them
to create?_

I'm not sure if the world would be better. There's an overwhelming demand for
competent programmers, and not anywhere close to enough supply to fill it. Is
it better to lower our standards, resulting in shoddy and sometimes
dangerously bad work, or to leave things undone?

However, for any given single institution, I am very confident that that
institution would be better off hiring only people who had created things
which nobody asked them to create. I agree that these are usually things which
either nobody needs, or which are marketed poorly; but I don't see why that
would indicate anything negative about the person in question (as far as the
company is concerned.)

------
Dilpil
In practice, how much of this article is about informing business folk and how
much is about patting ourselves on the back?

~~~
rw140
I'm generally interested in other people's criteria for hiring people as it
makes me think about what I'm not doing (and whether that's a concious
decision or I've just got distracted / out of the habit), and what I could be
doing better.

------
JosephAltmaier
A "good programmer" hasn't been defined, has it? Does it mean an architect,
designer, tester, integrator, debugger, coder? Each of these requires a
different skill set. Very few have all of these skills. Some are nearly
mutually exclusive. I know for instance that a good tester (worth their weight
in gold) has almost completely orthogonal skills to a good developer. The
tester focuses on regression, corner cases, code coverage, etc. The developer
is sprinting toward a goal. I've had some limited experience hiring -
15-member teams for startups. My approach is to fill out the skill set, put
them in a snug environment to promote communication and collaboration, and
then monitor the heck out of the progress. My job then is to keep them on
track, make sure all the holes and cracks are addressed, and mediate
disagreement. I've repeatedly hired (different startups) a plodding,
methodical, university-educated, by-the-book programmer to crank out database
schema with its 200-plus-dialog query frontends. And an inspired, chaotic,
brilliant, chronically sleep-deprived developer to write the 100,000+ lines of
code a year we needed to get to the next funding stage. In the same team. In
the right environment these guys even learned to respect and admire each
other.

------
diN0bot
quality is still hard to measure.

speaking from experience, i've always had passion and personal projects, etc,
but i used to be a sucky programmer. now i feel like i've mastered certain
things, but i'm still developing and getting better.

for one thing, quality comes from sustained effort and committment. i've been
working full time on startups for a while. that's a hell of a lot different
than someone doing a different weekend toy project every month.

i'm friends with some pretty passionate "hackers," and i'm definitely not
knocking that kind of activity---heck, i have side projects sometimes, too.
but there's a big difference between hacking and building something serious.
toying with tons of APIs and langauges doesn't make someone a good programmer.

finding a good programmer is still hard. even if programmers were completely
honest, and the metrics all objective, would they even have the language to
explain to business guys that they were good programmers, both in technical
proficiency and quality? it's not impossible, but it's quite difficult.

~~~
csytan
I find that for me, side projects are very beneficial because they give me
absolute freedom to try new things without stepping on co-workers toes.

I have to agree that metrics don't tell the whole story. It really depends on
what the programmer is looking for. Some people may be attracted to new
features & complexity in their projects, while others look to design a small
simple project.

~~~
diN0bot
trying new things is great. it's also extremely different, or rather limited,
than what is needed for a start up. that is, you need A LOT more than the
desire and experience of toying with new things.

toying is part of the inventor spirit and different projects need different
things. one project might be ok with one of the mockups architects make.
another project might need the life sized building. and so on in between,
changing as the project grows.

------
sketerpot
If loads of false negatives are okay, here's a simple heuristic: I don't think
I've ever seen a Haskeller who wasn't plenty smart.

~~~
ggruschow
I've seen a lot of smart people who weren't good programmers.

------
araneae
Just something I noticed:

"If your potential programmer didn’t do any programming before university, and
all his experience starts when she got her first job, she’s probably not a
good programmer."

This is the only time he uses the female pronoun anywhere in his post, and he
uses it to describe a programmer that started in college and isn't any good.

Conscious or not, it's somewhat accurate; female cs majors are less likely to
have prior experience with programming going into college.

~~~
mistermann
Maybe it shows he actually knows what he's talking about! ;) Not that I agree
with the article entirely...

------
jquery
TL;DR - they're smart and their whole world outside of work revolves around
their profession and they've been doing it their whole lives.

You could write a "How to recognize a good [X]" article about almost any
profession if that's your thesis.

Let's face it, the vast majority of work programming isn't that hard. A lot of
programmers, perhaps especially the good and smart ones, might rationally
realize that having a life outside of work--in other words, working a 9-5--
often makes more rational sense than putting all of one's considerable
intellectual energy into writing yet another CRUD (or whatever application du
jour one normally writes) remix.

~~~
InclinedPlane
I think there's a good point in your comment but I think you have buried it in
unnecessary insults and mischaracterizations of the article.

For all of the great devs I know and have known programming is very much a
passion for them, and they will engage that passion outside of work. But this
doesn't mean their job is their life or that they don't maintain a healthy
work/life balance. Indeed, working on projects they're passionate about
outside of work can often provide a release from toiling with a brain-dead
code base at work.

Also, the vast majority of software development may not be hard, but perhaps
that's because the vast majority of developers aren't that good. The work
being done by the best devs is orders of magnitude better (and more
challenging) than the work being done by the daily-wtf generating paycheck
programmers in the enterprise trenches.

------
rw140
How much weight would anyone here give to the "Started programming at
university" criterion? It's one that is bugging me slightly because 1) it
applies to me and 2) it's not something I can go back and change.

~~~
gridspy
Why did you wait until Uni to learn to program?

Is that the point when you finally realised you had the freedom to do what you
wanted in life? - If so, perhaps you are alright.

Is that when someone told you that you needed a job, and programming looked
well paid? - Perhaps not so good.

~~~
richieb
"Why did you wait until Uni to learn to program?"

Because at that time computers took entire floor of building and costs
millions of dollars. By the time I got my hands on Apple II I was in graduate
school...

------
mlLK
I am going to extend the discussion by asking this, how do you recognize a
_good_ programmer who wasn't born from the culture of academia?

The only reason I ask is that I consider myself a late-bloomer, and after
reading _Coders at Work_ (which I highly recommend) I was kind of bummed out
that I squandered my opportunity in college by not hanging out with CS crowd.
It seemed like so many of Seibel's interview subjects accomplished so much in
this period and were more or less born to be programmers. . .it sounds trite
when I read it aloud but I can no longer ignore this unspoken caste system
amongst programmers.

------
edw519
I know OP means well, but this post provides far more data about his own
experience than anything that can be reliably used by the reader.

What he calls "indicators", I call "co-factors". They may or may not accompany
a given programmer, and they predict nothing.

Generally speaking, good programmers are intelligent and do care about their
work, but his positive indicators are much more a matter of personal
preference than the quality of their work.

For each good programmer OP can identify who programs as a hobby, will talk
your ear off, started programming before university, or has knowledge of a
lots of technologies, I can cite a counterexample.

Similarly, I can also identify many good programmers who possess some of OP's
"negative indicators" like having a day job, enjoying a single technology, not
wanting to talk shop, or enjoying other activities.

There is one sure-fire way to identify a good programmer: their work. In fact,
it is by definition the way that we should evaluate programmers. It is the
great equalizer, and with web technology, exposed for all to see.

It really is as simple as cause and effect: good programmers produce good
work; bad programmers don't. Anything else, including OP's positive and
negative indicators, is just a detail.

~~~
azanar
_There is one sure-fire way to identify a good programmer: their work. In
fact, it is by definition the way that we should evaluate programmers. It is
the great equalizer, and with web technology, exposed for all to see._

Unless you are presuming a team of only a couple of developers doing their own
thing, there is a real challenge in determining the extent of the programmer's
responsibility for something that is exposed for all to see.

There are a number of other causes that might make a site a developer helped
work on look or run like complete garbage. Organizational inertia might have
forced the site into sucking, regardless of how good the programmers
developing it were. The organization may have one or more bad programmers who
were assigned to work on some critical component, screwing the whole site and
all the good programmers.

We can wax on eternally about how the good programmers in this situation
should've seen the writing on the wall and gotten out as soon as possible, but
that's very easy to say seated in armchairs gazing from afar. Maybe they
thought things were going better than they really were; maybe they saw things
going bad, and thought they could motivate others to turn things around before
things become a disaster -- and maybe they failed trying to do that[1]; maybe
they have been trying to get out, but they are already tainted by the bad work
of the organization that has become part of their image as well.

They could do work outside of their employer, for instance on an open source
project, but these can succumb to the same sort of pressures that push profit-
seeking organizations toward mediocrity. A single developer, even a really
willful one, will have a hard time overcoming this inertia.

[1] At one of my prior employers, I was in this boat; I both tried and failed
to get things turned around. I did quit, but probably not soon enough to
convince people that the site was not a reflection of me and my standards. The
site was absolutely shameful, and I'm sure anyone who used that site to infer
things about my skill level would've sworn I had no skill or experience
outside of a weekend PHP crash course. Granted, it would vet one organization
I would probably not want to work at; but it would represent wasted potential
based on presumption, which is a shame.

I really think the details matter, because they are a chance to determine if
the work you are using to assess the programmer is spurious input, and reflect
an influence largely made up of things _other_ than that programmer.

~~~
InclinedPlane
Yes. This is a far more difficult problem than people seem to appreciate.
Except for open, solo projects, finding out the work that people have done is
challenging. Which goes a long way to explain the difficulties of the job-
finding and interview process.

Consider the common case of the average developer (especially so for a non-web
developer). They've worked on several closed source projects on which the
extent of their participation is non-trivial to determine. Ultimately you have
to talk with them and suss out what they actually know, which is at least a
day long process in order to attain any degree of accuracy.

Even if they've worked on open source projects, it may take a lot of effort to
grovel through their commits to find out whether or not they're telling the
truth on the size of their contributions.

Incidentally, all of this is a good reason to have your own personal solo
project and your own personal blog, though it can take a lot of effort to do
so.

------
clistctrl
I would say I fit all of his criteria, but I would define myself as a mediocre
programmer at best.

------
dbz
I fit some of those criteria! I don't feel it in my place to judge my
programming skills in front of everyone here though. =p

