It could be the way I do things, but competitions or victory
against others
had never interested me in any sphere of life, including
programming. I
definitely like the act of creation. Creating something that can be a
complete application that someone could potentially use in real
life is
important even when I'm learning a language.
I also know several excellent programmers who enjoy awards and the
thrill
of success from being the best even if it means working on artificial
problems.
Thanks, Cheeni ... I think you've illuminated the concept I had been
trying to find: creation under constraints[0].
I'm probably more like you than like the HackerRank core market:
although I enjoy competitive contact sports away from the keyboard,
at the keyboard the only "competitions" I engage in are informal and
among friends, in which (often over periods of months to years) we
explore variations on a problem, slowly converging on extremes[*] of
time or space or expression. (if they involved more improvisation
than composition, "jams" would be a better word)
Not being a boxer, I don't know if the recent popularity of "non-
contact boxing" (perhaps a fad, but currently much larger than the
traditional market) is due to a dislike of antagonistic competition
or to a simple dislike of getting hit.
If we view creativity as finding solutions where constraints mean
they are rare, antagonistic competition provides some very strong
constraints: the simplest things become difficult, when if one is
attempting to do them at the same that someone else is attempting to
do exactly the opposite. These kinds of constraints privilege
improvisation: the successful player can execute a small number of
"known good" actions in any situation (the equilibrium is a small
number because multiplying the choices increases decision latency,
but having only one choice allows the opponent to anticipate[1]).
However, the emphasis on improvisation also tends to an emphasis on
"artificial problems": programming competitions seem to me to have
the same relation to industrial programming that bouldering does to
big wall climbs, and police officers studying martial arts have
remarked that would be difficult to create a more artificial scenario
than the typical sparring format: one-on-one starting with both
participants alert and facing each other.
Creating useful applications is a different form of imposing
constraints. And programmers, like the mathematician Piet Hein, who
said "problems worthy of attack / prove their worth by hitting back",
enjoy the advantage over boxers that they can easily pressure
themselves without any antagonistic interaction. Someone once said
"if you fail, the remedy is easy: try to improve; if you succeed, the
remedy is easy ... you solved the wrong problem: try to improve", and
for engineers (here: anyone who believes they are "someone who can do
for a dime what any fool can do for a dollar") there is a strong
temptation to redefine every problem until it is difficult enough to
become interesting. These constraints are more compositional than
improvisational: one goes back to the drawing board time after time,
and often finds a simple, elegant solution, only after improving a
large variety[2] of complex, crufty ones.
I currently believe the sort of people who shun competition, but who
don't mind getting hit, are the autodidacts who will seek out such
problems on their own, which leaves people who don't want to get hit
as the volume market for programming clinics. (The boxers are
addressing their equivalent market, and I know several people with
HEMA clubs who have also noticed that their sparring members are, in
effect, subsidized by the larger numbers of people who like to swing
swords around in a large group once a week, but for whom the idea of
testing how well they can execute, under pressure, the skills they
are supposedly learning, has absolutely no attraction.)
Sorry it's taken me this long to set up, but these models suggest a
few ways one might attempt to make "casual programming" more
attractive, by relaxing the normal constraints:
- give people a surplus of resources, so just about anything they
create works[3] (the "flower arranging"/"spirograph" approach)
- give people resources that don't combine well, so they can build a
few pretty things but not much else (the "modern lego kit" approach)
- in normal programming, choice is "demonic": one's program needs to
avoid messing up for any situation the environment can throw at it;
if one offered an "angelic" environment, which only offered
situations in which the program as written could possibly succeed,
the job is made much easier. (the "slow pitch softball" approach)
- a judicious selection of exercises and incremental test cases
would aid the beginner by strongly hinting at the best next step (the
"paint by numbers" approach)
- alternatively, someone who put a lot of effort into creating
"commonly failing" test cases might couple them with explicit hints
for probable fixes (the "programmed instruction" approach)
- instead of asking for complete programs, concentrate on "what is
the next edit" puzzles (the "newspaper chess problem"/"shallow bug"
approach)
- what else?
-Dave
[0] cf https://psych.princeton.edu/psychology/research/johnson_laird/
pdfs/1988freedomandconstraint.pdf
[*] as mentioned by http://www.economist.com/blogs/gametheory/2011/09/
marketing-action-sports most of these extremes are not things you
would do every day, if at all, but it can be inspiring to know they
are possible.
[1] There was a documentary on the Kendo 8-dan exam, in which it was
stated that former All-Japan champions often have trouble passing.
As an outsider, I suspect this is not at all paradoxical: the person
who was a national champion at 3-dan had been accustomed to beating
his opponents antagonistically, by simply being better and faster
improvisationally; while the examiners at the 8-dan level are looking
for someone who is strong enough to compose the fight, sympathizing
with the opponent enough to set up a situation in which he knows what
the opponent will do next.
[2] Over a decade, Knuth went from taking a week to write an
assembler as a student on a summer job, to saying that a simple one
should take an afternoon. It's been pointed out that part of the
reason for the performance of the V8 engine is that the key
contributors have been doing high-performance virtual machines for a
quarter century or so It's easily possible that they still don't
know the best way to do it, but it's nearly certain they know enough
about the problem space to avoid spending any more time on most of
the really poor ways to do it.
[3] To a large extent, the hardware people have done this for us:
machines today are about 10'000x faster and 10'000x cheaper than in
1960. In absolute terms, much of what they built then doesn't seem
like much to modern eyes, but becomes more impressive as soon as one
realizes how much they got out of such small and slow boxes.
