Hackers and Painters

****

****

| May 2003(This essay is derived from a guest lecture at Harvard, which incorporated
an earlier talk at Northeastern.)When I finished grad school in computer science I went
to art school to study painting. A lot of people seemed surprised
that someone interested in computers would also be interested in painting.
They seemed to think that
hacking and painting were very different kinds of work-- that
hacking was cold, precise, and methodical, and that
painting was the frenzied expression of some primal urge.Both of these images are wrong. Hacking and painting have a
lot in common. In fact, of all the different types of people I've
known, hackers and painters are among the most alike.What hackers and painters have in common is that they're
both makers. Along with composers, architects, and writers,
what hackers and painters are trying to do is make good things.
They're not doing research per se, though if in the course of
trying to make good things they discover some new technique,
so much the better.I've never liked the term "computer science." The main
reason I don't like it is that there's no such thing.
Computer science is a
grab bag of tenuously related areas thrown together
by an accident of history, like Yugoslavia.
At one end you have people who are really mathematicians,
but call what they're doing computer science so they can get DARPA grants.
In the middle you have people working on
something like the natural history of computers-- studying the
behavior of algorithms for routing data through
networks, for example. And then at the other extreme you
have the hackers, who are trying to
write interesting software, and for whom computers are just a
medium of expression, as concrete is for architects or
paint for painters. It's as if
mathematicians, physicists, and architects all had to be in
the same department.Sometimes what the hackers do is called "software engineering,"
but this term is just as misleading.
Good software designers are no more engineers than architects are.
The border between architecture and engineering is not sharply
defined, but it's there.
It falls between what and how: architects decide what to do,
and engineers figure out how to do it.What and how should not be kept too separate. You're
asking for trouble if you try to decide what to do without
understanding how to do it.
But hacking can certainly be more than just deciding how to
implement some spec. At its best, it's creating the spec-- though
it turns out the best way to do that is to implement it.Perhaps one day
"computer science" will, like Yugoslavia, get broken up into its
component parts. That might be a good thing. Especially if it
meant independence for my native land, hacking.Bundling all these different types of work together in one
department may be convenient administratively, but it's confusing
intellectually. That's the other reason I don't like the name
"computer science." Arguably the people in the middle are doing
something like an experimental science. But the people at either
end, the hackers and the mathematicians, are not actually doing science.The mathematicians don't seem bothered by this. They happily
set to work proving theorems like the other mathematicians
over in the math department, and probably soon stop noticing
that the building they work in says computer science'' on the
outside. But for the hackers this label is a problem.
If what they're doing is called science, it makes them feel they
ought to be acting scientific.
So instead of doing what they really want to do, which is
to design beautiful software, hackers in universities and
research labs feel they ought to be writing research papers.In the best case, the papers are just a formality. Hackers write
cool software, and then write a paper about it, and the paper
becomes a proxy for the achievement represented by the software.
But often this mismatch causes problems. It's easy to
drift away from building beautiful things toward building ugly
things that make more suitable subjects for research papers.Unfortunately, beautiful things don't always make the
best subjects for papers.
Number one, research must be original-- and
as anyone who has written a PhD dissertation knows, the way to
be sure that you're exploring virgin territory is to stake
out a piece of ground that no one wants. Number two, research must be
substantial-- and awkward systems yield meatier papers,
because you can write about the obstacles you have to overcome
in order to get things done. Nothing yields meaty problems like
starting with the wrong assumptions. Most of AI is an example
of this rule; if you assume that knowledge can be represented
as a list of predicate logic expressions whose arguments represent
abstract concepts, you'll have a lot of
papers to write about how to make this work. As Ricky Ricardo
used to say, "Lucy, you got a lot of explaining to do."The way to create something beautiful is often to make subtle
tweaks to something that already exists, or to combine existing
ideas in a slightly new way. This kind of work is hard to
convey in a research paper.So why do universities and research labs continue to judge
hackers by publications?
For the same reason that "scholastic aptitude"
gets measured by simple-minded standardized tests, or
the productivity of programmers gets measured in lines of code.
These tests
are easy to apply, and there is nothing so tempting as an easy test
that kind of works.Measuring what hackers are actually trying to do, designing
beautiful software, would be much more difficult. You need
a good sense of design to judge
good design. And
there is no correlation, except possibly
a negative
one, between people's ability to recognize good
design and their confidence that they can.The only external test is time. Over time, beautiful
things tend to thrive, and ugly
things tend to get discarded. Unfortunately, the amounts of time
involved can be longer than human lifetimes. Samuel Johnson
said it took a hundred years for a writer's reputation to
converge. You have to wait for the writer's
influential friends to die, and then for all their followers
to die.I think hackers just have to resign themselves to having a large random
component in their reputations. In this they are no different
from other makers. In fact, they're lucky by comparison.
The influence of fashion is not nearly so great in hacking as it
is in painting.There are worse things than having people misunderstand your
work. A worse danger is that you
will yourself misunderstand your work. Related fields are
where you go looking for ideas. If you find yourself in the computer science
department, there is a natural temptation to believe, for example,
that hacking is the applied version of what theoretical computer
science is the theory of. All
the time I was in graduate school I had an uncomfortable feeling
in the back of my mind that I ought to know more theory,
and that it was very remiss of me to have forgotten all that
stuff within three weeks of the final exam.Now I realize I was
mistaken. Hackers need to understand the theory of computation
about as much as painters need to understand paint chemistry.
You need to know how to calculate time and
space complexity and about
Turing completeness. You might also want to remember at
least the concept of a state machine, in case you have to write
a parser or a regular expression library. Painters in fact
have to remember a good deal more about paint chemistry than
that.I've found that the best sources of ideas
are not the other fields that have the word "computer" in
their names, but the other fields inhabited by makers.
Painting has been a much richer source of ideas than the
theory of computation.For example, I was taught in college
that one ought to figure out a program
completely on paper
before even going near a computer. I found that I did not
program this way. I found that I liked to program

[...]

Original source