On Sat, 4 Nov 2006 15:19:18 +0530, Devdas Bhagat wrote:
> On 04/11/06 06:10 +0530, sastry wrote:
> > On Friday 03 Nov 2006 8:43 pm, Kragen Javier Sitaker wrote:
> > > I wonder what makes one programmer good, and another average
> >
> > What makes a programmer "bad" or "average"?
> >
> That elusive thing termed 'code quality'. A good programmer can write
> readable code to do the right thing. A bad programmer can write readable
> code to do almost the right thing, or just unreadable code.
Let's stipulate that a bad programmer is one who produces bad code.
The question I was asking wasn't how to tell whether someone is a bad
programmer --- I have some clue about that. The question I was asking
is, what causes some people to be good programmers, and others to be
bad programmers?
Carol's NIAS-IDPAD report suggests one answer. To take one example of
the institutionalized incompetence it describes, "coding", "testing",
and even "software development" are apparently universally considered
"low-level jobs" --- so universally that even the report itself
discusses them as such --- and most people apparently get out of them
in five years or less, moving into either "architecture" or
management.
It's hard to believe there are people who consider the work done by
Kernighan, Knuth, Hoare, Marick, Thompson, Beck, Ingalls, Stallman,
djb, and the like to be "low-level", but apparently there are.
In a work environment with such a corrupt value system, it's not
surprising that people don't put in the many years of hard work needed
to develop their programming talents, and talent in any field is
worthless without that hard work.
But perhaps there are other factors as well. On FoRK, Dave Long
recently suggested "crit groups" for software in order to diffuse the
knowledge of difficult-to-explain things like code aesthetics through
a group of programmers; and in my experience of code reviews, I have
found that I learned a great deal from the process.
To be fair, though, most of my experience of code reviews comes from
working in an Extreme Programming team, and code reviewing is one of
the things XP takes to an extreme --- all production code, tests, and
design are reviewed in real time as they are written, and typically
over the next few days by several other team members. I don't know to
what extent less-intense code reviews would have the same effects.
Can anyone comment on code-review latency time and quality of comments
of in current Indian IT shops? Carol's report is curiously silent on
the matter, at least as far as I have read, but I assume that the CMM
mandates code reviews --- it's one of the practices most solidly
supported by software engineering research.
(I don't actually believe that a bad programmer is just someone who
produces bad code. Other dimensions of being a bad programmer might
include producing no code at all, taking the time to produce good code
when bad code would be more appropriate, willingness to accept
impossible constraints, and willingness to commit to decisions without
enough information to know if they're good ones.)
> Programming is simply a job of translating between human readable
> language to an exact, formal computer "understandable"
> language. Some people are better translators than others, possibly
> because they know the domain of work better, and get more done with
> less lines of code.
I don't agree with that characterization of the nature of programming.
Despite this:
When a professor insists computer science is X but not Y, have
compassion for his graduate students.
I'll say what I think programming is. It is a job of taking an
ambiguous, vague idea and making it completely specific, finding out
in the process what the idea really is, and maybe coming up with a
different idea in the process that turns out to be better. But that
description leaves out debugging, optimization, and the experiments
and consultations that are often needed to figure out what the job
should be in the first place.
