[OT] dealing with lower level programmers

[Alf P. Steinbach]

* Andrew Tomazos:

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

Some heat detected ... ;-)

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.

Heh.

Let's not devolve further to the stage of putting names and derogatory terms in
the subject line.

But yeah, some of those guys 'n gals are *very* good, very very smart, but the
code they write at competition is generally (at least what I've seen of it)
unmaintainable, using cryptic shortname macros to generate loops and so on.

It seems that the number of characters to type is a main factor in such
competitions, so to do well I think one must practice that macro usage.

Of course one must also be smart enough to solve the problems, and ideally be
free of distractions.



Cheers,

- Alf

 

[Ian Collins]

A long time ago. But that's not really the point. The most
important aspects of CMMI address a higher level---not so much
what to do, but how to decide what to do. Thus, CMMI doesn't so
much say that you have to use code reviews instead of pair
programming, but rather specifies criteria by which you can make
such a choice. Some aspects of agile programming can probably
be adopted into any process; some may even improve it (depending
on the rest of the process). But you don't adopt them because
they've been sold as agile; you adopt them as part of a larger
process, because they result in a measurable improvement in your
productivity.

What I miss in the agile programming literature is this
measuraable. There are a lot of claims, but they all seem to be
comparing with using no process at all, and they all seem to be
more feeling than actual measurement.

You're probably correct there. Getting reliable comparisons between any
two processes is an expensive task. The only real way to do it is to do
a project twice in parallel, once with each process.

 

[Brian Wood]

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've been reading Kanze's posts for years and would hardly
describe them as drivel. His posts are generally thoughtful
and sometimes insightful.


Brian Wood
www.webEbenezer.net

 

[Andrew Tomazos]

But yeah, some of those guys 'n gals are *very* good, very very smart, but the
code they write at competition is generally (at least what I've seen of it)
unmaintainable, using cryptic shortname macros to generate loops and so on.

Yes, I'm not suggesting that the code written for a competition is the
same as that written for production. There are many factors not
tested. I do however contend that there is a *significant*
correlation between general programming ability and scoring ability at
those sort of competitions. If we accept that assertion, than we can
see hard evidence of the 100x factor. In any case I ask the reader to
compare the submitted code, and make their own judgements.
-Andrew.

 

[James Kanze]

"James Kanze" <[email protected]>

[...]

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.

And that is simply not true. Every C++ programmer I've ever met
knows to initialize variables at the point of declaration, and
does so. Every coding guideline I've met requires this.

I don't know where this idea comes from that "average"
programmers are all idiots, and that there are just a few
"super-programmers" out there who know what they are doing.
Most professional are just that: professional. And they do a
pretty good job.

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.

Exactly. That's why we have code reviews---so that someone
"outside" can read the code. But that's true for everyone, from
the raw beginner to the top expert.

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.

Average or expert, the programmers keep the functions small
enough that keeping everything in one's head for the entire
function is not a problem.

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.

And that's just wrong. I've worked with a number of big
organizations (Siemens, Alcatel, T Mobile...), and I've never
found a service filled up with completely ignorant people.

Having that genuine drive to do the job WELL and paying
attention is in itself a trait in the above-average club.

The genuine drive is a result of management, not of the
individual.

Yes, and they appear pretty rare.

It varies, but they seem a lot less rare now than, say 20 years
ago. It takes time, but management is learning how to manage
software development.

Err, and what is "no"?

There's no visible sweat in staying late.

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.

In one of Suter's articles, it was just the opposite. The boss
took staying late as a sign that the person didn't know how to
manage his time. It varies. But whatever... bad management
certainly exists, and while it isn't as omnipresent as it used
to be, most places could still do with some improvement.

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.

I'm familiar with it. There was a time it was more or less true
in a lot of places. That's a lot less frequent today than when
it was written.

 

[James Kanze]

[ ... ]

- 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.

Alternatively, you initialize in the definition (which is, of
course, what the constructor does). Every coding guideline I've
seen requires this, and I've rarely seen code which doesn't do
it.

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.

It depends on the level. There's always something you have to
keep in your head, if only when moving your eyes down three
lines from the declaration. In well written ("good") code,
there's no place where there's very much, and it's all obvious
with a quick glance at the function.

 

[James Kanze]

* Andrew Tomazos:

Some heat detected ... ;-)

When you don't have any real arguments. The site is certainly
not anything a professional would use.

[...]

But yeah, some of those guys 'n gals are *very* good, very
very smart, but the code they write at competition is
generally (at least what I've seen of it) unmaintainable,
using cryptic shortname macros to generate loops and so on.

The requirements for winning some prize are different than the
requirements for professional work.

It seems that the number of characters to type is a main
factor in such competitions, so to do well I think one must
practice that macro usage.

Of course one must also be smart enough to solve the problems,
and ideally be free of distractions.

And be motivated to do work for almost nothing.

 

[Andrew Tomazos]

When you don't have any real arguments.  The site is certainly
not anything a professional would use.

Why not?

The requirements for winning some prize are different than the
requirements for professional work.

There is a strong correlation. Strong enough to demonstrate the
spectrum of programming ability.

And be motivated to do work for almost nothing.

What the hell are you talking about?
-Andrew.

 

[Ian Collins]

There is a strong correlation. Strong enough to demonstrate the
spectrum of programming ability.

How strong? Where has this been documented?

What the hell are you talking about?

The prizes on offer don't justify the effort required to win them.

 

[Jerry Coffin]

[ ... ]

It depends on the level. There's always something you have to
keep in your head, if only when moving your eyes down three
lines from the declaration. In well written ("good") code,
there's no place where there's very much, and it's all obvious
with a quick glance at the function.

Well, yes. The people who study such things claim most people's
short-term memory is good for 5 items, plus or minus three. I'm not
sure there's much point in trying to limit yourself to 2, but I'd be
extremely wary of going much beyond 6 or so if there's any reasonable
way to avoid it...

 

[Andrew Tomazos]

How strong?  Where has this been documented?

Yeah, okay. I mean that in my judgment and experience I would expect
a fairly strong correlation - however I leave it to the reader to look
at the details and make their own assessment.

The prizes on offer don't justify the effort required to win them.

My comments are isolated to the marathon matches, of which I doubt the
resulting code is put into production. I'm not sure the motivation to
compete in a programming competition is created by the prizes. It is
a game in a way. A test of skill with hard scores. It's easy to say
programmer X is better than programmer Y - but provided you accept the
correlation with "real" programming - this is a way that programming
ability can be empirically proven and compared.
-Andrew.

 

[Balog Pal]

"Andrew Tomazos"
My comments are isolated to the marathon matches, of which I doubt the
resulting code is put into production. I'm not sure the motivation to
compete in a programming competition is created by the prizes. It is
a game in a way. A test of skill with hard scores. It's easy to say
programmer X is better than programmer Y - but provided you accept the
correlation with "real" programming - this is a way that programming
ability can be empirically proven and compared.
<<

And if you want a guy to carry heavy stuff around (or move your household),
you certainly will get the best results with the weighlifting champ... :-o

 

[Noah Roberts]

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

*plonk*

I'm afraid to flush...a pile this big might get stuck.

 

[Noah Roberts]

Yes, I'm not suggesting that the code written for a competition is the
same as that written for production. There are many factors not
tested. I do however contend that there is a *significant*
correlation between general programming ability and scoring ability at
those sort of competitions.

I'm not so sure. I've seen too much code that is unmaintainable because
it was given to some lone wolf who could supposedly achieve the
impossible: a complex product delivered in simple product time. Whole
slews of code that nobody wants to even look at because all the triple
indirections and casting hacks make them dizzy.

 

[Noah Roberts]

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.

Yeah, and part of being a "bad" programmer is being too damn stubborn.
It's actually easier to get graduates to create nice code than some
"experts". One example: I had the misfortune of working under someone
who insisted exceptions slow down code too much and that the standard
library should not be used. Sure, he had years more experience working
than I did but boy was it a PITA to write decent code under THAT guy's
perview.

So you can have the opposite problem too.

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.

Actually, I'd only consider him better if he was able to write it in a
week because he's already got all he needs in libraries that are all
unit tested and proved out in other products....all he has to do is tie
it together nicely. That's kind of my job though: managing the products.

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

Perhaps, but still...a developer that is self-motivating is better than
one which needs to be pushed all the time. The former will go further
with less push than the later.

One of the things I look for in college recruits is that they interned
somewhere. Too many don't...they just do the work they're required to
do for class and that's it. No going out to get more. IMO someone that
graduated without interning isn't usually worth even interviewing.

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

Not what I'm talking about actually. I'm talking about the difference
between someone who is interested in programming vs. someone that
couldn't care less and just wants to get by.

 

[tomazos]

I do however contend that there is a *significant*
correlation between general programming ability and scoring ability at
those sort of competitions.

I'm not so sure.

Did you take a look at the submitted code as I suggested before making
this judgement? Did you compare the winning entry with an average
scoring one?
-Andrew.

 

[James Kanze]

James Kanze wrote:

[...]

Perhaps, but still...a developer that is self-motivating is
better than one which needs to be pushed all the time. The
former will go further with less push than the later.

I don't think it's a black and white situation. In my
experience, the vast majority of programmers are willing to
learn, and to keep up to date. They don't always realize that
it's necessary, or know how to do it, though. This is where
management comes in---it creates the atmosphere which encourages
such learning, and provides the means to do it. It can often be
things as simple as promoting or giving a bonus to someone who
has made the extra effort to learn something new, or providing
the necessary information (books, etc.) where it is easily
accessible to all, and encouraging people to use it *on*
*company* *time*. (Given the speed our field evolves, I would
expect close to a fourth of all time to be spend in further
learning. Two hours a day, in an eight hour day. One of the
management problems I often see is that management expects all
eight hours to be booked to some specific project---it should
insist that at least two hours be booked to further training.)

One of the things I look for in college recruits is that they
interned somewhere. Too many don't...they just do the work
they're required to do for class and that's it. No going out
to get more. IMO someone that graduated without interning
isn't usually worth even interviewing.

I've run into that once or twice---one person once told me that
he'd just finished five years of only learning, and now that he
was out of college, he didn't want to learn any more. But in my
experience, such people seem to be the exceptions. On the other
hand, when management insists that all time be booked to some
project, and frowns on it when you read a technical book in the
office, a lot of people won't make the additional effort to keep
up to date in their own time.

[...]

Not what I'm talking about actually. I'm talking about the
difference between someone who is interested in programming
vs. someone that couldn't care less and just wants to get by.

In my experience, most programmers are interested in
programming. But not only in programming---they have families,
and other interests as well. And 35-40 hours a week is already
a lot of time to spend on any one area of interest. It's up to
management to ensure that they can read about new technologies
and experiment in that 35-40 hours.

 

[Gerhard Fiedler]

The suggestion as no more ridiculous that the original claim!

What's ridiculous?

 

[Ian Collins]

What's ridiculous?

I thought this thread was done!

The original claim in my first paragraph.