Paul Graham: Chapter 2. Hackers and Artists (Habr edition)

Now Paul Graham teaches governments and universities how to create start-up hubs , but earlier ... he made a wonderful analogy between high-class programmers and artists.

For 13 years, the chapter of the same name with the name of the book has been lost in the network. For convenience, I want to publish it, collected in pieces from various archives.
')
Translated by Anastasia Gryzunova, Yana Shchekotova. Putting the text in order - CaptainCrocus . Publishing assistance - Edison .

Original - Hackers and Painters (May 2003)


After graduating from computer science graduate school, I went to art school to study painting. Many were surprised that a computer geek suddenly became interested in painting. These people apparently believed that hacking and art are very different occupations: hacking is cold, precise and methodical, and art is a fierce expression of some primitive rush.

Both views are incorrect. In hacking and art mass common. Of the many different types of people, hackers and artists are perhaps the most alike.

What they have in common here is the one and the other creators. And those and others are trying to do something quality. As composers, architects and writers. Both those and others conduct research not for the sake of research (although if new methods are discovered in the process of creating something qualitative, so much the better).

I never liked the term "computer science". Mainly because there is no such science. “Computer science” - a junk bag, where history has capriciously dumped a bunch of weakly related areas of science - some Yugoslavia turned out. At one extreme are the mathematics that call their work computer science to receive DARPA grants. At the equator there is some kind of computer science: for example, the behavior of algorithms when transmitting data over networks. And at the other extreme are hackers; they write interesting software, and computers for them are only a medium of self-expression, like concrete for an architect or paint for an artist. It is the same as mathematicians, physicists and architects to drive into one department.

Sometimes the work of hackers is called “software engineering” (software engineering). This term is also confusing. With the same success can be called an engineer architect. The boundary between architecture and engineering is fuzzy, but it is. It passes between “what” and “how”: the architect decides what to do, the engineer calculates how.

“What” and “how” should not be separated. Trying to decide what to do and not understanding how, you just ask for trouble. But of course, hackers do not just know how to decide how to implement the specification. In its apogee, the hacking specification creates - true, as it turns out, to create a specification, it is best to embody it.

It is possible that one day “computer science” will fall apart into components, like Yugoslavia. Maybe it's for the best. Especially if in the end my homeland - hacking - becomes sovereign.

Probably, from an administrative point of view, it is convenient to pack all these diverse classes in one department. Only it is very confusing. Here is another reason for my dislike of the term "computer science". Suppose those who are at the equator, are engaged in approximately experimental science. But those that are at the poles, mathematicians and hackers, in general have nothing to do with science.

Mathematicians do not seem to be worried. They are happy to be limited to theorems, like other mathematicians from mathematics, and soon, I think, they stop noticing that on the house where they go to work, there is a “computer science” sign hanging outside. But hackers from this sign - one headache. If hackers are engaged in science, then they need to act in a scientific way. And hackers from universities and research laboratories believe that they have to write scientific works, and not to do what they want - to create excellent programs.

Their scientific work is formality at best. Hackers write cool software, and then a report on this software, and the report certifies the success expressed by the software product. But often the case is complicated. It’s too easy to choose ugly things to beautiful ones: ugly things look better in research reports.

Unfortunately, beautiful things are not always an ideal topic for a report. Firstly, the scientific work must be original - and, as anyone who defended his candidate’s work knows, there is only one path to the virgin territory: you need to stake out a plot that no one voluntarily encroaches on. Secondly, the scientific work must be solid: with crooked systems, reports are more meaningful - you can write about the obstacles that the author has overcome before everything worked out. For meaningful work, there is nothing better than erroneous conclusions at the beginning. An example of this is the majority of work on artificial intelligence; if we conclude that knowledge can be presented alongside affirmative logical expressions, where arguments are abstract concepts, you can write a ton of dissertations on how to make it work. As Ricky Ricardo used to say, "Lucy, you have a lot to explain."

And in order to create the beautiful, it is often necessary only to slightly turn something that already exists, to connect old ideas in a slightly different way. Such an activity is not easy to describe in the dissertation.

So why are universities and research laboratories still judging hackers by scientific publications? And why the “ability to learn” is measured by simple tests, and the programmer's productivity is measured by the number of lines of code. The reason is the same.

Tests are easy to carry out, and there is nothing more seductive than a test that seems to work.

Assessing what hackers are really trying to do — great programs — is much more difficult. To judge a good design, you need a subtle development feel. And the ability to recognize good design and the confidence that you can recognize it, do not correlate - unless it is negative.

The best criterion is time. Over time, beautiful things flourish, and ugly things get lost in oblivion. Alas, time may take longer than human life lasts. Samuel Johnson said that it takes a hundred years to form a writer's reputation [1] : until influential friends of the writer die, and then their admirers.

Accident plays a big role in the reputation of hackers - in my opinion, we must accept this. In this sense, hackers are not much different from other creators. Compared to many hackers - just lucky. In painting, the influence of fashion is much stronger.

People do not understand your work - it’s bad, but there are worse things. Worse, if you do not understand your work. In search of ideas, go deep into related areas. At the computer science department, for example, it is very tempting to convince oneself that hacking is an applied version of what theoretical computer science theorizes. In graduate school, I was constantly tormented by a vague thought that more attention should be paid to theory, and it is very careless of me to forget it completely three weeks after the final exams.

Now I understand that I was wrong. Hackers need a theory of computing no more than artists need paint chemistry. We need to know how to calculate the time and spatial complexity, more about Turing completeness. Well, it still doesn’t hurt to remember at least the concept of a finite state machine - in case you write a parser or a regular expression library. In fact, artists have to remember the chemical composition of paints much more.

I discovered that the best sources of ideas are not areas whose names include the word “computer”, but those that are inhabited by creators. Painting - the source is much richer than the theory of computation.

For example, I was taught in college: before approaching a computer, the program should be written on paper entirely. It turns out that I programmed wrong. I enjoyed programming in front of the computer, rather than above a piece of paper. Worse, I did not patiently write the whole program, checking for errors, I threw up a hopelessly curved code and gradually brought it back to normal. Debugging, they taught me, is the last run when you catch typos and omissions. I worked in such a way that programming seemed like endless debugging.

I was worried about this for a long time - as if I didn’t hold a pencil in the same way as it was taught in elementary school. If I looked at other creators, at artists, architects, I would understand that my methods have a name: sketches. As far as I understand, in college I was taught programming completely wrong. You create a program in the process of writing, as artists, architects, and writers do.

Awareness of this fact really affects software development. A programming language must first be flexible. A programming language is to think about programs, not to formulate programs that are already thought out. A pencil, not a pen. Static type checking is not a bad thing if you programmed really as taught in college. But no hacker I know works that way. We need a language that allows karyobat, put blots and erase, and not like sitting with a cup of data types and politely talking with a strict aged compiler aunt.

Since we are talking about static control, that's what. Having called ourselves the creators, we will get rid of one more problem that torments science: from envy to mathematics. Any scientist secretly believes that mathematics is all smarter. It seems that mathematicians believe in this no less than the rest. But in the end, scientists are trying to make their work look like a mathematical one to the limit. Maybe in some physics this is not a problem, but the farther from the natural sciences, the more aggravated the problem.

Well, of course - the formula page is impressive. (Advice: for special expressiveness, enter the Greek variables.) And therefore it is so tempting to deal with problems that can be approached formally, and not over those that, let's say, are important.

If hackers saw in themselves creators - writers or artists - such temptation would not have arisen. Writers and artists are not jealous of mathematicians. They believe that they are doing something completely unrelated to mathematics. Like hackers, I suppose.

Universities and research laboratories do not allow hackers to do what they like - maybe hackers have a place in corporations? Alas, most corporations do not allow this either. Universities and laboratories force hackers to be scientists, and corporations - engineers.

I myself discovered this very recently. When Yahoo bought Viaweb, they asked me what I wanted to do. I never really liked the business aspects, and I said that I wanted to do one hacking. Once in Yahoo, I found that for them it meant embodying software products, not creating. Programmers for them are technologists who translate visions (well, let's call them that) managers into a code language.

It seems that in big companies this is the only way. Corporations do this to ultimately reduce the average level of deviations. Only a few hackers can really create software, and it is not easy to calculate them. Therefore, companies do not hand over the future of a software product to an ingenious loner, but arrange everything so that the product is created by a group, and hackers only embody it.

If you want to make money, keep this in mind all the time - this is one of the reasons for the success of startups. Large companies reduce the average deviation of the final product, because they do not want a catastrophe. But aligning the oscillations, you lose not only the lower extremes - the upper ones too. Major corporations are neither cold nor hot because they do not win at the expense of ingenious products. They win because they are not as nightmarish as other large corporations.

So if you figure out how to get involved in a war of development with a fairly large company whose software is created by product managers, the company will never follow you. Only opportunities - the cat wept. It is difficult for a large corporation to drag in developments in a war: it is difficult to drag in the enemy, who has entrenched himself in a fortress, in a hand-to-hand battle. Writing a word processor is better than Microsoft Word, for example, is not difficult, but Microsoft will probably not notice you and your processor in the impregnable lock of its monopoly on operating systems.

Wars of development in new markets should be waged where no one has yet built fortifications. There you can win big, creating a bold product and arranging so that the same people are engaged in its creation and embodiment. At the beginning, Microsoft itself worked this way. And Apple. And Hewlett Packard. I suspect all successful startups did this.

So, one of the ways to create great programs is to open your own startup. However, there are two problems. First, in a startup, you have to do a lot of things besides writing programs. In Viaweb, I was lucky that I hacked a quarter of the time.

In the remaining three quarters of the time, I did a bunch of things, from boring to terrible. I had a point of reference: once I had to leave the meeting of the board of directors in order to put the seals. I remember, I am sitting in a dental chair, anticipating a drill, and I feel like I'm on vacation.

Another problem is that software that brings money, and software that is interesting to write, do not intersect too much. It is interesting to write programming languages, and the first Microsoft product, in essence, was one, but now they don’t pay for programming languages. If you want money, you have to tackle problems that no one can solve for free, they are so monstrous.

This is the problem of any creator. The price is determined by supply and demand, and the pieces on which it is interesting to work are less in demand than the solution to the earthly problems that every consumer faces. For playing in off-Broadway plays, they pay less than running around at a fair in the shoes of a gorilla. For writing novels - less than for advertising garbage collection. And for hacking programming languages ​​- less than for software that clings corporate database to a web server.

I think that in the field of software, the problem is solved by a concept known to almost any creator: day work. The phrase was entered by musicians who play at night. In general, this means that one work for money, the other - for love.

Full-time work at the beginning of a career was enjoyed by almost all creators. This famous artists and writers. If you are lucky, you will find a job related to your present case. Musicians often work in music stores. A hacker working on a programming language or operating system may well find a job where all this is useful. [2]

Of course, the idea is not new. All open source programming is built on this. Actually, I want to say that maybe open source is the right model: all other creators independently confirm its correctness.

I would be surprised if an employer would reluctantly allow hackers to work on open source projects. In Viaweb, we reluctantly hired those who did not. At the interviews we were most interested in what kind of software a programmer writes in his spare time. If you do not like work, you will not be able to work really well, and if you like hacking, you will inevitably work on your own projects. [3]

Hackers are creators, not scientists, therefore, the metaphor should be sought not in the sciences, but among other creators. What else does painting teach us?

Firstly, we learn from the example of painting - we check, in any case, how to learn hacking. You learn to draw, mainly by drawing. Hacking is the same. Most hackers comprehend the craft is not at all learning programming courses in college, but creating their own programs - starting with the age of thirteen. At school, you learn to hack, just hakaya. [four]

The artist leaves canvases by which one can trace how he studied. If we look at the artist's works in chronological order, it will become clear that each subsequent painting contains the experience of the previous ones. As a rule, in early works the germ of later creative successes is found.

I think this is the way most creators work. Writers and architects, apparently, too. Maybe it is more useful for hackers to act as artists, to constantly start from scratch, and not work for years on a single project, trying to incorporate their latest ideas into it.

The fact that hackers learn in the process of work once again demonstrates how hacking and science are different. Scientists do not learn science in the process, they conduct laboratory tests and formulate tasks. Scientists begin with an ideal job - in the sense that they are trying to reproduce the work that someone did for them. And then they can finally do something original. Hackers do something original from the start; it's just bad. Therefore, hackers start from the original and bring it to perfection, and scientists start with perfection and bring it to originality.

More creators learn from examples. For the artist, the museum is a reference for artistic techniques. For hundreds of years, the traditional teaching of artists has been copying the works of great masters, because copying makes you look more closely at how the canvas is made.

Writers do that too. Benjamin Franklin learned to write, summarizing the main points of the Addison and Steele essay, and then trying to reproduce them. Raymond Chandler did the same with detective stories.

And hackers can learn to program by studying quality programs - not only outside, the source too.One of the least well-known advantages of open source programming is that it has greatly simplified learning programming. When I was studying, we had to basically learn examples from books. The only big cous of code at that time was Unix, but even that was not open source.

Most of those who read it, studied the illegal photocopies in the book of John Lyons, written in 1977, but allowed for publication only in 1996.

And here is what painting teaches us: pictures are created by step-by-step improvement. Usually the picture begins with an outline. Gradually added details. But not just added. Sometimes the original plan is wrong. On a set of pictures, if you look at them under x-ray, you can see shifted arms and legs or reddened facial features.

We could learn this from painting. In my opinion, hackers should act that way. It is foolish to expect that the specifications of the program will be ideal. It’s better to recognize this right away and write programs to change specifications on the fly.
(The structure of large corporations does not allow this, so here again, startups have an advantage.)

Now everyone seems to be aware of the danger of premature optimization. I think there is reason to worry about premature development, because it will be too early to decide what exactly the program should do.

To avoid this danger will help the right tools. A good programming language, like oil paints, makes it easy to change your mind. Dynamic type checking is a big plus: you don’t have to immediately subscribe to a specific data view. But the key to flexibility is to make the language very abstract. Short programs rewrite easier.

It sounds like a paradox, but the great canvas should be better than it should be .. Creating a portrait of Ginevra de Benchi (National Gallery), Leonardo placed a juniper bush behind her head. In it, he carefully prescribed each sheet. Many artists believed that it was just a background, a frame for the head. Who will closely study the bush?


This is not Leonardo. He carefully worked on each piece - no matter whether they look at it carefully or not. He was like Michael Jordan. Implacable.

Relentlessness is the key to victory: invisible details all become visible together. Passing by the portrait of Ginevra de Benchi, people often pay attention to him, not even looking at the sign with the signature "Leonardo da Vinci." All the invisible details together form something amazing, like a thousand barely audible voices singing in unison.

Excellent programs also require fanatical devotion to beauty. If you look inside a good program, you can see that even those fragments that nobody seems to see are beautiful in it. I do not claim to write great software. However, in daily life I behave in the same way as above the code, I would be prescribed medications. I'm worried if the code is poorly formatted, or if there are ugly variables in it.

If the hacker were a simple performer who turned the specification into a code, he would work from beginning to end, as if he were digging a ditch. But if a hacker is a creator, then inspiration should be taken into account.

In hacking, as in painting, work happens in cycles. Sometimes a new project is so exciting that it is ready to work sixteen hours a day. And sometimes nothing really touches.

In order to work qualitatively, we should not forget about these cycles: they depend on how you perceive them. When you go uphill in a car with a manual gearbox, sometimes you need to slow down so as not to stall. Retreat saves designs, and they do not fade away. In both painting and hacking, some tasks are terribly ambitious, while others are comfortingly common. It is reasonable to keep simple tasks until the moment when you simply stall without them.

In hacking, it literally means to leave bugs. I like debugging: during debugging, hacking turns out to be straightforward, which is what everyone thinks of it. There is a specific problem, and you need to solve it. The program should do X. And she does Y. What's wrong? You understand that you will win in the end. Relaxing how to paint the wall.

Painting teaches us not only to cope with our own work, but also to work together. Many of the great works of the past are the fruit of dozens of hands, although on the plate in the museum, perhaps, only one name appears. Leonardo studied in the workshop del Verrocchio and wrote an angel in the Baptism of Christ. Such cases were the rule, not the exception. Michelangelo was considered particularly zealous because he insisted on writing all the pieces on the ceiling of the Sistine Chapel himself.


As far as I know, artists, working together on a canvas, never wrote the same fragments. Usually the master wrote the main figures, and the assistants wrote the rest and the background. But not one wrote over the work of others.

In my opinion, this is also a successful cooperation model in programming. Do not go too far. When one piece of code is written by three or four people, and does not truly belong to anyone, it eventually turns into some kind of common room. Joyless, abandoned, dust collects. In my opinion, it is more correct to divide projects into rigidly defined modules, to issue each module modulo, and develop interfaces between modules to be as neat and, ideally, as clear as programming languages.

Programs, like painting, are mainly intended for people. And therefore, to create great works, hackers, like artists, must be able to empathize. Look at the product through the user's eyes.

As a child I was advised all the time to look at something from another point of view. In fact, this has always meant that we have to act as someone wants, and not as I want. From this empathy gained a bad reputation, and I deliberately did not pay attention to him.

Lord, how wrong I was. It turned out that the ability to look with someone else's eyes is practically the key to success. Empathy is not necessarily self-sacrifice. Not at all.If you understand someone else's point of view, it does not at all mean that you will become acting in the interests of others. In some situations - in a war, for example - you act exactly the opposite [5] .

Most creators do it for people. And in order to attract an audience, you need to understand what it needs. Almost on any painting canvas - people, because people interest people.

Perhaps empathy is the only major difference between a good hacker and a great one. Some hackers are very smart, but from the point of view of empathy - just solipsists. It is difficult for such people to create great software [6] : they do not see the product through the user's eyes.

To check how much empathy people are given, watch how they clarify technical issues to the interlocutor who does not understand technology. Everyone has friends, generally clever, but comically unable to solve this problem. If you ask them at dinner what a programming language is, they respond like this: “Well, the high-level language is what the input compiler uses to generate the object code.” High level language? Compiler? Object code? A person who does not know what a programming language is, certainly does not know these words.

The software partly explains itself. Therefore, to write good software, you should understand how little the user understands. He will turn to software without the slightest preparation, and it is better to let the software not deceive user expectations and do what it should, because the user will not read the instructions. The best system I know from this point of view is the 1985 Mac. He did what the software does not normally do: he just worked [7] .

Sources should also explain themselves. If I needed to teach people a single phrase about programming, I would teach them a quote given at the beginning of “Structure and Interpretation of Computer Programs” [8] :

Programs are written for people to read them, and only occasionally for the machines to execute them.

It is necessary to empathize not only with users, but also with readers. It is in your interest - you yourself will be one of them. A lot of hackers wrote programs first, and six months later, they found out that they have no idea how these programs work. Several of my acquaintances after such cases have vowed never to write in Perl [9] .

The lack of empathy is associated with intelligence — to the extent that in certain circles it is even fashionable in some way. I do not think that they somehow correlate. In mathematics and science, you can do without empathy; in such areas, people are usually smart, so the two qualities form a bundle. But there are a lot of stupid, which empathy is also not given. You listen to people who call with questions on a talk show. They ask these questions so crookedly that the presenter often has to be reformulated for them.

So, the mechanism of hacking is the same as in painting and literature - but is it really cool? In the end, there is only one life. Maybe it's better to dedicate it to something great?

Unfortunately, there is no simple answer. Glory is always very late. Like the light of a distant star. Painting is recognized because of the great paintings created five hundred years ago. Then these paintings were given much less value than today. In those days, it would have seemed extremely strange to people that someday Federico da Montefeltro, Duke of Urbino, would be known mostly as the guy with a strange nose in the picture of Piero della Francesco.


Yes, I admit that now hacking is not as cool as painting, but it should be remembered that painting did not seem so cool during the heyday.

With some confidence one can argue: now are the heyday of hacking. In most other areas, great works were created earlier. Painting, created between 1430 and 1500, remains unsurpassed to this day. Shakespeare appeared when a professional theater had just emerged; Shakespeare brought him to such heights that any playwright still lives in his shadow. Albrecht Durer did the same with the engravings, and Jane Austen with the romanist.

This is repeated over and over. A new environment arises and captures people in such a way that, for the first couple of generations, they squeeze out almost all of its possibilities. Apparently, hacking is now in this phase.

At the time of Leonardo, painting was not as cool as his work did. How cool the hacking will be depends on what we can do with this new medium. If you think about it, the time lag in recognition is dignity. Communicating with a person who writes a compiler or a Unix kernel, you know, at least, that he does not do this in order to remove girls.

Notes

[1] Johnson wrote in the preface to his Shakespeare edition:
“He has long gone through his century, a period that is usually measured to evaluate the artistic value of a book. Whatever advantages may arise from private references, local traditions, or temporal opinions, they have all been lost many years before; and every joyful topic or occasion for sadness, which the artificial way of life has given him, now only obscures the scenes that they once covered. The influence of support and rivalry is over; his friendly and hostile relations have sunk into oblivion; his works do not support anybody’s argumentative opinion, and do not fuel quarrels with accusatory speeches; they can neither indulge vanity nor indulge anger, but they are read solely for the sake of pleasure and, consequently, are exalted only if pleasure is received ... "

[2] The worst thing that made the picture with the painting, perhaps, is that it destroyed the best work. Most of the great artists made their living by creating portraits. Soon after the photo appeared, their number was thinned due to the appearance of hired photographers. (This method is also easier to use when working with models.) The class of technical artists to one degree or another ceased to exist, and the role of skill in assessing the picture was shifted to the fame (which also depends heavily on the photograph, or presented in books and magazines).

[3] Microsoft prevents employees from contributing to open source projects, even in their free time. But now there are so many excellent specialists working on open source projects that the main result of such a policy may be that it will become harder for them to hire first-class programmers.

[4] What you learn about programming in college is similar to what you learn about books or clothes: yes, you had absolutely no taste at school.

[5] Here is an example of applied empathy. If we in Viaweb could not choose from two options, we asked ourselves which one would upset the competition more. Once a competitor added an option to his product — essentially useless, but that was one of the few options that we didn’t add, and in the professional press, a lot was written about the competitor. It could be explained that the option is useless, but we decided that the competitor would be more upset if we implemented it ourselves. In general, we wrote our version that evening.

[6] In addition to text editors and compilers. For them, hackers empathy is not required, because the typical users are the hackers themselves.

[7] Well, almost. They went overboard a bit with memory, which made uncomfortable swapping, but this was easily fixed in a few months by buying an additional hard drive.

[8] Abelson, Harold, and Gerald Sussman, MITPress, 1985.

[9] To simplify the reading of programs does not mean to hammer in their comments. I would develop the idea of ​​Ebelson and Sussman: programming languages ​​should be created to express algorithms and only occasionally to tell computers how to execute them. A good programming language explains software better than English. Comments are needed only if there is some blooper in the program, about which the reader needs to be informed, as on the road, where the arrows hang only on sharp turns.