I wanted to point the programmers in the audience at a series of three posts by Mike Taylor of The Reinvigorated Programmer. In the first, he challenges programmers to sit down and see if they can write an implementation of binary search on the first try, without testing. I tried the exercise without reading the whole post last week and tested intermittently, so I blew it. My implementation didn’t work the first time but that’s because I started testing it before it was finished. Or maybe it’s because I suck. I’ll probably give it a try again later when it’s not so fresh on my mind.
If nothing else, the exercise revealed that I’m too eager to start on things for my own good. I started doing the exercise before I read all the rules, and I started testing my implementation before I was done writing it.
He also posted two followups . In the first, Common bugs and why exercises matter, he apologizes for the structure of the first post, which led me to dive in:
The bad: because I produced the Jon Bentley quote from Programming Pearls before stating the rules of the challenge, a lot of people eagerly ploughed straight in, and so inadvertently broke the rules. My bad.
Here’s his explanation of why it’s a good idea to work on exercises like the one he posted, in response to people who argue that it’s useless to write your own binary search routine when perfectly good implementations already exist:
Why would we think that in programming we don’t need to do exercises that are similarly related to our day-to-day work?
I have a hypothesis about that, but it’s not one that’s going to be popular. The boxer, the concert pianist and the sprinter need to be at the absolute top of their game in order to succeed. If the boxer’s not light on his feet, he’ll get beaten up; if the pianist lacks dexterity, he simply won’t get booked, in such a competitive career; the sprinter deals in margins of hundredths of a second. They practice, exercise, do training drills because they must: if they fall to, say, 97% of their best performance, they lose. Could it be that programming is a little too comfortable? Do employers expect too little? Are we content just to stay some way ahead of the pack rather than striving to excel? That’ll work if you’re happy to write Enterprise Beans For The Enterprise for the rest of your career. Not so much if you’re hoping to go and work for Google.
I’ll be blunt. If I were researching a job applicant and found them arguing that doing programming exercises is a waste of time, I’d reject them immediately. Even if you’re not doing programming exercises to improve your skills, you ought to at least know that there’s value in doing them. I don’t want to work with people who don’t take their craft seriously.
In his second followup, he takes on the assertion that the rule against testing the implementation as you work on it is bad. I like the title: Testing is not a substitute for thinking. Here’s his point:
The point is this: testing is only one of the weapons in our armoury, and it’s one that has recently become so fashionable that a lot of programmers are in danger of forgetting the others. Although testing is valuable, even indispensible, it is also limited in important ways, and we need to have facility with other techniques as well.
The entire series is well worth reading if you’re a professional software developer. It certainly shook me out of my comfort zone and made me realize that I could stand to do more basic programming work, rather than figuring out how to glue things together or what the right syntax is in JavaScript to do something I already know how to do in Java or Ruby.
April 25, 2010 at 3:53 pm
Agreed. My programming aptitude has definitely suffered because I don’t sit down often enough to do any kind of semi-formal learning, like taking a few hours to memorize the subtleties of regexp syntax or hacking away on some difficult recursive algorithm to sharpen the mind.
The internet unfortunately encourages this kind of behavior, because docs are often a minute away. Human nature probably has something to do with it as well — programmers’ variety of the paradox of the active user.
I don’t see it as an indication of personal failure, though — we already expect so much of ourselves in terms of lifelong learning — but rather as an encouragement to improve and keep improving.