I read this in John Lewis Gaddis's The Landscape of History on the way in this morning:
We are born, each of us, with such self-centeredness that only the fact of being babies, and therefore cute, saves us. Growing up is largely a matter of growing out of that condition: we soak in impressions, and as we do so we dethrone ourselves...from our original position at the center of the universe. [T]he establishment of identity requires recognizing our relative insignificance in the larger scheme of things... [T]hat's what maturity means in human relationships---the arrival at identity by way of insignificance.
That kind of maturity is crucial to being a great programmer. I've had colleagues who could code rings around me, but who treated any criticism of what they'd written as a personal attack, and for whom winning the argument was more important than finding the truth. All of them had stopped learning---they could still absorb new facts, but not new ways of seeing the world.
I think the best way to prevent this is to get students used to reading each other's code, and to having their code read and critiqued by peers (instead of by referees like TAs and instructors). This isn't a new idea---many people have said that students should spend more time reading code than writing it, and that code reviews ought to be an integral part of undergraduate CS education. The problem is that it's prohibitively labor-intensive. I can barely keep up with a group of nine (only half of whom are active on the mailing list); keeping up with a class of 80 or 120 would be physically impossible.
Perhaps this is the real reason people advocate pair programming. It isn't about making sure that everyone on the team knows why the Fribble class has a pair of dictionaries as members; it's about providing a constant reminder that there are other programmers in the universe, and that their view of that universe is as important as yours.comments powered by Disqus