R. Clayton (rclayton@clayton.cs.monmouth.edu)
Wed, 17 Jan 2001 19:01:09 -0500 (EST)
A couple of people have asked me what they should do to prepare for 505 next
fall. I told them they should practice programming. What I'd like to do in
this message is elaborate on that and make an offer.
In one sense, learning to program (or learning to program well) is like
learning to play a musical instrument. What do you do when you're given a new
piece of music and you struggle and fight you way through it the first time?
Do you toss the music and go on to the next piece? No - you go back and play
it again. And again, and keep practicing it until you can do a reasonable job
playing it (Wow - that speech by Jon Bon Jovi was more influential than I
thought).
You should write programs the same way you would practice music. Once you
write a program, don't toss it aside and go on to the next program; look at the
program and ask yourself "how is this program bad?" and "how can I fix it to be
less bad?" Then, rewrite the program so it's less bad. And then look at it
again, and rewrite it again, and so on.
In particular, what you should do is go back and redo the first assignment.
Most of you know more now then you did when you wrote the first assignment, so
it should be easy to figure out why your program's bad, and it also should be
easy to re-write it to be better. Once you've done that a couple of times for
the first assignment, go on to the second assignment, and so on.
I should emphasize that this recommendation applies to everybody in class, not
just those that didn't pass (in some sense) or just to those going on to 505.
A program either works or it doesn't, and if it doesn't do one thing right then
it doesn't work (as I asked one of your colleagues: "how much would you pay for
a program that core dumps on this input?"). Much like being a professional
musician, being a professional programmer means you have to practice to keep up
you skills.
Now for the offer. I mentioned a couple of times in class that one of the most
valuable ways of judging programs is in informal code reviews. Because I'll be
around for the summer, I'm willing to hold informal weekly code reviews. The
way it would work is everyone involved would rewrite each assignment and then
meet once a week to present and explain their code. Everybody else would
critique it. If you're interested, send me e-mail with a couple of preferred
two-hour time slots for meeting times.
This archive was generated by hypermail 2.0b3 on Thu May 17 2001 - 12:00:05 EDT