[OT] dealing with lower level programmers

[James Kanze]

"Andrew Tomazos" <[email protected]>

I'm quite sure James worked with some of those.

What I seriously doubt from reading many his posts, that he
worked with bad ones. And mor importantly with many average
ones. And if you cut the first 80% of measuring data,
certainly different figures will emerge.

I've worked with many different types. What I've seen is that
the environment makes a big difference---once or twice, I've
been in an environment where even the best programmer couldn't
produce anything good. And I've worked in one place where even
very average programmers (and one or two definitely below
average) produced good code.

On the whole, if you want to produce good code, it's best to
have at least one or two distinctly better than average people;
software isn't that cut and dried yet, and you do need some real
creativity. But an exceptionally good programmer in a bad
environment will still be less productive than an average
programmer in a good environment (where he will, for example, be
encouraged to recognize his limits, and ask for help when
necessary).

I tend, here, to talk mostly about the better places I've
worked, and not mention the worst (where management seemed to go
out of their way to ensure failure). The large differences in
productivity that I've seen, however, have more to do with
different processes, than with different levels of programmer
skills.

Being able to find the good places to work, and restrict to
only those is a good thing -- but not too widespread.

On the whole, I think I've been fairly lucky. Being a
contractor has meant that when I did end up in a bad place, I
could leave quickly. And with the time, I've learned to ask the
right questions during the interview---I interview the potential
client as much as he interviews me.

 

[Pascal J. Bourguignon]

[ ... ]

Have a look at the figure #3 on page 9 of this report:

http://www.haskell.org/papers/NSWC/jfp.ps

Notice that it has been written by a Haskell advocate. Compare the
development time of Lisp vs other programming languages...

To get anything meaningful, you need to look at more than just that
one figure. First, you need to take into account that this was
development of a prototype, not real code. Second, you need to look
at the date on the paper -- 1994. [...]
All in all, it's an interesting paper, and I'm glad you posted the
link -- but I don't think it provides much support for conclusions
about C++ or Lisp.

I agree that this kind of experiment should be re-done more
serriously, on complete projects, and with the conditions of today,
such as access from the internet to libraries and documentation,
modern language features and development environments, etc.

 

[James Kanze]

* Ian Collins:

Your argument wouldn't be much different with one order of
magnitude, and that's commonly observed.

Is it?

So where does the argument go wrong? It's simply that the
argument assumes that the requirements for graduating and
holding a job, in a technical profession, have to do with
productivity and/or quality, a sort of monotonically
increasing function, whereas in reality there can be little
direct connection between technical ability and success, and
whereas success can have more to do with conformance and
social issues. In fact, a recent career guide in Norwegian
"Dagens Næringsliv", a leading economics newspaper in Norway,
cautioned strongly against doing too well while at the lower
rungs of the ladder because one is then viewed as a threat
both by co-workers and by one's boss, and reader comments were
uniformly positive that at last some reality was discussed.

My argument only concerns best compared to average. I'm aware
that on the negative side, there are some real outliers, which
make you wonder how they did get a diploma. But they're
outliers, not average, and they're rather rare (and often do
have problems getting a job). On the positive side, there seems
to be an upper limit to human ability, regardless of the field
of endevor. It's certainly true for most fields, and I see no
reason to think that it's different for programming.

Third google hit on "programmer productivity", citing e.g.
Steve McConnell, Randall E. Stross and [clc++m] mod (now
inactive) Robert C. Martin:
<url:http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/>.

It's so common and well-known that it has its own name.

It's a relatively wide spread misconception. If you'll look at
the quoted text, McConnell mentions that it also applies to
teams---that definitely suggests that it is more of an
environmental effect than a difference in actual programmer
ability.

There is a difference between programmers, and some are better
than others. But the difference is nowhere near 100x, and most
of the time, the difference depends on which aspect of
programming you're considering---I'm much better at working on
e.g. threading problems than I am in numerics, and I've met
programmers much better than me in numerics who had serious
problems with threading.

Note that this fact, the observed reality,

The "observed reality" seems to be mostly annecdotal, and not
measurable. And doesn't square with what is measurable (in
other domains).

 

[James Kanze]

Again it depends on what "better" means. How are we going to
measure it? Are we going to compare someone who's been in the
field for decades, and constantly making sure their knowledge
is current, to someone straight out of college? You would
probably get close to 100x difference in any method you chose
to measure their code quality and production.

That's not necessarily true. Part of being "good" (and I
believe that most programmers are good) is being able to
recognize your limits. If the recent grad, even average, is in
a conducive environment, he'll be able to recognize when he
starts getting in over his head, and ask questions, or look the
information up. It will take more time than someone who's
already encountered the problem, but not 100x more.

Still, you do have a point. If you're fully familiar with the
domain, and have already implemented enough similar programs,
you know exactly what to expect, and you've already seen all of
the problems that can occur, and know the solutions to them
without thinking. In such cases, compared to someone who's
unfamiliar with the domain, who knows what the difference can
be. Maybe I've been lucky, but on all of the projects I've
worked on, there's been enough novelty that there's never been
someone that prepared in advance. And would you consider
someone who's writing what is essentially the same code for the
fifth time "better", just because he can write that code (and
not necessarily anything else) much faster than anyone else.

I'm of the opinion that good developers do something extra on
the side to keep themselves updated.

I'm of the opinion that good management ensures that its
developer keep up to date.

They read books, experiment with stuff they can't experiment
with at work, and they continue to bring in new, fresh ideas.
A lot of people are simply not motivated to do this but think
going to work and getting the job done is enough. I frankly
don't know what it's like in the larger companies but I see
this quite a lot. Nothing wrong with it if that's what you're
about but someone who goes the extra mile is going to be
better (no matter how much of a star you were in school) and
in many cases that difference will be significant.

Obviously, if you've only done Java, your first project in C++
will take more time that you or I would require.

[...]

Again, it depends. If you're talking about a big company that
has lots of money and can hire the best then I'm sure you're
right.

Actually, I think it's easier to hide incompetence in a big
company. If the company's small enough, and someone is truly
incompent, either they recognize it and replace him, or they go
out of business. (The few outliers I've seen---truly
incompetent people---have been in big companies.)

[...]

So I think that though the 100x figure is a bit extreme I do
believe there can be significant differences between
developers,

Again, I don't dispute that there will be significant
differences. What I do argue is that there won't be anything
near 100x between average and best---for some reason, the
extreme differences always seem to be on the negative side
(although it's rare, I've seen total incompetence), and that the
environment will often (always?) make a bigger difference: One
of the best programmers I've known had a negative productivity
on the project where I met him; all of the programmers on that
project had negative productivity---management ensured to that.

 

[Balog Pal]

"James Kanze" <[email protected]>

I've worked with many different types. What I've seen is that
the environment makes a big difference---once or twice, I've
been in an environment where even the best programmer couldn't
produce anything good. And I've worked in one place where even
very average programmers (and one or two definitely below
average) produced good code.

On the whole, if you want to produce good code, it's best to
have at least one or two distinctly better than average people;
software isn't that cut and dried yet, and you do need some real
creativity. But an exceptionally good programmer in a bad
environment will still be less productive than an average
programmer in a good environment (where he will, for example, be
encouraged to recognize his limits, and ask for help when
necessary).

Exactly! That is what I implied in a previous post. This way you measure
in the impact of the envirionment in the individual performance -- and reach
the very different figures.

The most amount of impact of the god programmers is not in the lines of code
they cranked out by hand -- and using them to write much code themselves
would be a serious waste. The value comes from their view, insight,
knowledge, exprerience, (...) applied to the whole team. making it tick, and
fare toward the target. ( what makes the comparision even more moot...

Sure, the average programmer can write a ton of working code if he receives
design and code reviews, mentoring, and supervision as necessary.

But left on his own devices, the story is different. It is interesting (and
so sad) to look at projects that got abandoned by the good programmers and
being maintained by the "average". Picking up all the antipatterns in the
book quite soon, and declining.

I tend, here, to talk mostly about the better places I've
worked, and not mention the worst (where management seemed to go
out of their way to ensure failure). The large differences in
productivity that I've seen, however, have more to do with
different processes, than with different levels of programmer
skills.

Yeah, and the others (Noah?) estimate that your "better places" are the tiny
minority of sw producing places.

On the whole, I think I've been fairly lucky. Being a
contractor has meant that when I did end up in a bad place, I
could leave quickly. And with the time, I've learned to ask the
right questions during the interview---I interview the potential
client as much as he interviews me.

Exactly. As expected. What is very good, just makes you view of the
world very much filtered. Especially to the extent.

 

[Balog Pal]

So I think that though the 100x figure is a bit extreme I do
believe there can be significant differences between
developers,

Again, I don't dispute that there will be significant
differences. What I do argue is that there won't be anything
near 100x between average and best---for some reason, the
extreme differences always seem to be on the negative side

It is just artefact of the arbitrarily picked measuring methods.

Say you want to compare people on long jumping. (this is just parable, not
aiming accuracy, substitute actuel values where necessary)

Current sport way is to make 5 jumps and take the length of best in cm. So
AvgJoe can measure 600, and the worl recorder 900. 50% diff. It is insane
to think the best coud jump 10x let alone 100x the distance.

However, suppose we have a different way to do the competition: an arbitrary
distance D is picked, and candidates must jump over that "chasm". Everyone
keep jumping until falling in or saying enough. And you get X points for
every success and, Y (some negative value) for a fail, B as base.

Now comparing the points will make a very different spectrum 100x times
difference easy to reach (after we overcome some adjustment for div0 and
play with X,Y,B). Especially tweaking D, after the other numbers are set.

The second measuring method may look weird at first, but probably has a
better value guessing evolutionary value of the performance.

 

[James Kanze]

"Noah Roberts" <[email protected]>

I'd approach from the other direction. The average programmer
planted the otiginal bug in the code, being unaware of stuff
like 'you initialize variables' 'you read the F*ing
warnings', and so on.

What kind of average programmers are those? I've yet to meet a
programmer who didn't know that variables have to be
initialized, and the treatment of warnings has always been a
matter of policy, which even the worst programmers respect.
Errors like uninitialized variables do creep in, because
programmers (even good ones) are human beings, and make
mistakes. A weaker performer may make more, but even the best
programmers aren't exempt from them.

Of course, if an error has been pointed out to you in a code
review, you tend to pay more attention to what caused it in the
future.

I observed organisations, especially bosses tend to not
calculate with prevention at all.

That depends on the organization. An ounce of prevention is
worth a pound of cure, and good organizations know this.

Instead, measuring 'hard work' in the amount of visible sweat.

No. In the poorly managed places I've worked in, "hard work" is
measured by being seen at work late in the evening. Whether
you're actually doing anything or not. (In this regard, Martin
Suter's "Business Class" is well worth reading. I'm not sure
that it's been translated into English, however.)

 

[James Kanze]

In trying to understand where the 100x factor comes from
consider:

In trying to understand anything, don't speculate, measure.

[...]

Have a look at the results of one of the completed marathon
matches at TopCoder.com. You can see the problem statement,
the finalists and their code.

What you can't see is how they developed it? Whether they
worked alone, or in a group? What technical environment they
were working in? There's absolutely nothing which would make me
thing that the "winner" would be productive in the environment I
work in, or that some of the lower placers wouldn't be more
productive than the winner if they were in the same environment.

1. Get the winner of the recent TopCoder marathon match "Fred".
2. Get the next problem statement.
3. Give Fred a day to do it.
4. Assemble a team of 10 average programmers - give them 10 days to do
it.
5. See who wins.

My money is on Fred.

If the program can be implemented in a day, I don't know. If
Fred can implement it in a day, it can't be significant, and I
certainly wouldn't put a team of 10 programmers on it. If Fred
can implement it in a day, however, two or three average
programmers won't take more than two or three days, unless there
is something in the environment which prevents them from being
normally effective.

I might add that I can't find anything at the site which says
how the programs are judged, or how they are deamed "correct" or
"good" or anything else. In fact, off hand (and I'll admit that
I've only made a superficial visit) the site more or less looks
like a scam to get software developed at less than the going
price (and probably significantly less than generally accepted
minimum quality).

 

[Balog Pal]

What kind of average programmers are those? I've yet to meet a
programmer who didn't know that variables have to be
initialized, and the treatment of warnings has always been a
matter of policy, which even the worst programmers respect.
Errors like uninitialized variables do creep in, because
programmers (even good ones) are human beings, and make
mistakes. A weaker performer may make more, but even the best
programmers aren't exempt from them.

'Coding standards', guidelines, etc, are written for who? Not the average
programmers? All of them include the 'DO init the $%#$% variables'. IMO
because the practical obseravation is is just not happening.

The 'creep in' is true, please think about how it actually happens:

- I do not init the variable where created, because it will get value later
on, before use
- that later on is avoided on some code paths that still lead to use.

And this creates the ital difference: the good programmer will more likely
shape the code to prevent the situation altogether (i.e defining variable
where initialized, not C90-way), or well aware of all the paths. The
average one isn't. Also the first will do a self-review of the paths and
run tests with proper values, the other will not (often enough).

Yeah, human beings do mistakes, Murphy does not sleep, and sometimes the
good programmer too misses some combination of events, or just makes a typo
putting the good value in the wrong variable, then keeps reading his code as
if it had the correct text.

But the average is not just ht by Murphy, but by the limitation of his
thinking. Keeping all the relevant info in the head, skill to see all the
relevant combos, and so on. and/or the attitude to do stuff properly instead
of cutting some corners.

Of course, if an error has been pointed out to you in a code
review, you tend to pay more attention to what caused it in the
future.

Of course my ass. my experense shows huge organizations are filled up with
completely ignorant people caring little about the project, and in general
about anything besides their desk and salery.

Having that genuine drive to do the job WELL and paying attention is in
itself a trait in the above-average club. And it will stay that way as
long as serious selection process will be forced on programming, and clients
can start winning lawsuits for malpractice and bad products. (not in
visible future).

That depends on the organization. An ounce of prevention is
worth a pound of cure, and good organizations know this.

Yes, and they appear pretty rare.

No. In the poorly managed places I've worked in, "hard work" is
measured by being seen at work late in the evening.

Err, and what is "no"?

Whether
you're actually doing anything or not. (In this regard, Martin
Suter's "Business Class" is well worth reading. I'm not sure
that it's been translated into English, however.)

That is the same thing I say, the visibility-based development. The boss
can't tell real work from anything, so "being around late" is one of his
best guesses of performance.
Possibly discounting instances he found someone on quake or a forum during
daytime, that can mess up the picture even more.
Read the story Jerry linked recently up this thread.

 

[James Kanze]

[ ... ]

For that statement to mean anything on earth you shall fill with
meaning the terms:
- "good programmer"
- "average programmer"
- "productiveness of the programmer"
Until that the whole debate is no different from "how many
angels can dance on the top of a needle".

For the current discussion, all of those really revolve around
the last -- i.e. what is meant by productivity. I'd measure it
in terms of function points implemented per unit of time.
Other people might prefer to use lines of code -- under the
right circumstances (within a given project, all using the
same language, etc.) that can be reasonable, but especially
across languages it becomes difficult to compare meaningfully.

At least part of the argument centers around what we mean by
"good" code. Just implementing a function point isn't
sufficient, the implementation has to be "sufficiently correct"
and "sufficiently maintainable".

From there, about all you really need to define for average is
what average you want to use: the arithmetic mean, the
harmonic mean, the geometric mean, the median, the mode, etc.

And what you're averaging. If you're using the median over all
human beings on earth, then the 100x factor is probably too
low---I'd bet that over half of the world's population can't
program at all. The claims only make sense, however, if you're
talking about professional programmers---people who are paid to
program for a living. And within that group, there is an elite,
but the difference between the elite and the average isn't
anywhere near a factor of 100---more like three to five.

If you were going to use the mode, you'd also have to define
your strata as well, but I don't think it's suitable here, so
I wouldn't bother. While most people find the arithmetic mean
the most understandable, given the claimed variability, the
geometric mean would probably be a better choice.

I was actually thinking of the median. But I don't think it
matters too much---most programmers are probably fairly bunched
near the center.

In this context, it seems nearly certain (at least to me) that
"good programmer" was intended to mean "highly productive" or
(probably) "most productive."

In what environment. Productivity depends more on the
environment than on the individual programmer---I've seen
environments where even the best programmer couldn't be
productive, and in well run shops, "average" programmers can be
very productive. Since it depends so much on the environment,
productivity can vary greatly, because there is a great variance
in environments.

 

[James Kanze]

James Kanze wrote:

Ah, but measure what?

Everything.

Seriously, it is a difficult question. One of the reasons I
keep coming back to errors per KLOC is because it is easily
quantified and measured. Most other aspects, many just as
important, aren't so easily quantified and measured. In my
experience, code with few errors tends to be easier to maintain,
because the techniques used to reduce the errors also make code
more readable. But I can't quantify that. And customer
satisfaction is even vaguer, at least in some environments.
(I've worked on a number of systems were all that was required
was that the program work as specified. 24 hours a day, 7 days
a week, without interruption. No crashes or incorrect behavior,
and the customer was satisfied. But that's certainly not
sufficient for a lot of programs.)

I've always judged my my code by either customer satisfaction
and (lack of!) support revenue with a single customer or field
defects for applications with many, unknown, customers.

How do you quantify the customer satisfaction?

Of course, there are many aspects to consider. I think you're
an independent---in a very real sense, your code is "good" if it
brings you repeat business, and bad otherwise. (But I think
you're professional enough to set your standards a bit higher
than just that.)

 

[James Kanze]

Actually, what I said was that in order for something to be
empirically based there must have been a measurement done.

I don't agree with you that software "goodness" is something
that can be measured. In fact, I can't think of any
"goodness" that is possible to measure. Various things that
various people think are "good", sure, but "goodness" is a
subjective term that can't be empirically measured or applied.

Well, if we're going to compare it, we need something
empirically based, because otherwise, it's just words in air.

For example, you are using "goodness" to mean, "lack of
errors." We can measure errors, somewhat, but since not
everyone agrees with your use of the term "good" we haven't
objectively measured "goodness". This is why when speaking
empirically it is best to use objective terms like "lack of
error" instead of "goodness". Then people know WTF you're
talking about.

Maybe my point of view has been deformed by having worked on
critical projects, but code which crashes isn't good, no matter
what other criteria it fulfills. Not crashing isn't a
sufficient condition, but it's a necessary one.

And the measure of "good" is somewhat subjective. I didn't
intend to publish a book (or even write as much as I have on the
subject)---I simply intended to point out (and insist on the
fact) that programming requires teamwork. In a very real sense,
doing anything well requires some sort of teamwork, and
programming isn't an exception. The classical image of the
genius hacker working alone doesn't correspond to today's
reality; the programs we write are too complicated.

 

[James Kanze]

James Kanze wrote:

[...]

Just to look at some of the questions that are asked here
daily which show fundamental misunderstandings or surprising
lack of even the most basic knowledge -- and those are asked
by the ones who find Usenet. And not all of those asking such
questions are newbies just trying to learn the language.

I've seen one or two real duds in industry---the mentor assigned
to help me get up to speed in C++ in my first professional use
of the language (I'd written the usual String, AssocArrayOf and
RegularExpression classes on my home computer before) once
complained that there must be an error in the compiler, since it
said "missing semicolon" on line x, and there was a semicolon on
line x---he also explained to be that a clever trick to get a
line to compile was to put two slashes at the start of it. But
they've been by far the exceptions: one or two in over thirty
years of professional programming.

Note too that not knowing a language is not proof of
incompetence. There was a time I didn't know C++. There was
even a time I was working professionally and didn't know C. Not
being able to learn is a serious problem, especially in our
field, but such people tend not to get jobs in our field, or at
least not to keep them, since it does change so rapidly. And
while I know that there are exceptions, employers, at least here
in Europe, are becoming more or less computer savey, and the
**** and bull stories that would get you through an interview 20
years ago don't work today. In fact, in some ways, the problem
is just the reverse---potential employers will go to extremes
checking out your C++ knowledge (which you could easily acquire
on site, if you were hired), but will ignore whether you can
communicate and work well with the rest of the team (which is in
many ways more important).

 

[James Kanze]

Or visa-versa. A human alone has X number of flaws. A group
of humans has XN number of flaws and often times the X's
complement each other to create new flaws so you have XN + Z
number of flaws such that for any n in the group the non-flaws
about that person cannot possibly counter the flaws in the
entire group.

It depends on how the group is organized. I know that the
intelligence of a mob is the intelligence of the dumbest person
in the mob, divided by the number of people in the mob. But
normally, software organizations aren't organized like mobs. I
also know that in critical systems, it is usual to have several
systems performing more or less the same work (pair
programming, in sum), because the failings of one system will
not overlap with those of the other system. In a well run
organization, that's the way it works---the errors one person
makes are caught and corrected by another person. You don't
have to use pair programming---in fact, I think that there are
even more effective alternatives---but code that has been
written by one person and not even looked at by another is very
suspect. And I suspect, although I've no measurements to back
me up here, that two people, using pair programming (meaning two
people in front of one keyboard for all programming activity),
will take less than half the time that a single person, working
alone, will take to produce a program "sufficiently correct" and
"sufficiently maintainable", for all reasonably non-trivial
programs and all reasonable definitions of "sufficiently
correct" and "sufficiently maintainable". (Again, I'm pretty
sure that even better methods exist. But I'm definitely sure
that pair programming is more effective than lone wolf
programming.)

 

[James Kanze]

But you haven't told us why "good software" must be "perfect
software".

Because, of course, I can't. Perfect software doesn't
exist---even teams make mistakes. And I guess good is somewhat
arbitrary---some people think that Windows (or Linux) is good.
Shit, when I first started C++, some people claimed that g++ was
good. Today, g++ is one of the better C++ compilers, but it's
still far from being what I would consider "good". When I
started C++, on the other hand... One of the bugs I encountered
was that it didn't call destructors on local variables if your
returned from a function, as opposed to running off the end.
But there were still any number of people to defend it.

From my perspective it doesn't require a perfect human to
develop _good_ software..convenient thing too because
otherwise there'd be no such thing as good software, written
by teams or otherwise.

Agreed. But surely there must be some sort of minimum quality.
It's a moving target (what was considered "good" software 30 or
40 years ago would count as junk today), and the exact minimum
might depend on the context, but while somewhat vague and
imprecise, it does seem to make sense, to me, to talk about
"good" software.

 

[James Kanze]

"James Kanze" <[email protected]>

[...]

Exactly! That is what I implied in a previous post. This way
you measure in the impact of the envirionment in the
individual performance -- and reach the very different
figures.

The most amount of impact of the god programmers is not in the

^^^
That's an interesting typo.

lines of code they cranked out by hand -- and using them to
write much code themselves would be a serious waste. The
value comes from their view, insight, knowledge, exprerience,
(...) applied to the whole team. making it tick, and fare
toward the target. ( what makes the comparision even more
moot...

Sure, the average programmer can write a ton of working code
if he receives design and code reviews, mentoring, and
supervision as necessary.

And the best programmer can't really write working code at all
without some design and code reviews, and supervision. It's a
continuum: the best programmers aren't perfect, and the medien
isn't really that bad either. There are certainly some
programmers who would be better off working in a different
field, but they seem to have become an increasingly small
minority.

But left on his own devices, the story is different.

Working in absolute isolation, it's hard to say. A lot depends
on the requirements. If something totally new is required, the
chances are better with one of the "exceptional" programmers,
but they're far from 100%, and I've seen some pretty average
programmers hit it lucky as well. Most programs, however, don't
really need anything not already known. And average programmers
are capable doing that. Perhaps even better that the elite,
because they don't get bored by it as quickly. (Note that while
an elite programmer improves the performance of the average
programmers in the team, the reverse is true as well. Because
he is relieved of the less challenging parts, the elite
programmer doesn't get bored as quickly.)

And note well that the difference in competence between the
elite and the average is between three and five. Not one
hundred.

[...]

Yeah, and the others (Noah?) estimate that your "better
places" are the tiny minority of sw producing places.

That's not my impression. It's been a long time since I've had
to turn down an offer because the company looked bad. And I
typically interview for quite a few places before deciding.
Judging from the interviews I've had, the quality of management
has increased enormously in recent (last 10 or 15) years. (Of
course, if for some reason you're stuck at one of the bad
places, this doesn't help you.)

 

[Jerry Coffin]

- I do not init the variable where created, because it will get
value later on, before use
- that later on is avoided on some code paths that still lead to use.

And this creates the ital difference: the good programmer will more likely
shape the code to prevent the situation altogether (i.e defining variable
where initialized, not C90-way), or well aware of all the paths. The
average one isn't. Also the first will do a self-review of the paths and
run tests with proper values, the other will not (often enough).

Code that requires tracking every path and ensuring initialization in
every one is (almost by definition) fragile, and should generally be
avoided if possible -- one of the most common forms of maintenance is
to add code for something that wasn't previously taken into account,
which almost inevitably creates a new path through the code, and with
it a new chance for the variable to remain uninitialized.

IMO, it's better to plan for that, by (for example) creating a type
with a ctor, so initialization becomes nearly impossible to avoid --
either the ctor takes an argument, so the code won't compile without
supplying an initializer, or else a default ctor is supplied so it'll
be initialized even if no initializer is supplied.

But the average is not just ht by Murphy, but by the limitation of his
thinking. Keeping all the relevant info in the head, skill to see all the
relevant combos, and so on. and/or the attitude to do stuff properly instead
of cutting some corners.

IMO, the ability to keep all relevant info in your head is
counterproductive more often than not -- people who can do so, tend
to depend on doing so far too often, leading to code that's quite
fragile when handled by anybody with even slightly less ability in
that specific direction. Code should not only BE bug-free when
written, but be written to remain bug free.

 

[Jerry Coffin]

[ ... ]

At least part of the argument centers around what we mean by
"good" code. Just implementing a function point isn't
sufficient, the implementation has to be "sufficiently correct"
and "sufficiently maintainable".

Well, yes. The time measured should not just be for the initial
implementation, but over the life of the project.

Even that is somewhat of a simplification though: something that's
implemented sufficiently poorly can (and often will) lead to extra
work in other parts of the project. In theory, you'd like to measure
that as well, but it's usually almost impossible to do so --
especially in the (frequent) case of a good (or at least accurate)
implementation of a poor specification.

And what you're averaging. If you're using the median over all
human beings on earth, then the 100x factor is probably too
low---I'd bet that over half of the world's population can't
program at all.

Hmmm...I think it's safe to guess that fewer than 1% can program at
all. I'm not even certain that half the world's population is really
even literate (no, I'm not trying to be elitist in saying that, only
observing that there are quite a few places where literacy rates
really are very low -- including some where teaching certain people
to read is illegal or considered immoral).

The claims only make sense, however, if you're
talking about professional programmers---people who are paid to
program for a living. And within that group, there is an elite,
but the difference between the elite and the average isn't
anywhere near a factor of 100---more like three to five.

I don't think even that much is needed. A 100x difference between
elite and average would imply a 10000x difference between elite and
"bottom".

To put that in perspective, assume there are 2000 working hours a
year. That multiplies out to the worst taking five years of full time
work to match one hour by a top programmer.

If you just picked somebody at random off the street, in less than
five years they could learn to program enough to do at least as much
as a really good programmer could do in an hour.

 

[Brian Wood]

"James Kanze" <[email protected]>

    [...]

Exactly!  That is what I implied in a previous post.  This way
you measure in the impact of the envirionment in the
individual performance -- and reach the very different
figures.
The most amount of impact of the god programmers is not in the

                                   ^^^
That's an interesting typo.

lines of code they cranked out by hand -- and using them to
write much code themselves would be a serious waste.  The
value comes from their view, insight, knowledge, exprerience,
(...) applied to the whole team. making it tick, and fare
toward the target.  ( what makes the comparision even more
moot...
Sure, the average programmer can write a ton of working code
if he receives design and code reviews, mentoring, and
supervision as necessary.

And the best programmer can't really write working code at all
without some design and code reviews, and supervision.  It's a
continuum: the best programmers aren't perfect, and the medien
isn't really that bad either.  There are certainly some
programmers who would be better off working in a different
field, but they seem to have become an increasingly small
minority.

But left on his own devices, the story is different.

Working in absolute isolation, it's hard to say.  A lot depends
on the requirements.  If something totally new is required, the
chances are better with one of the "exceptional" programmers,
but they're far from 100%, and I've seen some pretty average
programmers hit it lucky as well.  Most programs, however, don't
really need anything not already known.  And average programmers
are capable doing that.  Perhaps even better that the elite,
because they don't get bored by it as quickly.  (Note that while
an elite programmer improves the performance of the average
programmers in the team, the reverse is true as well.  Because
he is relieved of the less challenging parts, the elite
programmer doesn't get bored as quickly.)

And note well that the difference in competence between the
elite and the average is between three and five.  Not one
hundred.

    [...]

Yeah, and the others (Noah?) estimate that your "better
places" are the tiny minority of sw producing places.

That's not my impression.  It's been a long time since I've had
to turn down an offer because the company looked bad.  And I
typically interview for quite a few places before deciding.
Judging from the interviews I've had, the quality of management
has increased enormously in recent (last 10 or 15) years.  (Of
course, if for some reason you're stuck at one of the bad
places, this doesn't help you.)

I recommend not working as an employee of a company that
supports homosexuality. That's one of the reasons I started
Ebenezer Enterprises -- to prevent having my work being used
to support immorality. Unfortunately today the majority of
companies are supportive of homosexuality. 50 years ago I
don't think there were any that corrupt. "In Defense of
Homophobia" by Jonathan Katz is helpful in this area --
http://wuphys.wustl.edu/~katz


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[Andrew Tomazos]

I'll admit that I've only made a superficial visit

How about making a non-superficial visit before drowning us further in
your ignorance?

You seem to have plenty of time to write 20 posts of drivel per day,
but you don't have 30 seconds to review clear evidence.

I can tell by what you said about TopCoder that you have no experience
with it, or a programming competition like it.

Here, I will spoon feed you:
1. Go to TopCoder.com
2. Sign up
3. Go to COMPETE > MARATHON MATCHES
4. Go to STATISTICS > MATCH ARCHIVE
5. Pick a recent competition.
6. Click around until you find:
- the detailed problem statement
- the test cases
- the precise scoring system
- exact specification of the system on which the code is run
- the final leaderboard
- the code from each of the submissions

Come back when you have an *informed* opinion to share. Everything
you said about it was laughable.
-Andrew.