Cardboard Programmer
(Just by coincidence, this post also has a cardboard theme, but is unrelated.)
A “Cardboard Programmer” is a fellow colleague to whom you explain your current programming problem in the hope that as you give the explanation the solution will come to mind. Your colleague usually doesn’t have to do anything except stand there and listen, which is why some programmers will suggest that a cardboard cutout of a colleague will suffice.
In practice, a cardboard cutout will not suffice. I’ve tried. Apart from the sense of stupidity of talking to oneself, there is a certain lack of intensity in the act of giving an explanation to an inanimate object. The flesh-and-bone (F&B) variety of cardboard programmer is without doubt the most effective. But why?
The most obvious reason is that the F&B can give you quizzical looks if your explanation isn’t up to scratch, so you are less likely to skip details or make too many assumptions. With a F&B programmer you are under even more pressure to be clear and precise, and this in itself is conducive to you finding the solution.
In a way, this is why I extensively document my code. I know this documentation may one day fall into the hands of another programmer who will have the unfortunate task of maintaining it, upgrading it or (however unlikely) repairing it. I picture this person from the future as a F&B cardboard programmer standing at my shoulder, and the last thing I want is some quizzical looks.
Many years ago, as a lecturer, my students learnt that I would fail them for poor documentation, no matter how good the code was. They would complain initially that they didn’t have time to do the code and write the documentation. But in time they found that writing the documentation (preferably first) reduced the overall time to completion, and greatly reduced errors. For me, having to look at thousands of programs submitted by students, it impressed on me the huge importance of clear code with clear explanatory documentation.
I recently had to dig into some legacy code that was sparsely documented and unfortunately it was proving difficult to decipher. After a few hours I found myself trying to explain out loud what I thought I understood. (I was at home; nobody was listening.) This viva voce approach was getting me nowhere. I thought perhaps writing it down would be better, but again that felt like I was talking to myself and it just didn’t have that edge I needed.
Then I thought about using a colleague as a CP via email. Sure, he wouldn’t read it until perhaps the following day, but like code documentation, the pressure of knowing that a competent colleague capable of making quizzical looks would see it…
And so started a short sequence of detailed emails in which I went from total bewilderment, through realization and eventually to solution, which I’m glad to say appears to work perfectly. I’ve had no replies to the emails (yet), though that’s not unusual for cardboard.
Categorised as: Coding