On Wed, Jan 30, 2002 at 02:22:33PM -0600, David W. Tamkin wrote:
Cliff Sarginson has joined the thread:
| I have known dozens of brilliant "C" programmers who could hardly mumble
| coherently let alone write coherently.
OK, they wrote very good code, but how good were they at reading other
Good for the most part. Although reading code is in many ways a
different skill to writing it, I would not call a programmer a good
one unless he has obviously mastered bith skills.
How good were they at finding non-obvious quirks of
others' code -- bad things that looked good and good things that, as is
typical of procmail's source, looked bad?
Well, this is quite a complex question. If someone writes a program in
such an opaque way that it is hard to see that what they are doing is
"good", when it looks "bad", then they are not communicating their
intent in the code itself in a sufficient or professional way. I believe
someone else said in this thread that procmail appeared to have a
cavalier attitude to "malloc", on further investigation it turns out
that the code has an internal implementation of "malloc" (if I read the
email correctly). Well this is fine, but why call it "malloc" .. that is
bad. In a code review I would throw that back at the author and tell him
to make it clear by using a different name. Now for code that people
write and freely allow others to use, maybe we cannot complain. However
if it was code written for a commercial project, paid for and supported,
then it would be completely unacceptable.
And how good were they at
communicating what they found in other programmers' code -- apparently they
sucked at that part.
When you tried to tell or ask them something, how well did they understand a
simple question or comment? What about complex ones? Did you have to keep
re-explaining what you were saying while they continued to give responses
that missed the point if any responses at all?
Generally speaking this was not a problem. The problem was they could
not write coherently.
It boils down to this: how well did they process thoughts that didn't come
from inside their own minds?
Well, again, because these people had difficulty with written
communication it didn't necessarily mean they couldn't read, listen and
speak ! Good programmers need to know how to listen.
At least those people mumbled; this ranter shouted, bellowed, and
Oh I am not defending him, or even saying he is right or wrong, I have
not read the code. I am just trying to make the point that coherence in
a natural language does not always bear any relationship to coherence in
an artifical one. One particular programmer I worked with, easily in my
top 5, was a very shy person, very self-deprecating, and a very poor
communicator in the spoken and written word. His code was a model of
clarity, was efficient without being opaque, was well commented (he
could write well in the context of a program) and was work in an
extremely complex area of a system we were writing for a very large
bank. When he became fed up with the company and resigned the boss
practically went down on his knees asking him to stay. Later I had to
add some functionality into the programs he had written, and I was not
an expert in the field, it was a task made a great deal simpler by the
crystal clearness of his code.
| Likewise I have known dozens of
| very poor programmers who were extremely coherent (which is probably how
| they managed to keep their jobs).
I know thousands of people who are very poor programmers but who keep their
jobs because they earn their livings at something other than programming.
Mmm, well I am not sure what that has to do with what we are
Mmm, I have a lot of criticisms of procmail, but this is not really a
very useful place for me to mention them. They are nothing to do with
the coding style (as I say I haven't read the code). I will remember
however that if I do critcise anything about it, I will try and present
it in a coherent, non-ranting way :)
I am just here for the tips...
procmail mailing list