## paul graham ### paulgraham,com
summary
you cannot ignore the act of making inherent to “computer science” (even though the author doesn’t like that term)
hackers are the ones who “who are trying to write interesting software, and for whom computers are just a medium of expression, as concrete is for architects or paint for painters”. indeed the what to do and how to do it are very much intertwined in cs-as-hacking
his concept of the beautiful: “to make subtle tweaks to something that already exists, or to combine existing ideas in a slightly new way” (WRITERLY TEXT? NON AUTHOR?)
the eternal test of beauty, though, is time (that’s one way to see it?)
he has quite a fantasized version of what painters and architects do. “You should figure out programs as you’re writing them, just as writers and painters and architects do.”
programming languages are for “thinking through” programs, not carving them in stone (he doesn’t like static typing), but how about production software? that’s the reality of it.
could we actually have multiple phases in the writing of programs? moving between hacker and engineer?
in large companies, hackers (programmers) are seen as the grunt technicians, the code-monkeys. which asks the question of agency in such places, and in such books like software development and clean code
“Writing novels doesn’t pay as well as writing ad copy for garbage disposals. And hacking programming languages doesn’t pay as well as figuring out how to connect some company’s legacy database to their Web server.”
cf. line 14: learning to hack/paint/architect is iterative and by examples
one standard he adheres to is make the program very short
one way to combine modularity and authorship: “The right way to collaborate, I think, is to divide projects into sharply defined modules, each with a definite owner, and with interfaces between them that are as carefully designed and, if possible, as articulated as programming languages.”
he cites empathy as the greatest quality a hacker can have because:
Part of what software has to do is explain itself. So to write good software you have to understand how little users understand.