Paul Graham’s definition of a hacker is mostly compatible with Steven Levy’s. In “Good Bad Attitude,” for example, Graham mentions hackers’ disdain for locks, copyrights, and other mechanisms that stifle collaboration and innovation. This theme appears numerous times in Levy’s book, and with the same two reasons for lock-breaking: for the pure challenge and as a form of resistance to what they see as “a threat to … intellectual freedom.” For instance, Levy writes about the MIT AI Lab hackers who would pick literal locks for the challenge and to borrow tools and ideas (never with malicious intent) and the Homebrew members who distributed illicit copies of Bill Gates’ Altair BASIC.

Graham discusses both hackers and nerds but never explicitly distinguishes between them; his “nerd” is similar to Levy’s “hacker” in that both are motivated by something unconventional: to make themselves better at something for the primary purpose of just being better at it. For nerds, this can be any broad academic or technological pursuit, while for hackers it is specifically working with computer software or hardware. In a way, Graham takes Levy’s hacker persona and splits it into poor social habits (which he assigns to nerds) and love of working on computers (which he assigns to hackers). This is more appealing to me than Levy’s book, where at times he seemed to imply that one must throw personal hygiene and a social life out the window to be a true hacker. I greatly enjoy working with computers, but I also want a life of friends, family, hobbies, and relaxation.

Graham’s description of hackers as “painters” resonated with me and put into words something I had never really been able to express about why I enjoy working with computers. The creative freedom that computer scientists have when doing their work is significantly more than most scientists and many engineers, who are limited by natural laws and experimental precedent. I have taken a number of classes in the natural sciences, and I always felt limited by the fact that our practical work (i.e. labs) was merely following a set of instructions to replicate already-known experiments or results. I know that there is a great deal of cutting-edge scientific research going on, but the bar for entry is quite high.

Even the very early coding that a CS student or a hacker does (besides copying something from a book or a professor) is fairly original and novel because there are so many choices to be made and so many valid ways of doing things: what language to use, what to name variables, what paradigm and/or algorithm to employ, and how to break up the problem into distinct parts. Different methods are fairly objectively worse than others, to be fair; I look back on early programs that I wrote and cringe at the disorganization and lack of scalability of that code. But I learned by starting at that level (the fact that an ugly program still works was instrumental in boosting my confidence) and refining my techniques by doing. I read about best practices and I looked at other people’s exemplary code, but mostly I learned by writing a whole lot of code myself. I learned to write code that is pleasing to look at (at least, I think so) and maintainable and efficient.