Hackers and Painters

May 2003

Май 2003

(This essay is derived from a guest lecture at Harvard, which incorporated
an earlier talk at Northeastern.)

(Это эссе основано на гостевой лекции в Harvard, в которую вошёл более ранний доклад в 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.

Мне никогда не нравился термин «computer science». Главная причина в том, что такой науки попросту нет. Computer science — это солянка из едва связанных областей, сваленных вместе по исторической случайности, как Югославия. На одном краю — люди, которые по сути математики, но называют свою работу computer science, чтобы получать гранты DARPA. В середине — те, кто занимается чем-то вроде естественной истории компьютеров: например, изучает поведение алгоритмов маршрутизации данных по сетям. А на другом краю — хакеры, которые пытаются писать интересный софт и для которых компьютеры — лишь средство выражения, как бетон для архитектора или краска для художника. Это всё равно что усадить математиков, физиков и архитекторов на одну кафедру.

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.

Иногда то, чем занимаются хакеры, называют «software engineering», но и этот термин не менее обманчив. Хорошие проектировщики ПО — такие же инженеры, как и архитекторы, то есть не инженеры вовсе. Граница между архитектурой и инженерией размыта, но она существует. Она проходит между «что» и «как»: архитекторы решают, что делать, а инженеры придумывают, как это сделать.

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.

Возможно, однажды «computer science», как Югославия, распадётся на составные части. И это могло бы быть к лучшему. Особенно если бы это означало независимость для моей родной земли — хакерства.

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.

Объединять все эти разные виды труда на одной кафедре, может, и удобно административно, но интеллектуально это путает. В этом и вторая причина, по которой мне не нравится название «computer 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.

Математиков это, похоже, не смущает. Они спокойно принимаются доказывать теоремы, как и прочие математики на математической кафедре, и вскоре, наверное, перестают замечать, что на здании, где они работают, снаружи написано «computer science». Но для хакеров эта вывеска — проблема. Если то, чем они занимаются, называют наукой, у них возникает ощущение, что им положено вести себя по-научному. И вместо того чтобы делать то, чего они на самом деле хотят, — проектировать красивый софт, — хакеры в университетах и исследовательских лабораториях чувствуют, что им положено писать научные статьи.

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."

К сожалению, красивые вещи не всегда становятся лучшим предметом для статей. Во-первых, исследование должно быть оригинальным — а как знает всякий, кто писал кандидатскую диссертацию, верный способ убедиться, что осваиваешь нетронутую территорию, — застолбить участок, который никому не нужен. Во-вторых, исследование должно быть основательным — а неуклюжие системы дают более содержательные статьи, потому что можно написать о препятствиях, которые приходится преодолевать, чтобы хоть что-то заработало. Ничто не порождает столь сочных проблем, как старт с неверных предпосылок. Бо́льшая часть AI — пример этого правила: если предположить, что знание можно представить в виде списка выражений логики предикатов, аргументы которых обозначают абстрактные понятия, то у вас будет масса статей о том, как заставить это работать. Как любил говорить Ricky Ricardo: «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.

Единственная внешняя проверка — время. Со временем красивые вещи, как правило, процветают, а уродливые — отбрасываются. К сожалению, речь может идти о промежутках времени длиннее человеческой жизни. Samuel Johnson говорил, что репутации писателя нужно сто лет, чтобы устояться. Приходится ждать, пока умрут влиятельные друзья писателя, а затем — пока умрут все их последователи.

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.

Есть вещи похуже, чем непонимание твоей работы окружающими. Бо́льшая опасность в том, что ты сам неправильно поймёшь свою работу. За идеями ты отправляешься в смежные области. И если ты оказался на кафедре computer science, возникает естественный соблазн поверить, например, что хакерство — это прикладная версия того, чего теоретическая computer science является теорией. Все годы в аспирантуре меня не покидало неуютное ощущение где-то в глубине сознания, что мне следовало бы лучше знать теорию и что с моей стороны было большим упущением забыть всё это в течение трёх недель после выпускного экзамена.

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
sitting in front of a computer, not a piece of paper. Worse
still, instead of patiently writing out a complete program
and assuring myself it was correct, I tended to just spew
out code that was hopelessly broken, and gradually beat it into
shape. Debugging, I was taught, was a kind of final pass where
you caught typos and oversights. The way I worked, it
seemed like programming consisted of debugging.

Например, в колледже меня учили, что программу нужно полностью продумать на бумаге, прежде чем вообще подходить к компьютеру. Я обнаружил, что программирую не так. Я обнаружил, что мне нравится программировать, сидя перед компьютером, а не перед листком бумаги. Хуже того: вместо того чтобы терпеливо выписывать целиком готовую программу и убеждаться в её правильности, я обычно просто вываливал безнадёжно сломанный код и постепенно доводил его до ума. Отладка, как меня учили, — это что-то вроде финального прохода, на котором ловишь опечатки и недосмотры. А судя по тому, как работал я, выходило, что программирование и состоит из отладки.

For a long time I felt bad about this, just as I once
felt bad that I didn't hold my pencil the way they taught me
to in elementary school.
If I had only looked over at
the other makers, the painters or the architects, I would
have realized that there was a name for what I was doing:
sketching. As far as I can tell, the
way they taught me to program in college was all wrong.
You should figure out programs as you're writing them,
just as writers and painters and architects do.

Долгое время я переживал из-за этого — так же, как когда-то переживал, что держу карандаш не так, как учили в начальной школе. Если бы я только взглянул на других создателей — художников или архитекторов, — я бы понял, что у того, чем я занимался, есть название: набросок. Насколько я могу судить, то, как меня учили программировать в колледже, было сплошь неправильно. Программы следует продумывать по ходу их написания — ровно так, как делают писатели, художники и архитекторы.

Realizing this has real implications for software design.
It means that a programming language should, above all, be
malleable. A programming language is for
thinking of
programs, not for expressing programs you've already thought
of. It should be a pencil, not a pen. Static typing would
be a fine idea if people actually did write programs the way
they taught me to in college. But that's not how any of the
hackers I know write programs. We need a language that lets us
scribble and smudge and smear, not a language where you have
to sit with a teacup of types balanced on your knee and make
polite conversation with a strict old aunt of a compiler.

Осознание этого имеет вполне реальные последствия для проектирования ПО. Это означает, что язык программирования должен прежде всего быть податливым. Язык программирования нужен для того, чтобы мыслить программы, а не для того, чтобы выражать программы, которые ты уже придумал. Он должен быть карандашом, а не ручкой. Статическая типизация была бы отличной идеей, если бы люди действительно писали программы так, как меня учили в колледже. Но никто из знакомых мне хакеров так программы не пишет. Нам нужен язык, который позволяет черкать, смазывать и размазывать, а не язык, где приходится сидеть с чашечкой типов, балансирующей на колене, и вести вежливую беседу со строгой пожилой тётушкой-компилятором.

While we're on the subject of static typing, identifying with
the makers will save us from another problem that afflicts
the sciences: math envy. Everyone in the sciences
secretly believes that mathematicians are smarter than they are.
I think mathematicians also believe this. At any rate,
the result is that scientists tend to make their
work look as mathematical as possible. In a field like
physics this probably doesn't do much harm, but the further you
get from the natural sciences, the more of a problem it
becomes.

Раз уж мы заговорили о статической типизации: отождествление себя с создателями избавит нас и от другой беды, поражающей науки, — зависти к математике. Все в науках втайне верят, что математики умнее их. Думаю, и сами математики в это верят. Так или иначе, результат таков, что учёные стремятся придать своей работе как можно более математический вид. В такой области, как физика, это, вероятно, не приносит большого вреда, но чем дальше ты от естественных наук, тем серьёзнее становится проблема.

A page of formulas just looks so impressive.
(Tip: for extra impressiveness, use Greek variables.) And
so there is a great temptation to work on problems you
can treat formally, rather than problems that are, say,
important.

Страница, заполненная формулами, выглядит так внушительно. (Совет: для пущей внушительности используйте греческие переменные.) И вот возникает сильный соблазн работать над задачами, которые можно трактовать формально, а не над задачами, которые, скажем, важны.

If hackers identified with other makers, like writers and
painters, they wouldn't feel tempted to do
this. Writers and painters don't suffer from math envy.
They feel as if they're doing something completely unrelated.
So are hackers, I think.

Если бы хакеры отождествляли себя с другими создателями, такими как писатели и художники, у них не возникало бы такого соблазна. Писатели и художники не страдают от зависти к математике. Им кажется, что они занимаются чем-то совершенно к ней не относящимся. Так же, по-моему, обстоит дело и с хакерами.

If universities and research labs keep hackers from doing
the kind of work they want to do,
perhaps the place for them is in companies.
Unfortunately, most companies won't let hackers do what they
want either. Universities and research labs force hackers
to be scientists, and companies force them to be engineers.

Если университеты и исследовательские лаборатории мешают хакерам заниматься той работой, которой они хотят, то, может быть, их место — в компаниях. К сожалению, большинство компаний тоже не дают хакерам делать то, чего им хочется. Университеты и лаборатории заставляют хакеров быть учёными, а компании — инженерами.

I only discovered this myself quite recently. When Yahoo bought
Viaweb, they asked me what I wanted to do. I had never
liked the business side very much, and said that I just wanted to
hack. When I got to Yahoo, I found that what hacking meant
to them was implementing software, not designing it. Programmers
were seen as technicians who translated the visions (if
that is the word) of product managers into code.

Сам я обнаружил это совсем недавно. Когда Yahoo купила Viaweb, меня спросили, чем я хочу заниматься. Бизнес-сторона мне никогда особо не нравилась, и я сказал, что просто хочу хакать. Придя в Yahoo, я обнаружил, что для них хакерство означало реализацию софта, а не его проектирование. Программистов считали техниками, переводящими в код видения (если это подходящее слово) продакт-менеджеров.

This seems to be the
default plan in big companies. They do it because
it decreases the standard deviation of the outcome.
Only a small percentage of hackers can actually design software,
and it's hard for the
people running a company to pick these out. So instead of
entrusting the future of the software to
one brilliant hacker, most companies set things up so that it is
designed by committee, and the hackers merely
implement the design.

Похоже, это план по умолчанию в больших компаниях. Они так делают, потому что это уменьшает стандартное отклонение результата. Лишь малая доля хакеров действительно способна проектировать софт, а тем, кто руководит компанией, трудно их выявить. Поэтому вместо того чтобы доверить будущее софта одному гениальному хакеру, большинство компаний устраивает всё так, чтобы дизайн делался комитетом, а хакеры лишь реализовывали этот дизайн.

If you want to make money at some point, remember this,
because this is one of the reasons startups win. Big companies want
to decrease the standard deviation of design outcomes because they
want to avoid disasters. But when you damp oscillations, you
lose the high points as well as the low. This is not a problem for
big companies, because they don't win by making great
products. Big companies win by sucking less than other big companies.

Если вы хотите когда-нибудь заработать денег, запомните это, потому что это одна из причин, по которым выигрывают стартапы. Большие компании хотят уменьшить стандартное отклонение результатов дизайна, потому что хотят избежать катастроф. Но когда вы гасите колебания, вы теряете не только низшие точки, но и высшие. Для больших компаний это не проблема, потому что они выигрывают не за счёт создания великих продуктов. Большие компании выигрывают тем, что отстойны меньше других больших компаний.

So if you can figure out a way to get in a
design war with a company big enough that its software is
designed by product managers, they'll never be able to keep up
with you. These opportunities are not easy to find, though.
It's hard to engage a big company in a design war,
just as it's hard to engage an opponent inside a castle in hand
to hand combat. It would be pretty easy to write a better
word processor than Microsoft Word, for example, but Microsoft,
within the castle of their operating system monopoly,
probably wouldn't even notice if you did.

Так что если вы сумеете втянуть в design-войну компанию, достаточно большую для того, чтобы её софт проектировался продакт-менеджерами, она никогда не сможет за вами угнаться. Правда, такие возможности найти непросто. Втянуть большую компанию в design-войну трудно — так же, как трудно сойтись в рукопашной с противником, засевшим в замке. Например, написать текстовый процессор лучше, чем Microsoft Word, было бы довольно легко, но Microsoft, укрывшаяся в замке своей операционно-системной монополии, скорее всего, этого даже не заметит.

The place to fight design wars is in new markets, where no one
has yet managed to establish any fortifications. That's where
you can win big by taking the bold approach to design, and
having the same people both design and implement the product.
Microsoft themselves did this at the start. So did Apple.
And Hewlett-Packard. I suspect almost every successful startup
has.

Место, где надо вести design-войны, — это новые рынки, где ещё никто не успел возвести укреплений. Именно там можно крупно выиграть, взяв смелый подход к дизайну и поручив одним и тем же людям и проектировать, и реализовывать продукт. Сама Microsoft так и поступила на старте. Так же поступила Apple. И Hewlett-Packard. Подозреваю, что так поступал почти каждый успешный стартап.

So one way to build great software is to start your own
startup. There are two problems with this, though. One is
that in a startup you have to do so much besides write software.
At Viaweb I considered myself lucky if I
got to hack a quarter of the time. And the things I had to
do the other three quarters of the time ranged from tedious
to terrifying. I have a benchmark for this, because I
once had to leave a board meeting to have
some cavities filled. I remember sitting back in the
dentist's chair, waiting for the drill, and feeling like
I was on vacation.

Итак, один из способов создавать великое ПО — основать собственный стартап. Однако с этим связаны две проблемы. Первая в том, что в стартапе приходится делать так много всего помимо написания софта. В Viaweb я считал, что мне повезло, если удавалось хакать хотя бы четверть времени. А то, чем мне приходилось заниматься остальные три четверти, варьировалось от занудного до ужасающего. У меня для этого есть эталон: однажды мне пришлось уйти с заседания совета директоров, чтобы запломбировать несколько зубов. Помню, как я откинулся в кресле у стоматолога, ждал бормашины и чувствовал себя как в отпуске.

The other problem with startups is that there is not much
overlap between the kind of software that makes money and the
kind that's interesting to write. Programming languages
are interesting to write, and Microsoft's first product was
one, in fact, but no one will pay for programming languages
now. If you want to make money, you tend to be forced to work
on problems that are too nasty for anyone to solve for free.

Другая проблема со стартапами в том, что есть мало пересечения между тем софтом, который приносит деньги, и тем, который интересно писать. Языки программирования интересно писать, и первым продуктом Microsoft, кстати, был именно язык, но сейчас за языки программирования никто не станет платить. Если хочешь зарабатывать, тебя обычно вынуждают работать над задачами, слишком противными, чтобы кто-то решал их бесплатно.

All makers face this problem. Prices are
determined by supply and demand, and there is just not as much
demand for things that are fun to work on as there is for
things that solve the mundane problems of individual customers.
Acting in off-Broadway plays just doesn't pay as well as
wearing a gorilla suit in someone's booth at a
trade show. Writing novels doesn't pay as well as writing
ad copy for garbage disposals.
And hacking programming languages doesn't pay as well
as figuring out how to connect some company's
legacy database to their Web server.

С этой проблемой сталкиваются все создатели. Цены определяются спросом и предложением, а спрос на то, над чем работать в удовольствие, попросту не так велик, как спрос на то, что решает рутинные проблемы отдельных клиентов. Играть в спектаклях off-Broadway просто платят не так хорошо, как за то, чтобы носить костюм гориллы на чьём-то стенде на торговой выставке. Писать романы платят не так хорошо, как писать рекламные тексты для измельчителей пищевых отходов. А хакать языки программирования платят не так хорошо, как придумывать, как подключить чью-то унаследованную базу данных к их веб-серверу.

I think the answer to this problem, in the case of software,
is a concept known to nearly all makers: the day job.
This phrase began with musicians, who
perform at night. More generally, it means that you have one
kind of work you do for money, and another for love.

Думаю, ответ на эту проблему — по крайней мере применительно к ПО — это понятие, известное почти всем создателям: подработка (day job). Это выражение пошло от музыкантов, которые выступают по ночам. В более общем смысле оно означает, что у тебя есть один вид работы, который ты делаешь ради денег, и другой — ради любви.

Nearly all makers have day jobs early in their careers.
Painters and writers notoriously do. If you're lucky
you can get a day job that's closely
related to your real work. Musicians often
seem to work in record stores. A hacker working on some
programming language or operating system might likewise be able to
get a day job using it. [1]

Почти у всех создателей в начале карьеры есть подработка. Художники и писатели — это общеизвестно. Если повезёт, можно найти подработку, тесно связанную с твоим настоящим делом. Музыканты, похоже, часто работают в музыкальных магазинах. Хакер, работающий над каким-нибудь языком программирования или операционной системой, точно так же может найти подработку, где этим пользуются. [1]

When I say that the answer is for hackers to have day jobs,
and work on beautiful software on the side, I'm not proposing
this as a new idea. This is what open-source hacking is all
about. What I'm saying is that open-source is probably the right
model, because it has been independently confirmed by all the
other makers.

Когда я говорю, что ответ для хакеров — иметь подработку, а над красивым софтом работать на стороне, я не выдаю это за новую идею. Именно в этом и состоит весь смысл open-source-хакерства. Я лишь говорю, что open-source — вероятно, правильная модель, потому что её независимо подтвердили все остальные создатели.

It seems surprising to me that any employer would be reluctant
to let hackers work on open-source projects.
At Viaweb, we would have been reluctant to hire anyone
who didn't. When we interviewed
programmers, the main
thing we cared about was what kind of software they
wrote in their spare time.
You can't do anything really well unless
you love it, and if you love to hack you'll inevitably
be working on projects of your own. [2]

Мне кажется удивительным, что какой-нибудь работодатель может неохотно отпускать хакеров работать над open-source-проектами. В Viaweb мы бы неохотно брали на работу того, кто этого не делает. Когда мы собеседовали программистов, главное, что нас интересовало, — какой софт они пишут в свободное время. Нельзя сделать что-то по-настоящему хорошо, если ты этого не любишь, а если ты любишь хакать, ты неизбежно будешь работать над собственными проектами. [2]

Because hackers are makers rather than scientists,
the right place to look for metaphors is not in the
sciences, but among other kinds of makers. What else can painting
teach us about hacking?

Поскольку хакеры — создатели, а не учёные, искать метафоры стоит не в науках, а среди других видов создателей. Чему ещё живопись может научить нас в хакерстве?

One thing we can learn, or at least confirm, from the
example of painting is how to learn to hack. You learn to
paint mostly by doing it.
Ditto for hacking. Most hackers don't learn to hack by
taking college courses in programming. They learn to hack
by writing programs of their own at age thirteen. Even in
college classes, you learn to hack mostly by hacking. [3]

Одно, чему мы можем научиться — или хотя бы что подтвердить — на примере живописи, это то, как учиться хакать. Живописи учатся в основном через саму живопись. То же и с хакерством. Большинство хакеров учатся хакать не на курсах программирования в колледже. Они учатся хакать, написав собственные программы в тринадцать лет. Даже на занятиях в колледже хакерству учишься в основном через само хакерство. [3]

Because painters leave a trail of work behind them, you
can watch them learn by doing. If you look at the work
of a painter in chronological order, you'll find that each
painting builds on things that have been learned in previous
ones. When there's something in
a painting that works very well, you can usually find version
1 of it in a smaller form in some earlier painting.

Поскольку художники оставляют за собой след из работ, можно наблюдать, как они учатся в процессе. Если расположить работы художника в хронологическом порядке, обнаружишь, что каждая картина опирается на то, чему он научился в предыдущих. Когда в картине есть что-то, что работает очень удачно, обычно можно найти версию 1 этого в меньшей форме в какой-нибудь более ранней картине.

I think most makers work this way. Writers and architects seem
to as well. Maybe it would be good for hackers
to act more like painters, and regularly start over from scratch,
instead of continuing to work for years on one project, and
trying to incorporate all their later ideas as revisions.

Думаю, большинство создателей работают именно так. Писатели и архитекторы, похоже, тоже. Возможно, хакерам было бы полезно вести себя больше как художники и регулярно начинать с чистого листа, а не годами работать над одним проектом, пытаясь встроить все свои более поздние идеи в виде правок.

The fact that hackers learn to hack by doing it is another
sign of how different hacking is from the sciences. Scientists
don't learn science by doing it, but by doing labs and problem sets.
Scientists start out doing work that's perfect, in the sense
that they're just trying to reproduce work someone else has
already done for them.
Eventually, they get
to the point where they can do original work.
Whereas hackers, from the start, are doing original work; it's
just very bad. So hackers start original, and get good, and
scientists start good, and get original.

То, что хакеры учатся хакать через само занятие, — ещё один признак того, насколько хакерство отличается от наук. Учёные учатся науке не через само занятие наукой, а через лабораторные и задачники. Учёные начинают с работы, которая безупречна — в том смысле, что они лишь пытаются воспроизвести работу, уже сделанную для них кем-то другим. Со временем они доходят до момента, когда могут делать оригинальную работу. Тогда как хакеры с самого начала делают оригинальную работу — просто очень плохую. Так что хакеры начинают с оригинального и становятся хорошими, а учёные начинают с хорошего и становятся оригинальными.

The other way makers learn is from examples.
For a painter, a museum is a reference library of techniques.
For hundreds of years it has been part of the traditional
education of painters to copy the works of the great masters,
because copying forces you to look closely
at the way a painting is made.

Другой способ, которым учатся создатели, — через примеры. Для художника музей — это справочная библиотека техник. Сотни лет частью традиционного образования художников было копирование работ великих мастеров, потому что копирование заставляет внимательно вглядываться в то, как сделана картина.

Writers do this too.
Benjamin Franklin learned to write by summarizing the points
in the essays of Addison and Steele and then trying to
reproduce them. Raymond Chandler did the same thing
with detective stories.

Писатели делают то же самое. Benjamin Franklin учился писать, кратко излагая мысли из эссе Addison и Steele, а затем пытаясь их воспроизвести. Raymond Chandler проделывал то же самое с детективными рассказами.

Hackers, likewise, can learn to program by looking at
good programs-- not just at what they do, but the source
code too. One of the less publicized benefits
of the open-source movement is that it has made it easier
to learn to program. When I learned to program, we had to rely
mostly on examples in books. The one big chunk of
code available then was Unix, but even this was not
open source. Most of the people who read the source
read it in illicit photocopies of John Lions' book, which
though written in 1977 was not allowed to be published
until 1996.

Хакеры, аналогично, могут учиться программировать, разглядывая хорошие программы — не только то, что они делают, но и их исходный код. Одно из менее разрекламированных преимуществ движения open-source в том, что оно облегчило обучение программированию. Когда я учился программировать, нам приходилось полагаться в основном на примеры из книг. Единственным крупным куском доступного тогда кода был Unix, но даже он не был open source. Большинство тех, кто читал исходники, читали их в нелегальных ксерокопиях книги John Lions, которую, хоть и написанную в 1977 году, не разрешали публиковать до 1996-го.

Another example we can take from painting is the way that
paintings are created by gradual refinement. Paintings usually
begin with a sketch.
Gradually the details get filled in.
But it is not merely a process of filling in. Sometimes
the original plans turn out to be mistaken.
Countless paintings,
when you look at them in xrays, turn out to have limbs that
have been moved or facial features that have been readjusted.

Ещё один пример, который мы можем взять из живописи, — то, как картины создаются путём постепенного уточнения. Картины обычно начинаются с наброска. Постепенно прорисовываются детали. Но это не просто процесс заполнения. Иногда первоначальный замысел оказывается ошибочным. Бесчисленные картины, если посмотреть на них в рентгеновских лучах, оказываются такими, где конечности были сдвинуты, а черты лица — переделаны.

Here's a case where we can learn from painting. I think hacking
should work this way too. It's unrealistic
to expect that the specifications for a program will be
perfect. You're
better off if you admit this up front, and write programs in
a way that allows specifications to change on the fly.

Вот случай, где мы можем поучиться у живописи. Думаю, хакерство должно работать так же. Нереалистично ожидать, что спецификации программы будут идеальны. Лучше признать это сразу и писать программы так, чтобы спецификации могли меняться на ходу.

(The structure of large companies makes this hard for them
to do, so here is another place where startups have an advantage.)

(Структура крупных компаний затрудняет для них такой подход, так что вот ещё одно место, где у стартапов есть преимущество.)

Everyone by now presumably knows about the danger of premature
optimization. I think we should be just as worried about
premature design-- deciding too early what
a program should do.

К настоящему моменту все, надо полагать, знают об опасности преждевременной оптимизации. Думаю, нам следует столь же беспокоиться о преждевременном дизайне — о том, чтобы слишком рано решать, что́ программа должна делать.

The right tools can help us avoid
this danger.
A good programming language should, like oil paint, make it
easy to change your mind. Dynamic typing is a win here because
you don't have to
commit to specific data representations up front.
But the key to flexibility, I think, is to make the language
very abstract.
The easiest program to change is one that's very short.

Избежать этой опасности помогают правильные инструменты. Хороший язык программирования должен, подобно масляной краске, позволять легко передумать. Динамическая типизация тут выигрывает, потому что не приходится заранее обязываться к конкретным представлениям данных. Но ключ к гибкости, на мой взгляд, — в том, чтобы сделать язык очень абстрактным. Легче всего менять ту программу, которая очень короткая.

This sounds like a paradox, but a great painting
has to be better than it has to be.
For example, when Leonardo
painted the portrait of Ginevra de Benci
in the National Gallery, he put a juniper bush behind her head.
In it he carefully
painted each individual leaf. Many painters might have thought,
this is just something to put in the background to frame
her head. No one will look that closely at it.

Звучит как парадокс, но великая картина должна быть лучше, чем ей необходимо быть. Например, когда Leonardo писал портрет Ginevra de Benci в National Gallery, он поместил за её головой куст можжевельника. На нём он тщательно прописал каждый отдельный листок. Многие художники могли бы подумать: это всего лишь нечто для фона, чтобы обрамить её голову. Никто не станет вглядываться в это так пристально.

Not Leonardo. How hard he worked on part of a painting didn't
depend at all on how closely he expected anyone to look at it.
He was like Michael Jordan. Relentless.

Но не Leonardo. То, насколько усердно он работал над частью картины, совершенно не зависело от того, насколько пристально, по его ожиданиям, кто-либо станет в неё вглядываться. Он был как Michael Jordan. Неумолим.

Relentlessness wins because, in the aggregate, unseen details
become visible.
When people walk by the portrait of Ginevra de Benci,
their attention is often immediately arrested by it,
even before they look at the label and notice that it says
Leonardo da Vinci. All those unseen details combine to produce
something that's just stunning, like a thousand barely audible
voices all singing in tune.

Неумолимость побеждает, потому что в совокупности невидимые детали становятся видимыми. Когда люди проходят мимо портрета Ginevra de Benci, их внимание часто оказывается мгновенно прикованным к нему — ещё до того, как они взглянут на табличку и заметят, что там написано Leonardo da Vinci. Все эти невидимые детали соединяются, порождая нечто просто ошеломляющее, — словно тысяча едва слышных голосов, поющих в унисон.

Great software, likewise, requires a fanatical devotion to
beauty. If you look inside good software, you find that
parts no one is ever supposed to see are beautiful too.
I'm not claiming I write great software, but I
know that when it comes to code I behave in a way that would
make me eligible for prescription drugs if I approached everyday
life the same way.
It drives me crazy to see code that's badly indented,
or that uses ugly variable names.

Великий софт точно так же требует фанатичной преданности красоте. Если заглянуть внутрь хорошего софта, обнаружишь, что красивы и те части, которые никто никогда не должен видеть. Я не утверждаю, что пишу великий софт, но знаю, что в отношении кода я веду себя так, что, веди я себя так же в повседневной жизни, мне бы полагались рецептурные препараты. Меня сводит с ума код с плохими отступами или уродливыми именами переменных.

If a hacker were a mere implementor, turning a spec into code, then
he could just work his way through it from one end to the other like
someone digging a ditch. But if the hacker is a creator, we have
to take inspiration into account.

Если бы хакер был просто реализатором, превращающим спецификацию в код, он мог бы попросту прорабатывать её от одного края к другому, как человек, копающий канаву. Но если хакер — творец, нам приходится учитывать вдохновение.

In hacking, like painting,
work comes in cycles. Sometimes you get excited about some
new project and you want to work sixteen hours a day on it.
Other times nothing seems interesting.

В хакерстве, как и в живописи, работа идёт циклами. Иногда тебя захватывает какой-то новый проект, и хочется работать над ним по шестнадцать часов в день. В другие времена ничто не кажется интересным.

To do good work you have to take these cycles into
account, because they're affected by how you react to them.
When you're driving a
car with a manual transmission on a hill, you have to back off
the clutch sometimes to avoid stalling. Backing
off can likewise prevent ambition from stalling.
In both painting and hacking there are some
tasks that are terrifyingly ambitious, and others that are
comfortingly routine. It's a good idea to save some easy
tasks for moments when you would otherwise stall.

Чтобы работать хорошо, эти циклы надо учитывать, потому что на них влияет то, как ты на них реагируешь. Когда ведёшь машину с механической коробкой передач в гору, иногда приходится отпускать сцепление, чтобы не заглохнуть. Точно так же «отпускание» помогает не дать заглохнуть честолюбию. И в живописи, и в хакерстве есть задачи устрашающе амбициозные и другие — успокаивающе рутинные. Хорошая идея — приберечь несколько лёгких задач на те моменты, когда иначе ты бы заглох.

In hacking, this can literally mean saving up bugs.
I like debugging: it's the
one time that hacking is as straightforward as
people think it is. You have a
totally constrained problem, and all you have to do is solve
it. Your program is supposed to do x. Instead it does y.
Where does it go wrong? You know you're going to win
in the end. It's as relaxing as painting a wall.

В хакерстве это может буквально означать накапливать баги. Я люблю отладку: это единственный момент, когда хакерство оказывается таким же прямолинейным, каким его представляют люди. У тебя полностью ограниченная задача, и всё, что нужно сделать, — её решить. Программа должна делать x. Вместо этого она делает y. Где она ошибается? Ты знаешь, что в конце концов победишь. Это так же расслабляет, как красить стену.

The example of painting can teach us not only how to manage our
own work, but how to work together. A lot of the
great art of the past is the work of multiple hands, though
there may only be one name on the wall next to it in the
museum. Leonardo was an apprentice in the workshop of
Verrocchio and painted one of the angels in his Baptism of
Christ. This sort of thing was the rule, not the exception.
Michelangelo was considered especially dedicated for insisting
on painting all the figures on the ceiling of the Sistine
Chapel himself.

Пример живописи может научить нас не только тому, как управлять собственной работой, но и тому, как работать сообща. Многое из великого искусства прошлого — труд множества рук, хотя рядом с ним на стене музея может стоять лишь одно имя. Leonardo был подмастерьем в мастерской Verrocchio и написал одного из ангелов в его Крещении Христа. Подобное было правилом, а не исключением. Michelangelo считался особенно преданным делу за то, что настоял на том, чтобы расписать все фигуры на потолке Сикстинской капеллы самому.

As far as I know, when painters worked together on a painting,
they never worked on the same parts. It was common
for the master to paint the principal figures and for assistants
to paint the others and the background. But you never had
one guy painting over the work of another.

Насколько мне известно, когда художники работали над картиной вместе, они никогда не работали над одними и теми же частями. Было обычным делом, что мастер пишет главные фигуры, а помощники — остальные и фон. Но никогда не бывало, чтобы один человек писал поверх работы другого.

I think this is the right model for collaboration in software
too. Don't push it too far. When a piece of code is
being hacked by three or four different people, no one of whom
really owns it, it will end up being like a common-room. It will
tend to feel bleak and abandoned, and accumulate cruft.
The right
way to collaborate, I think, is to divide projects into sharply
defined modules, each with a definite owner, and with interfaces
between them that are as carefully designed and, if possible,
as articulated as programming languages.

Думаю, это правильная модель совместной работы и для софта. Не доводите её до крайности. Когда кусок кода хакают трое-четверо разных людей, и никто из них им по-настоящему не владеет, он в итоге становится похож на общую гостиную. Он будет ощущаться унылым и заброшенным и обрастать хламом. Правильный способ сотрудничать, на мой взгляд, — делить проекты на чётко определённые модули, у каждого из которых есть однозначный владелец, с интерфейсами между ними, спроектированными столь же тщательно и, по возможности, столь же артикулированными, как языки программирования.

Like painting, most software is intended for
a human audience. And so hackers, like painters, must have
empathy to do really great work. You have to be able to see
things from the user's point of view.

Как и живопись, бо́льшая часть софта предназначена для человеческой аудитории. И потому хакеры, как и художники, чтобы делать по-настоящему великую работу, должны обладать эмпатией. Надо уметь видеть вещи с точки зрения пользователя.

When I was a kid I was always being told to look at things from
someone else's point of view. What this always meant in
practice was to do what someone else wanted, instead of what
I wanted. This of course gave empathy a bad name, and I made a
point of not cultivating it.

Когда я был ребёнком, мне постоянно говорили смотреть на вещи с точки зрения кого-то другого. На практике это всегда означало делать то, что хочет кто-то другой, вместо того, чего хочу я. Это, разумеется, создало эмпатии дурную славу, и я нарочно не стал её в себе развивать.

Boy, was I wrong. It turns out that looking at things from
other people's point of view is practically the secret of
success. It doesn't necessarily mean being self-sacrificing.
Far from it. Understanding how someone else sees things
doesn't imply that you'll act in his interest; in some
situations-- in war, for example-- you want to do exactly
the opposite. [4]

Ох, как же я ошибался. Оказывается, умение смотреть на вещи с точки зрения других людей — практически секрет успеха. Это не обязательно означает самопожертвование. Отнюдь. Понимание того, как видит вещи кто-то другой, не подразумевает, что ты будешь действовать в его интересах; в некоторых ситуациях — например, на войне — ты захочешь поступить ровно наоборот. [4]

Most makers make things for a human audience.
And to engage an audience you have to understand what they need.
Nearly all the greatest paintings are paintings of people,
for example, because people are what people are interested in.

Большинство создателей делают вещи для человеческой аудитории. А чтобы увлечь аудиторию, надо понимать, что ей нужно. Почти все величайшие картины — это, например, картины людей, потому что люди — это то, что людей интересует.

Empathy is probably the single most important difference
between a good hacker and a great one. Some hackers
are quite smart, but when it comes to empathy are
practically solipsists. It's hard for such
people to design great software [5], because they can't
see things from the user's point of view.

Эмпатия — пожалуй, единственное самое важное различие между хорошим хакером и великим. Некоторые хакеры весьма умны, но в том, что касается эмпатии, практически солипсисты. Таким людям трудно проектировать великий софт [5], потому что они не способны видеть вещи с точки зрения пользователя.

One way to tell how good people are at empathy is to watch
them explain a technical question to someone without a technical
background. We probably all know people who, though otherwise smart,
are just comically bad at this. If someone asks them at
a dinner party what a programming language is, they'll
say something like ``Oh, a high-level language is what
the compiler uses as input to generate object code.''
High-level language? Compiler? Object code? Someone who
doesn't know what a programming language is obviously doesn't
know what these things are, either.

Один из способов определить, насколько у человека хорошо с эмпатией, — понаблюдать, как он объясняет технический вопрос тому, у кого нет технического образования. Мы все, наверное, знаем людей, которые, будучи в остальном умными, в этом просто комично плохи. Если их на званом ужине спросят, что такое язык программирования, они скажут что-то вроде: «А, язык высокого уровня — это то, что компилятор использует на входе для генерации объектного кода». Язык высокого уровня? Компилятор? Объектный код? Тот, кто не знает, что такое язык программирования, явно не знает и что такое всё это.

Part of what software has to do is explain itself. So to
write good software you have to understand how little users
understand.
They're going to walk up to the software with no preparation, and
it had better do what they guess it will, because they're
not going to read the manual. The best system I've ever seen
in this respect was the original Macintosh, in 1985.
It did what software almost never does: it just worked. [6]

Часть того, что должен делать софт, — это объяснять себя. Поэтому, чтобы писать хороший софт, надо понимать, как мало понимают пользователи. Они подойдут к софту безо всякой подготовки, и ему лучше бы делать то, что они угадают, потому что руководство они читать не станут. Лучшей системой в этом отношении из тех, что я когда-либо видел, был оригинальный Macintosh 1985 года. Он делал то, что софт почти никогда не делает: он просто работал. [6]

Source code, too, should explain itself. If I could get people to
remember just one quote about programming, it would be the
one at the beginning of Structure and Interpretation of Computer
Programs.

Исходный код тоже должен объяснять себя. Если бы я мог заставить людей запомнить всего одну цитату о программировании, это была бы та, что стоит в начале Structure and Interpretation of Computer Programs.

Programs should be written for people to read, and
only incidentally for machines to execute.

Программы должны писаться для того, чтобы их читали люди, и лишь попутно — чтобы их исполняли машины.

You need to have
empathy not just for your users, but for your readers. It's in
your interest, because you'll be one of them.
Many a hacker has written a program only to
find on returning to it six months later that he has no idea
how it works. I know several people who've sworn off Perl after
such experiences. [7]

Эмпатию нужно иметь не только по отношению к своим пользователям, но и по отношению к своим читателям. Это в твоих же интересах, потому что одним из них будешь ты сам. Не один хакер писал программу, лишь чтобы, вернувшись к ней полгода спустя, обнаружить, что понятия не имеет, как она работает. Я знаю нескольких людей, которые завязали с Perl после такого опыта. [7]

Lack of empathy is associated with intelligence, to the point
that there is even something of a fashion for it in some places.
But I don't think there's any correlation.
You can do well in math and
the natural sciences without having to learn empathy, and people in these
fields tend to be smart, so the two qualities have come to be
associated. But there are plenty of dumb people who are bad at
empathy too. Just listen to the people who call in with questions on
talk shows. They ask whatever it is they're asking in
such a roundabout way
that the hosts often have to rephrase the question for them.

Недостаток эмпатии ассоциируется с интеллектом — до такой степени, что в некоторых местах на него даже существует своего рода мода. Но я не думаю, что тут есть какая-либо корреляция. Можно преуспевать в математике и естественных науках, не научившись эмпатии, а люди в этих областях склонны быть умными, вот два качества и стали ассоциироваться. Но полно и глупых людей, у которых с эмпатией тоже плохо. Достаточно послушать тех, кто звонит с вопросами на ток-шоу. Они задают то, что хотят спросить, столь окольным образом, что ведущим часто приходится переформулировать за них вопрос.

So, if hacking works like painting and writing, is it as cool?
After all, you only get one life.
You might as well spend it working on something great.

Итак, если хакерство работает как живопись и литература, так ли оно круто? В конце концов, жизнь даётся одна. Так что лучше уж потратить её на работу над чем-то великим.

Unfortunately, the question is hard to answer. There is always
a big time lag in prestige. It's like light from a distant star.
Painting has prestige now because of great work people did five hundred
years ago. At the time, no one thought
these paintings were as important as we do today. It would have
seemed very odd to people at the time that Federico da Montefeltro,
the Duke of Urbino, would one day be known mostly as the guy
with the strange nose in a painting
by Piero della Francesca.

К сожалению, на этот вопрос трудно ответить. В престиже всегда есть большое запаздывание во времени. Это как свет далёкой звезды. Живопись престижна сейчас благодаря великим работам, сделанным людьми пятьсот лет назад. В своё время никто не считал эти картины такими важными, какими их считаем мы сегодня. Людям той эпохи показалось бы очень странным, что Federico da Montefeltro, герцог Урбинский, однажды будет известен прежде всего как тот тип со странным носом на картине Piero della Francesca.

So while I admit that hacking doesn't seem as cool as painting now,
we should remember that painting itself didn't seem as cool in
its glory days as it does now.

Так что, признавая, что хакерство сейчас кажется не таким крутым, как живопись, нам стоит помнить, что и сама живопись в дни своего расцвета казалась не такой крутой, какой кажется теперь.

What we can say with some confidence is that these are the glory
days of hacking. In most fields the great work is done early on.
The paintings made between 1430 and 1500 are still unsurpassed.
Shakespeare appeared just as professional theater was being born,

Что мы можем утверждать с некоторой уверенностью — так это то, что сейчас золотые дни хакерства. В большинстве областей великое создаётся на ранних этапах. Картины, написанные между 1430 и 1500 годами, до сих пор не превзойдены. Shakespeare появился как раз тогда, когда рождался профессиональный театр,

and pushed the medium
so far that every playwright since has had to live in his shadow.
Albrecht Durer did the same thing with engraving, and Jane Austen
with the novel.

и развил эту форму так далеко, что всякому драматургу с тех пор приходилось жить в его тени. Albrecht Durer сделал то же самое с гравюрой, а Jane Austen — с романом.

Over and over we see the same pattern. A new medium appears, and
people are so excited about it that they explore most of its
possibilities in the first couple generations. Hacking seems
to be in this phase now.

Снова и снова мы видим одну и ту же картину. Появляется новое средство выражения, и люди настолько им увлечены, что в первые пару поколений исследуют бо́льшую часть его возможностей. Похоже, хакерство сейчас как раз в этой фазе.

Painting was not, in Leonardo's time, as cool as his work
helped make it.
How cool hacking turns out to be will depend on what we can
do with this new medium.

Живопись во времена Leonardo не была так крута, какой его работы помогли её сделать. Насколько крутым окажется хакерство, будет зависеть от того, что мы сумеем сделать с этим новым средством выражения.

Notes

Примечания

[1] The greatest damage that photography has done
to painting may be the fact that it killed the best day job.
Most of the great painters in history supported
themselves by painting portraits.

[1] Возможно, величайший урон, который фотография нанесла живописи, — в том, что она убила лучшую подработку. Большинство великих художников в истории кормились написанием портретов.

[2] I've been told that Microsoft discourages
employees from contributing to open-source projects, even in
their spare time.
But so many of the best hackers work on open-source
projects now that the main effect of this policy may be
to ensure that they won't be able to hire any first-rate
programmers.

[2] Мне говорили, что Microsoft отговаривает сотрудников от участия в open-source-проектах даже в свободное время. Но столь многие из лучших хакеров работают сейчас над open-source-проектами, что главным следствием этой политики может оказаться гарантия того, что компания не сможет нанять ни одного первоклассного программиста.

[3] What you learn about programming in college is much like
what you learn about books or clothes or dating: what bad taste you
had in high school.

[3] То, что узнаёшь о программировании в колледже, очень похоже на то, что узнаёшь о книгах, одежде или свиданиях: какой плохой вкус у тебя был в старших классах.

[4] Here's an example of applied empathy.
At Viaweb, if we couldn't decide between two alternatives, we'd
ask, what would our competitors hate most? At one point a
competitor added a feature to their software that was basically
useless, but since it was one of few they had that we didn't, they
made much of it in the trade press.
We could have tried to explain that the feature was useless,
but we decided it would annoy our competitor more if we
just implemented it ourselves, so we hacked together our own
version that afternoon.

[4] Вот пример прикладной эмпатии. В Viaweb, если мы не могли выбрать между двумя вариантами, мы спрашивали: что́ наши конкуренты возненавидели бы больше всего? Однажды конкурент добавил в свой софт функцию, по сути бесполезную, но поскольку это была одна из немногих, что были у них и не было у нас, они вовсю раструбили о ней в отраслевой прессе. Мы могли бы попытаться объяснить, что функция бесполезна, но решили, что конкурента сильнее разозлит, если мы просто реализуем её сами, и в тот же день к вечеру наспех сколотили собственную версию.

[5] Except text editors and compilers. Hackers don't need empathy to
design these, because they are themselves typical users.

[5] За исключением текстовых редакторов и компиляторов. Хакерам не нужна эмпатия, чтобы их проектировать, потому что они сами и есть типичные пользователи.

[6] Well, almost. They overshot the available RAM somewhat,
causing much inconvenient disk swapping, but this could be fixed
within a few months by buying an additional disk drive.

[6] Ну, почти. Они несколько превысили доступный RAM, что вызывало много неудобного свопинга на диск, но это можно было устранить за несколько месяцев, докупив дополнительный дисковод.

[7] The way to make programs easy to read is not to
stuff them with comments. I would take Abelson and Sussman's
quote a step further. Programming languages should be designed
to express algorithms, and only incidentally to tell computers
how to execute them. A good programming language
ought to be better for explaining software than English.
You should only
need comments when there is some kind of kludge you need to warn
readers about, just as on a road there are only
arrows on parts with unexpectedly sharp curves.

[7] Способ сделать программы лёгкими для чтения — не напихивать их комментариями. Я бы продвинул цитату Abelson и Sussman на шаг дальше. Языки программирования должны проектироваться для того, чтобы выражать алгоритмы, и лишь попутно — чтобы сообщать компьютерам, как их исполнять. Хороший язык программирования должен подходить для объяснения софта лучше, чем английский. Комментарии должны требоваться только там, где есть какой-то костыль (kludge), о котором нужно предупредить читателей, — точно так же, как на дороге стрелки ставят лишь на участках с неожиданно крутыми поворотами.

Thanks to Trevor Blackwell, Robert Morris, Dan Giffin, and Lisa
Randall for reading drafts of this, and to Henry Leitner
and Larry Finkelstein for inviting me to speak.

Благодарности Trevor Blackwell, Robert Morris, Dan Giffin и Lisa Randall за чтение черновиков этого текста, а также Henry Leitner и Larry Finkelstein за приглашение выступить.