Re: dealing with lower level programmers
On Jul 17, 11:18 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Jul 16, 12:26 pm, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
[...]
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.
If alone, how did you do code reviews, or brainstorming
sessions.
Acceptance testing and any reviews where done by the clients.
I would take that as a given. But if I were a client, the code
would either pass or fail the review, and if it failed, you
won't be paid. As a client, the reason I pay is to not have to
do all of the work.
Brainstorming sessions where done over the phone.
My experience is that often, the most important "brainstorming
sessions" are the impromptu ones. You cross someone working on
a different component at the coffee machine, and get to talking,
and you end up setting up a brainstorming session.
I'm not saying that with such modern tools as teleconferencing,
it is completely impossible, but I'm very, very sceptical. In
my experience, so much essential communication is impromptu---a
result of discussions with people you meet at the coffee
machine, and not a direct result of concrete planning.
Good programming is a team effort---a single individual is
incapable of writing a correct program, regardless of how
skilled he is.
Maybe, but I've written a lot of programmes for clients
incapable of reviewing the code. "Correct" behaviour can be
determined with sufficient developer and client testing.
Testing can never prove correction; it can only prove that the
code is incorrect. Depending on the application, stricter
proofs may be necessary (in which case, the client will have
someone competent, or employ a competent third party, to
validate them), or the client may simply depend on you to ensure
a certain level of correction.
And team efforts mean collaboration and communication, which
in turn requires face to face communication.
True, but the collaboration and communication doesn't have to
be between programmers. Programmer - client communication is
at least as important as programmer - programmer
communication.
Certainly. And programmer--management communication as well.
Generally, the client--implementer communication will be
somewhat structured, but the programmer--programmer, and to a
degree, the programmer--management, communication entails a
significant amount of impromptu communication (as well as some
structured communication).
--
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