Re: dealing with lower level programmers
On Jul 17, 11:35 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
James Kanze <james.ka...@gmail.com> writes:
On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Jul 15, 1:24 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
[...]
There are good programmers everywhere. The choice is
between a good programmer here, where you can manage him
well, and a good programmer elsewhere, where you can't
manage him, so he can't perform.
I don't get that. I've worked for clients on the other side of
the world and we'd both say that they had no trouble managing
me (not that they had to) and that I performed well.
Were you working alone, or in a group?
Alone too.
If alone, how did you do code reviews, or brainstorming
sessions.
Group work is not a guarantee of implementing code reviews.
Working along is a guarantee that they aren't implemented,
however.
Basically, you can do code reviews alone, by just forgetting
your code, and then reviewing it.
I do that too, when I have to work alone. It's still far from
being as effective as having other people do the review.
There's also all of the ad hoc discussions that occur (or should
occur) when you're working in a team. You discuss what you're
doing with someone else at the coffee machine, and he points out
a potential problem. That you then fix, before formel review.
Good programming is a team effort
AFAICSITRL, this is completely wrong. Team programming leads
to huge quasi unmaintenable, bug-ridden programs that nobody
can understand completely, and that work only by miracle (and
thanks to encapsulation).
No doubt that's why all of the companies implementing critical
systems insist on team programming, and why it is required in
such cases.
Mostly, where there's something wrong in a program by one, the
one will pause and correct the wrong thing. When there's
something wrong in a program by many, there is a lot of red
tape, and group psychology to overcome before being able to
correct it. In practice most problems in team programs never
get corrected, just wrapped over as far as there's a customer
crying for a bug correction.
That's just bullshit. Mostly, programmers are human beings, and
as such, imperfect. They all make mistakes. And they don't see
their own mistakes---that takes someone else.
a single individual is incapable of writing a correct program,
regardless of how skilled he is.
This is obviously wrong, there are several example.
Such as?
What may be true is that the scope and size of a program
written by an individual might be smaller, but how would that
be a bad thing? At least an individual will produce programs
that are understandable and manageable.
And team efforts mean collaboration and communication, which in turn
requires face to face communication.
"Mythical Man Month".
Irrelevant here. You're not adding additional people (beyond
the optimal) in the middle of a project, to hopefully make the
project go faster.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34