OT: Crazy Programming

[Alex Martelli]

Max M wrote:

>> Imagine two painters.  One spends half his time at arts supplies stores,
>> checking out the tiniest differences between different models of
>> brushes, different brands of paint, canvases prepared with minutely
>> distinct processes yielding minute roughness and absorption differences,
        ...
> So there really is a lot of craftsmanship in writing good code.

There can be -- as there can be in painting.  But given a finite amount
of time and energy to spend on all kinds of issues altogether, what IS
the allocation of these "scarce resources" that's likely to have the
higher overall returns -- spend more time/energy on worrying about what
kind of brush is fractionally better, or on what to portray and how?

The overall cultural bias of today is towards "gadget-o-mania" -- the
quest for the Silver Bullet, the gadget / trick / technology / toy that
will solve every problem.  And, sure, the technology does matter, A
BIT.  A good golfer uses good clubs, a good runner good shoes, a good
bridge player a good bidding system, a good "human networker" uses a
good mobile phone, a good coder uses good idioms of his or her chosen
programming language.  But it's easier to overdo the attention to such
tool-level details, than to make the opposite mistake.  I've seen too
many bridge players worrying to death about a pluperfect bidding system
rather than choosing a solid, sensible one, and focusing on using it
effectively in real life, which is in fact a far more important task.
Golfers tell me the same about their ilk, runners about theirs, etc --
and again from personal observation the same phenomenon is amply in
evidence in programming, too.

I sympathize -- the tools-level part is just SO interesting and fun,
I, myself, would be quite prone to spend all my bridge-available time
and energy on bidding-system issues, all my programming-available
time on clever idioms, classes, extensions &c, and so on, and so forth.

Exactly *because* overdoing the tools-level concerns is by far the
likelier trap, Python's culture, that de-emphasizes them in favour
of real design and architecture issues, is such a boon to most of
its practitioners.  *Do the simplest thing that can possibly work*.


Alex