Great programmers see their work through users' eyes

Paul Graham, a programmer who later trained as a painter, came to think that the gap between capable coders and exceptional ones lay less in raw cleverness than in imagination. Graham argues that some hackers are very intelligent yet struggle to picture the experience of the person using what they build, and that this limits what they can design.

The idea grew, he writes, from rethinking a childhood lesson. Lectures about considering other viewpoints had struck him as pressure to set his own goals aside, so he deliberately avoided the habit.

He later concluded he had been mistaken. "It turns out that looking at things from other people's point of view is practically the secret of success," Graham writes. He adds, "It doesn't necessarily mean being self-sacrificing," noting that grasping how another person thinks does not commit you to serving that person's aims.

For software, he argues, the payoff is direct: "Empathy is probably the single most important difference between a good hacker and a great one." His test is ordinary conversation, how someone describes a technical idea to a person with no training in the field. The weak version, offered at a dinner party when asked to define a programming language, sounds like this: "Oh, a high-level language is what the compiler uses as input to generate object code." That reply leans on terms that mean nothing to the listener.

Good programs, in his account, must be self-explanatory because people come to them unprepared and are unlikely to study instructions first, so the behavior should match a newcomer's first guess. As an example, he points to the original Macintosh as it was in 1985, which stood out because, as he puts it, "it just worked."

The same duty applies to code, which must be legible to future readers, including the author returning after months away and finding the logic unfamiliar. Graham borrows a line from the textbook Structure and Interpretation of Computer Programs as the one line he would have programmers keep: "Programs should be written for people to read, and only incidentally for machines to execute."