Paul Graham
Hackers & Painters
I've never liked the term "computer science." The main reason I don't like it is that there's no such thing.
Note: What if we replaced comp sci with Ed reform?
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.
Big companies win by sucking less than other big companies.
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. All makers face this problem.
Note: On Matt's mind: I am struggling w our full time stuff. What if we need to be looking for people while they are still in their day jobs?
When we interviewed programmers, the main thing we cared about was what kind of software they wrote in their spare time.
Note: Our selection needs to be more focused on this.
hackers start original, and get good, and scientists start good, and get original.
Note: On Matt's mind: Which one are we?
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.
Note: I wonder if school leaders really feel this way about things like interim assessments and other things that folks keep saying are silver bullets? Are we totally misunderstanding school leaders and teachers the way hackers are misunderstood?
Empathy is probably the single most important difference between a good hacker and a great one. Some hackers are quite smart, but practically solipsists when it comes to empathy. It's hard for such people to design great software, because they can't see things from the user's point of view.6
Note: Damn. Did not see that coming. We need to eat lunch with Joe next week.
It is by poking about inside current technology that hackers get ideas for the next generation.
We had general ideas about things we wanted to improve, but if we knew how we would have done it already. What were we going to do in the next six months? Whatever looked like the biggest win. I don't know if I ever dared give this answer, but
At Viaweb, as at many software companies, most code had one definite owner. But when you owned something you really owned it: no one except the owner of a piece of software had to approve (or even know about) a release. There was no protection against breakage except the fear of looking like an idiot to one's peers, and that was more than enough. I may have given the impression that we just blithely plowed forward writing code.
Over time the teams have gotten smaller, faster, and more informal. In 1960, software development meant a roomful of men with horn-rimmed glasses and narrow black neckties, industriously writing ten lines of code a day on IBM coding forms. In 1980, it was a team of eight to ten people wearing jeans to the office and typing into VT100s. Now it's a couple of guys sitting in a living room with laptops. (And jeans turn out not to be the last word in informality.)
At Viaweb we spent the first six months just writing software. We worked the usual long hours of an early startup. In a desktop software company, this would have been the hard part, but it felt like a vacation compared to the next phase, when we took users onto our server. The second biggest benefit of selling Viaweb to Yahoo (after the money) was to be able to dump ultimate responsibility for the whole thing onto the shoulders of a big company.
CEOs, stars, fund managers, and athletes all live with the sword hanging over their heads; the moment they start to suck, they're out. If you're in a job that feels safe, you are not going to get rich, because if there is no danger there is almost certainly no leverage.
But you don't have to become a CEO or a movie star to be in a situation with measurement and leverage. All you need to do is be part of a small group working on a hard problem.
Steve Jobs once said that the success or failure of a startup depends on the first ten employees. I agree. If anything, it's more like the first five. Being small is not, in itself, what makes startups kick butt, but rather that small groups can be select.
Nothing is more powerful than a community of talented people working on related problems.
Today's experimental error is tomorrow's new theory.
They do a really good job of solving slightly the wrong problem.
Nothing could be better for a new technology than a few years of being used only by a small number of early adopters.
There are two ways new technology gets introduced: the organic growth method, and the big bang method.
If you can keep hope and worry balanced, they will drive a project forward the same way your two legs drive a bicycle forward.
Users are a double-edged sword. They can help you improve your language, but they can also deter you from improving it.
The difference between design and research seems to be a question of new versus good. Design doesn't have to be new, but it has to be good. Research doesn't have to be good, but it has to be new. I think these two paths converge at the top: the best design surpasses its predecessors by using new ideas, and the best research solves problems that are not only new, but worth solving.
Note: 4th wave. research and design
What do you do differently when you treat programming languages as a design problem instead of a research topic? The biggest difference is that you focus more on the user.
A good architect, for example, does not begin by creating a design that he then imposes on the users, but by studying the intended users and figuring out what they need.
Note: imposition = 3.0
You're most likely to get good design if the intended users include the designer himself. When you design something for a group that doesn't include you, it tends to be for people you consider less sophisticated than you, not more sophisticated. And looking down on the user, however benevolently, always seems to corrupt the designer. I suspect few housing projects in the US were designed by architects who expected to live in them. You see the same thing in programming languages.
To get good design you have to get close, and stay close, to your users. You have to calibrate your ideas on actual users constantly. One of the reasons Jane Austen's novels are so good is that she read them out loud to her family.
In the software world, this idea is known as Worse is Better. Actually, there are several ideas mixed together in the concept of Worse is Better, which is why people are still arguing about whether worse is actually better or not. But one of the main ideas in that mix is that if you're building something new, you should get a prototype in front of users as soon as possible.
What made oil paint so exciting, when it first became popular in the fifteenth century, was that you could make the finished work from the prototype.
Morale is key in design.
This is a good plan for life in general. If you have two choices, choose the harder.