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:
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?
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:
- Avoid distractions
- Work in long stretches
- Use succinct languages
- Keep rewriting your program
- Write re-readable code
- Work in small groups
- Don't have multiple people editing the same piece of code
- Start small
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?