Paul Graham recently posted a piece titled "Holding a Program in One's Head"
. His argument is that, "...it's only when you have the code in your head that you really understand the problem," which I agree with. He then goes on to list eight things you can do to achieve this goal, one of which is just plain wrong:
Don't have multiple people editing the same piece of code. You never understand other people's code as well as your own. No matter how thoroughly you've read it, you've only read it, not written it. So if a piece of code is written by multiple authors, none of them understand it as well as a single author would.
And of course you can't safely redesign something other people are working on. It's not just that you'd have to ask permission. You don't even let yourself think of such things. Redesigning code with several authors is like changing laws; redesigning code you alone control is like seeing the other interpretation of an ambiguous image.
If you want to put several people to work on a project, divide it into components and give each to one person.
Everybody's had the experience of wrestling with a bug for hours, then having the solution leap out at them when they're three sentences into explaining it to someone else. Co-authoring code is, I believe, the best
way to understand it and the problem it's supposed to solve, just as teaching is the best way to actually learn something. Gerry Weinberg knew this thirty-five years ago when he talked about egoless programming
;I guess it's a point that needs to be re-made constantly.