Python's popularity statistics

[Laura Creighton]

> I was fortunate early in my career to be working with the equivalent
> of an Alex, and it was a heady experience. Very productive. In my
> pair-programming experience, though, I've come to believe you really
> need an unbalanced pair like that; it gives the less-skilled member a
> chance to contribute by keying (and occasionally catching fuzzy
> thinking) and frees up the more-skilled member for on-the-fly
> designing. A more balanced pair tends to develop into a "fine! we'll
> do it your way!" affair with shouting and sulking. I'd be interested
> in hearing how that compares with others' experience.
> 
> --
> rzed

You have a problem in your process.  These pairs are utterly too ego
driven, and wrapped up in their own code.  This can come from many reasons.

1.  How many hours a week are you working on code?  If it is more than
    40, and this is not a one-time-emergency, then that is WAY TOO MUCH
    for something like 85% of the planet.  (All 15% who can do it fine
    are regular c.l.py readers, I know ... grin)  You make ego-driven
    mistakes when you are tired, and if you are tired all the time it's
    a bad situation.  Plus you know you aren't doing your best work 
    because you are tired, and that makes you even more grumpy.

2.  Why can't you build a test case and try it one way or another?  This
    is Python, after all, and so it is frequently faster to test it.  Lots
    of hell can be avoided if you are willing to give up 'Proof by
    General Principles' for 'Proof by experimentation'.  And you must
    absolutely, totally, utterly irradicate 'Proof because I am such
    a smart bastard'.

3.  The human race has invented all sorts of Beautiful Lies which are
    Really Good to believe in.  Truth -- Justice -- nice things like that.
    It is a good thing to believe in these as true, even though there is
    no perfect Justice on the planet, and unfairness exists.  I would
    like to attempt to teach you all another one.

    'Nobody is better than anybody else.'

    Thus one can say, perfectly correctly, 'Alex Martelli is a better
    Python programmer than Laura Creighton is', but that does not ever
    imply that Alex is a better person than I am.  Alex is not 'better'
    than I -- and what is more important, nothing that Alex can ever
    do will _ever_ make him better than I.  Now, the flip-side of this
    is that nothing that I will do will ever make me better than Alex
    Martelli.  This is a complete, utterly dead, no-posibility of reviving,
    X-parrot (er concept).

    If everybody is committed to this concept, then relations with your
    co workers are a lot more harmonious.

    Please try it and let me know how it goes for you.  If you have problems
    with it, let me know, I have lots of experience getting this to work and
    believe I have seen most of the ways this can screw up.  So, either I
    will know a fix, or I will learn a new way to ruin things, and we will
    all prosper in any case.

Thanks very much for listening,
Laura Creighton