BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Holding a Program in Your Head

Holding a Program in Your Head

In a recent essay titled "Holding a Program in Your Head", Paul Graham - essayist, Lisp hacker, and the creator of Yahoo! Stores - argues that "your code is your understanding of the problem you're exploring. So it's only when you have your code in your head that you really understand the problem." Unfortunately, as every programmer knows, this is easier said than done:
It's not easy to get a program into your head. If you leave a project for a few months, it can take days to really understand it again when you return to it. Even when you're actively working on a program it can take half an hour to load into your head when you start work each day. And that's in the best case. Ordinary programmers working in typical office conditions never enter this mode. Or to put it more dramatically, ordinary programmers working in typical office conditions never really understand the problems they're solving.
So what can a developer do to get a program loaded into their head? Graham offers eight suggestions:
  1. Avoid distractions
  2. Work in long stretches
  3. Use succinct languages
  4. Keep rewriting your program
  5. Write re-readable code
  6. Work in small groups
  7. Don't have multiple people editing the same piece of code
  8. Start small
Agile processes and practices can be viewed as a mapping of what happens organically in a successful startup company to what can possibly be done within a large organization. As a partner of the seed investment firm Y Combinator, Paul Graham targets most of his advice towards small startup companies, and so the question becomes which of these best practices map to agile practices. Certainly most agile developers are accustomed to writing re-readable code, continually refactoring, working in small groups, and starting with the smallest thing that provides real value. And many agile developers are increasingly moving towards more powerful languages such as Ruby, Erlang, Haskell, or even Common Lisp.

But what about those suggestions that don't easily map to agile practices? (1) and (2) go hand-in-hand, and some would argue that working in a shared lab space is the antithesis of avoiding distractions. Another common agile practice is shared ownership of code, contradicting (7). So do the agilists have it wrong? Or does the conflict between these recommended practices reflect the unavoidable differences between working for a small company and working for a large company?

Rate this Article

Adoption
Style

BT