In Peter Seibel’s Coders at Work, I particularly enjoyed a story from Bernie Cosell, who was on the team that wrote the original routing software for the Internet. He was talking about a theme that occurs throughout the book, the idea that a good program is written not just for the computer but also for the humans who may need to understand the program or change it later—including the program’s original author:
At some college they had a two-semester course from September right through May and they had you work on some fairly hard program at the beginning. What they didn’t warn you was in April they were going to make you work on the program again, having now really run you through the hoops on other things. The idea was for you to be stunned at how hard it was to remember whatever it was you thought you understood perfectly clearly just six months ago.
This lesson is inevitable in any programmer’s career: You must write code for an audience, at minimum for the future you. It’s a well-known concept in software development, and is probably said often in various classes. But I suspect it’s rarely learned until the student gets burned by his or her own code, and that’s what the above does safely.
So, to whichever school did it, I thank you on behalf of the students and their future employers.
I wish I had taken a CS class like that.
ReplyDeleteTwice now I've written foundational code that I've had to deal with for the following 8 years.
You ended up hating all of your old code, but this is because of selection bias. If it just works, you never think about it again. On the other hand, if you have to go back & deal with it, you despise it. Regardless of how lapidary it was at the time, it's still hard to remember and it often uses a slightly different idiom than you're currently using. Plus, it's old and slowing you down when you wish it just worked, like all the other code you've forgotten about!