I did… what?

Last year I set an assignment where I asked students to reflect on their semester of assignments and tell me about their software development process. As I believe I’ve already mentioned, the assignment was answered with thoughtful and generally well written answers. One student’s response stood out and I reproduce it, anonymously and in part, here:

“I assessed the difficulty of the pracs each week by reading through the instructions and taking a guess [at] how difficult it would be and how long it would take. I was actually pretty accurate with these guesses (except for a few unforseen bugs that didn’t set me back much). I even did an okay job assessing the time it would take me to do the library prac. And then I ignored that assessment and skimped on the design and didn’t start it until a few days before it was due. [My bolding] I’m not entirely sure what I was thinking there, I was probably just dreading the prospect of doing such a large prac.”

I find this comment fascinating because we are currently listening to one of the top students of the class going through a thought process that is, effectively, “I did… what?” The library prac was the hardest programming assignment of the semester. Two weeks duration rather than one, complex dependencies, detailed design required to get it right and an assignment where your testing framework was either good enough or next to useless. We’d spent a lot of time building up their coding muscles to handle this but, obviously, we’ve still got a way to go.

One of the best students, who actually scoped the problem properly, looked at the task, worked out what was required – and didn’t do it. In the same assignment where this quote comes from was a question “If you could give one piece of advice to a student starting [this course] next semester, who wants to do well in the [coding assignments], what would it be?” The student in question made a lot of good comments, as he wrestled with the question and tried to pick the best piece of advice.

“Good design (or in fact any design) reduces the chances of making mistakes and creating bugs to begin with, but breaking up code and testing it bit by bit catches the bugs early, before they become a big problem and are harder to find and fix.”

Again, his awareness of his own mistakes appears to be driving his thinking and his writing. He’s move on beyond the “I did… what?” and is now finishing that phrase with “but this is how I’ll avoid doing it again!” He’s explaining to his peers how, from a similar basis, he made mistakes but he’s making fewer now and this is something that they can learn. Yes, he didn’t explicitly address the fear issue that he raises as a possibility, but he does advocate divide-and-conquer, one of the best techniques for conquering something large and scary, so I think he’s addressing the issue anyway.

There’s nothing intrinsically wrong with someone staring aghast at their early coding errors, as long as it’s quickly accompanied by a well-learnt lesson, a scribbled reminder and a silent promise to catch it next time before it becomes a problem!