Hackers & Painters: Big Ideas from the Computer Age

by Paul Graham

if languages vary, he suddenly has to solve two simultaneous equations, trying to find an optimal balance between two things he knows nothing about:

Within the hacker subculture, there is another language called Perl that is considered a lot cooler than Java.

Each one is progressively more like Lisp.

the short explanation of why this 1950s language is not obsolete is that it was not technology but math, and math doesn’t get stale.

As a rule, the more demanding the application, the more leverage you get from using a powerful language.

These guys entered a market already dominated by two big, entrenched competitors, Travelocity and Expedia, and seem to have just humiliated them technologically.

The core of ITA’s application is a 200,000-line Common Lisp program that searches many orders of magnitude more possibilities than their competitors, who apparently are still using mainframe-era programming techniques.

But if you control the whole system and have the source code of all the parts, as ITA presumably does, you can use whatever languages you want. If any incompatibility arises, you can fix it yourself.

In server-based applications you can get away with using the most advanced technologies, and I think this is the main cause of what Jonathan Erickson calls the “programming language renaissance.”

If a company considers it self to be in the software business, and they’re writing an application that will be one of their products, then it will probably involve several hackers and take at least six months to write. In a project of that size, powerful languages probably start to outweigh the convenience of pre-existing libraries.

The third worry of the pointy-haired boss, the difficulty of hiring programmers, I think is a red herring. How many hackers do you need to hire, after all? Surely by now we all know that software is best developed by teams of less than ten people. And you shouldn’t have trouble hiring hackers on that scale for any language anyone has ever heard of. If you can’t find ten Lisp hackers, then your company is probably based in the wrong city for developing software. In fact, choosing a more powerful language probably decreases the size of the team you need, because (a) if you use a more powerful language, you probably won’t need as many hackers, and (b) hackers who work in more advanced languages are likely to be smarter.

You can’t let the suits make technical decisions for you.

What seemed like an anomaly to them was in fact cause and effect.

If you start a startup, don’t design your product to please VCs or potential acquirers.

Code size is important, because the time it takes to write a program depends mostly on its length. If your program would be three times as long in another language, it will take three times as long to write — and you can’t get around this by hiring more people, because beyond a certain size new hires are actually a net lose. Fred Brooks described this phenomenon in his famous book The Mythical Man-Month, and everything I’ve seen has tended to confirm what he said.

As one data point on the curve, at any rate, if you were to compete with ITA and chose to write your software in C, they would be able to develop software twenty times faster than you. If you spent a year on a new feature, they’d be able to duplicate it in less than three weeks. Whereas if they spent just three months developing something new, it would be five years before you had it too.

when it comes down to it, the pointy-haired boss doesn’t mind if his company gets their ass kicked, so long as no one can prove it’s his fault.

Within large organizations, the phrase used to describe this approach is “industry best practice.” Its purpose is to shield the pointy-haired boss from responsibility:

I believe this term was originally used to describe accounting methods and so on. What it means, roughly, is don’t do anything weird.

what “industry best practice” actually gets you is not the best, but merely the average.

Number 1, languages vary in power. Number 2, most managers deliberately ignore this. Between them, these two facts are literally a recipe for making money.

If you want to win in a software business, just take on the hardest problem you can find, use the most powerful language you can get, and wait for your competitors’ pointy-haired bosses to revert to the mean.

A hacker would consider being asked to write add x to y giving z instead of z = x + y as something between an insult to his intelligence and a sin against God.

Good programmers often want to do dangerous and unsavory things.

A good programming language should have features that make the kind of people who use the phrase “software engineering” shake their heads disapprovingly.

Inventors of wonderful new things are often surprised to discover this, but you need time to get any message through to people.

Early adopters are sophisticated and demanding, and quickly flush out whatever flaws remain in your technology.

There are two ways new technology gets introduced: the organic growth method, and the big bang method.

Generally, the garage guys envy the big bang guys.

Organic growth seems to yield better technology and richer founders than the big bang method.

The most important part of design is redesign.

You have to be able to think how hard can it be? with one half of your brain while thinking it will never work with the other.

You want to be optimistic and skeptical about two different things. You have to be optimistic about the possibility of solving the problem, but skeptical about the value of whatever solution you’ve got so far.

People who do good work often think that whatever they’re working on is no good. Others see what they’ve done and think it’s wonderful, but the creator sees nothing but flaws.

If you can keep hope and worry balanced, they will drive a project forward the same way your two legs drive a bicycle forward.

It’s tricky to keep the two forces balanced. In young hackers, optimism predominates. They produce something, are convinced it’s great, and never improve it. In old hackers, skepticism predominates, and they won’t even dare to take on ambitious projects.

choose your users carefully, and be slow to grow their number.

Having users is like optimization: the wise course is to delay it.

Introducing change is like pulling off a bandage: the pain is a memory almost...

It’s so much work to introduce changes that no one wants to bother.

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.

Notice I said “what they need,” not “what they want.”

I don’t think you can even talk about good or bad design except with reference to some intended user.

One of the reasons Jane Austen’s novels are so good is that she read them out loud to her family.

Morale is key in design.

Building something by gradually refining a prototype is good for morale because it keeps you engaged.

always have working code.