[linux-elitists] Re: Yet another mozilla atrocity

Martin Pool mbp@samba.org
Mon Oct 13 18:48:45 PDT 2003

On 10 Oct 2003, "Karsten M. Self" <kmself@ix.netcom.com> wrote:
> on Thu, Oct 09, 2003 at 10:16:56AM -0400, Justin F. Knotzke (jknotzke@shampoo.ca) wrote:
> > <quote who=Karsten M. Self date=[031009 06:47]/>
> > 
> > > > One of several smart things Havoc said is 
> > > > 
> > > >   If you don't know how to code, then you don't know how to design the
> > > >   software either. Period. You can only cause trouble.
> > > 
> > > Bogus.  Adequately discussed elsewhere.
> > 
> > I'm not entirely sure it's that Bogus.
>     See:
>     http://zgp.org/pipermail/linux-elitists/2003-October/007663.html
>     Starting "I've worked on both sides of this divide".

In which you wrote:

    As a SAS programmer, I'm often working with clinical experts or
    statisticians who have very specific domain knowledge, but can't
    implement the concepts in the coding language, or can't create a
    generalized implementation.

> The discriminator isn't ability or inability to code.  It's ability or
> inability to contribute.

So there is a spectrum, and we are trying to work out a reasonable

(Of course there is no actual line; people just decide in each
instance whether the would-be contributor knows what they're talking

So in things like your SAS example, the other person knows about the
problem domain, and about statistics.  Down at that end of the
spectrum, they're solid.  When it comes to the details of SAS syntax
and semantics, it's probably all down to you.

Sometimes in this situation the domain expert for some reason gets a
really strong but wrong opinion about a technical issue.  Sometimes
it's based on patterns they've observed in using the system, but
because they don't really understand how it works, they don't
understand why it won't work in this case.  Of course sometimes the
user is either right, or bumps the programmer into thinking of the
right thing.

This can be pretty frustrating for both parties.  The programmer can
say "no, that's not right, just trust me", but that sounds patronizing
or elitist.  Or, the programmer can try to explain what's really
happening, but sometimes the idea is so fixed that it can't be
dislodged.  If the person doesn't have enough context you can get
"it's not even wrong" situations.  Or the programmer can just go ahead
and humor them, but sometimes that would take so much time as to be

I don't know, maybe you have a better way of handling this?

If the user starts ranting about censorship or the programmer about
lusers it rapidly goes downhill.

Saying that you must know how to use the tools to design software is a
decent rule of thumb for placing that line, if not always perfect.
Most of the detailed designs proposed by non-programmers are pretty
bad; your example of collision recovery is one such.  By "design" I
mean technical design.  Anyone may express an opinion on
documentation, user interface, etc.

In fact, anyone can express an opinion on anything, but unqualified
opinions tend to get filtered out.


More information about the linux-elitists mailing list