Re: What makes a (super-)programmer?

From: Les Cargill (lcargill_at_worldnet.att.net)
Date: 01/19/04


Date: Mon, 19 Jan 2004 00:01:05 GMT

CTips wrote:
>
> We know that there exist people who can far out-produce the average
> programmer. For instance, I know of 3-6 people who can produce 100klocs+
> of shippable code a year. Of course, just mentioning that figure does
> not adequately capture their abilities - that 100kloc would be
> 200-300kloc were it written by less skilled programmers, and it is
> higher quality in other aspects as well.
>
> I also know about 10-20 50kloc+ shippable/year programmers; again, that
> 50klocs is better quality than from an average programmer.
>
> So, what sets these peopele apart from the rest? What makes a
> super-programmer? More important - what is keeping "average" programmers
> from becoming better?
>
> Here is my list of observed similarities:
> - all of them can type fast - I'd guess 30wpm+
> - they use editors like vim,emacs,epsilon,sam - keyboard-centric as
> opposed to mouse-centric editors
> - they have a formal education in computer science.
> - they are intelligent
> - most use C, but a couple use scheme and ocaml.
> - they tend to work in systems (though this may be observer bias)
>
> Unfortunately, this list is only somewhat prescriptive. I guess I'm asking:
> - If you're a 100kloc/year programmer: what makes you so productive?
> - If you're a 50kloc/year programmer: what makes you more productive
> than the average programmer? Whats preventing you from being even more
> productive?
> - Otherwise: What's preventing you from being more productive?

KLOC are such a bad metric even Ballmer knows it. You can't even
measure productivity unless you're willing to have strong acountability
top to bottom throughout the organization, and it *will* be
severely biased by local mores.

"Defect density" is an improvement, but it chills progress. You have
to be very careful and know the customers and know how to
establish contingency plans when things go wrong.

My experience is that somebody who is deliberate and produces
a low rate of errors will arguably be of more value than
somebody who spews out cubic yards of slop. But one sloppy/fast
guy can act as a "point man" and get stuff on the table, and
any number of "cleanup" guys can firm his output into a
product. Depends. Who are the customers, and what are the
deliverables?

Making simple mistakes is the preferred thing. The Hard
Part is avoiding profound mistakes that cost a lot to fix.

I once spent two weeks characterising and fixing code to
manage a circuit which had been reused as a block for *fifteen
years* and had very subtly elicited failure modes, which
the tests designed to find would have never found. The
only reason it came to light was because a very dogged and
talented field service guy insisted it was broken. He
designed a test, and we fixed it.

And negative productivity is a distinct possibility.

--
Les Cargill