Slashdot Mirror
Paul Graham: Hackers and Painters
larsberg writes "Another wonderful article from Paul Graham on hackers, their lifestyle, and their tools. It's entitled "Hackers and Painters", and provides a great description of how the great hackers write code. The article is definitely worth a read, especially for those who have an inkling that any field that has to place the word "Science" in its name probably isn't really a science after all."
I don't know any real hackers that speak like that either, just the wannabes.
Programming / Hacking is neither and art or a science and yet it is both. If you don't program you probably would not understand, but if you've ever implemented your own b-tree in an application, you'll probably agree. Most likely, whether or not you agree depends on what type of software you have written in the past.
Art and science are probably closer than most people believe. Leonardo da Vinci painted some of the most astounding scenes ever painted; yet, he also studied science, literature, and the Christian bible. Many mathematicians would say that math is an art, heck there are probably some artists that believe art is a science.
Knuth says that computer programming is an art, but I dare you to read his books and claim they are devoid of science.
In short... It's all depends on the application.
10: PRINT "Everything old is new again."
20: GOTO 10
"Perhaps one day "computer science" will, like Yugoslavia, get broken up into its component parts"
This is already the case. There are people specializing in writing comp-sci software (compiler etc...), there all those double-majors who write software for their other degree specialization (software for given domains like geophysical etc...), there are people who specialise on the ergonomic of the GUI, etc....
This isn't that different from people designing a car, a thing that is both functional and can be beautiful. It takes engineer and designer to make a car.
Now don't tell me "I am the creative type", I am writting software, science doesn't apply to me. I once work in a software lab where the lab had been producing software for several decades. One day the person in charge of QA convinced the person in charge of development to bring some quality type tools like cyclomatic analysis (McCabe etc...). A few engineer came up with that argument that they were producing art, that a software couldn't / shouldn't judge them.
Well, they did two things: They ran McCabe against a lot of their software, some that have been in the market for decades, and there was a direct correlation between the "level" the tool was finding and the number of patches applied to the piece of software. Then they analysed code per current programers: The artsy types were writting complex code that the QA dept. kept sending back !!
Conclusion, there is a place for "out there" artsy type to inovated in a small shop, there is a place in ergonomic to write "beautifull software", but a serious piece of software does need some science.
Think about this, how beautifull would a car that looks good but keeps breaking down be ? Doesn't this remind you a lot of the software out there ?
He's not referring to all programming as "hacking". In fact, the article mentions how most of the programmers in the corporate world do jobs that have absolutely nothing to do with his concept of hacking. Hacking has a heavy dose of design on it. In fact, Graham argues that design happens to be more important than the actual implementation, it just happens that the implementation gets done as you design.
On most cases, coding to a design, instead of coding to user specs, restricts the task so much that there is little chance of creativity. That's not Hacking at all. On the other hand, desigining a +100,000 LOC complex, flexible system, designing it's data structures and object relationships, is so much more complex than "grunt coding" that I think it is way closer to architecture than it is to building a brick wall.
If you belive that all design/code is more like building a house than paiting it's just because you've not seen a truly brilliant, innovative design yet. I hope you're lucky enough to see one, or better yet, create one.
If you really want to pick an analogy, I'd pick carpentry. Not finish carpentry, as that's too artistic on the scale, but rather functional carpentry. For instance, a carpenter with no real experience and no tools can build a table out of what they find lying around. Some tables have four different legs of four different sizes, one's attached by childrens paste, and another with a high strength steel bolt. See most OSS packages for the coding analogue. A better carpenter has a few tools and makes a better structure, giving a more functional table. Better programs stand up well provided you embrace their rigid design criteria. A master carpenter might the best looking table and design it such that he could come back and add drawers later or replace it with a bigger top or taller legs.
Carpentry, like software, is mostly about figuring out what pieces you'll need and how to piece them together. That's the essence of engineering. Those who study traditional engineering disciplines often scoff at the idea of software engineering because it violates the traditional way of doing the engineering before construction. That hasn't always been the case, and even today some software is developed by traditional engineering techniques. That's not an invalid way to do it, although it is more expensive. Software engineers are embracing the engineer-on-the-fly paradigm, and that's a new idea that nobody really knows how to teach.
In carpentry as in software, the engineering and fabrication are distinct and separable. I wouldn't consider it unlikely that in the future software architecture (engineering) will be done by a different group of people than the coding (fabrication). This is starting to show up now with many companies doing their architecture in UML and then sending it overseas for actual implementation.
This has run way longer than I wanted, so I'll stop here.. Just a few thoughts on a slow morning.
Maybe I'm just too old (OK, yesterday was my 40th birthday, so call me a curmudgeon if you want, I've been called worse) but when I started out as a systems programmer, it was fashionable to speak English. Leet-speak doesn't exactly do much to promote ease of communication, does it?
The exceptions and formality of Java are supposed to aid development by making sure you've crossed all your t's and dotted your i's when it comes to error handling and type checking. (emphasis mine)
;-) That is indeed the "strong, static type checking" party line.
You carefully qualified your statement so I won't lay into you
An increasing number of smart people are starting to ask questions about that party line though. They'll try out a dynamic language like Python, and the disaster promised by the static typing advocates conspicuously fails to materialize. For two examples of this, see Are Dynamic Languages Going to Replace Static Languages? and Strong Typing vs. Strong Testing. A lot of other people are leaning this way too in newsgroups and on personal weblogs, and of course a lot of people still believe the party line.
Personally, I'm suspicious of "received wisdom" that's much older then 10 or 20 years, as the static typing claims are; the world has changed a lot since then in a lot of ways, not least of which is our improved understanding of how to build things (i.e., even in non-technological ways).
I disagree. It seems like there is a stigma against the "hacking method" of development in the large software engineering companies. I totally related to the hacking mentality he described, and I have felt (since college) that this is not the "right way" to do things. I learned to hack in jr. high and high school, while college taught me rigorous design and implementation methods. These methods are anti-hacking because they focus on a lot of up-front paper design and process, whereas the hacking mentality involves working out the problem in code on-the-fly and refining over time. It's not unlike roughing out a sculpture in clay and progressively adding detail and changing things here and there as you go rather than working out the sculpture ahead of time.
So the point of this is that he is trying to say that hacking is a legitimate technique that has advantages over the traditional, slower and possibly less flexible, software engineering moethods and he's doing it by drawing parallels to how artists work. I think the truth is that you need a little of both.