A great essay from Paul Graham. He says some controversial things, but my sense is that he’s right about many of them. Like how hackers don’t wanted to be managed by non-hackers and how hackers want interesting problems and abhor “nasty, little problems”. I don’t agree with everything – his negative assessment of Java is on very shaky ground and I think that his idea that a company should pick a language like Python because it attracts a certain community is not realistic. It’s true that Perl has more of a “hacker community” than Java but are you going to pick a language because you like people who use vi and emacs or because they’re more likely to read Slashdot? Even if it’s a high-performance database server? Or an embedded system for a pacemaker or a missile targeting system? Or for an application that has more than 5 engineers working on it and you’re planning to maintain it for a number of years and the language is as much about programmers communicating effectively with each other as it is about communicating with the computer and minimizing keystrokes?
If you’re impatient and just want to read his conclusion on how to become a great hacker, here it is:
Can you cultivate these qualities? I don’t know. But you can at least not repress them. So here is my best shot at a recipe. If it is possible to make yourself into a great hacker, the way to do it may be to make the following deal with yourself: you never have to work on boring projects (unless your family will starve otherwise), and in return, you’ll never allow yourself to do a half-assed job. All the great hackers I know seem to have made that deal, though perhaps none of them had any choice in the matter.