One result of keeping this blog is that, occasionally, I run into a friend socially who shares a thought or insight in response to something I wrote. Sweet! For example, my friend Sasha came over for dinner the other week and brought up the challenge of modern programming and how confusing it is to teach students how to learn and improve as engineers in the context of all the libraries and technologies that are available and appropriate to use in solving real-world problems.
His thought, which I totally agree with, is that one major way programmers improve is to see worked solutions to problems that we have struggled with. And furthermore, when we work on teams we often iteratively improve a design, debating (sometimes fiercely) the tradeoffs along the way. We’re forced to examine, defend, and improve our own work, look for best practices in what others are doing, hold both a big-picture and small-picture view of the problem, and even build new tools or techniques for evaluating code and modeling the problem we’re trying to solve.
But that wasn’t Sasha’s point, it’s just our shared background. The insight he brought comes from a similar practice in a completely different problem domain: art critique. As students in that world will tell you, this can be one of the most painful and difficult processes at first, but ultimately helps one see things more clearly and make progress faster than would otherwise be possible.
So why don’t we do code critiques? Well, in the world of professional programming we have the concept of a “code review” that is focused on finding errors or approving a checkin. But a critique could go beyond correctness, into the realm of tradeoffs and patterns and even style and aesthetics. Wouldn’t that be valuable?
I’m not sure if I’m ready to have everyone put their code up on a wall for the class to walk up to and discuss, but I did take some first steps in that direction earlier this week. I gave anonymized examples of solutions to a problem from a previous class and we discussed pros and cons. Then I had students look back at their own code and write about both good and bad aspects of their implementation decisions. And I got some great responses like this one:
In my clock lab, I had set up variables for each individual time part, for both the main time as well as the alarm time. While writing this would take longer than merely writing an array, I only have to focus on each variable by itself whenever I’m trying to work on it. If I had set up an array, I would have to remember which individual array stood for each part of which time. However, in doing this, I’ve also made my setters and getters for each time part really long, since I would have to address every single one.
And a different student writing about a different part of the problem:
For printing out the time, I chose to consider 3 situations which the outputs of time will be different. One is when minutes and seconds are single digit. Second and third are when either minutes and seconds is single digit. The advantage of this implementation is easy to understand and straight forward. The disadvantage is when there are a lot of possible situations, this method won’t work well because you have to write lots of if statements to consider every possible situation.
One more student, again a different part of the problem:
The advantages of setting up my randomizeTime() method this way is that it allows people to clearly see how the numbers for hour, min, and sec will be randomized. This way, you’ll know for sure that it randomizes the numbers that you want for each variable. You’ll also use less lines this way. The disadvantages of setting up this method this way is that if you have more than one randomize method, like in this Clock lab, and if you were to change the numbers you wanted to randomize it, then you would have to go and change it for each one
I’m realizing now that I could have picked even more challenging aspects of the problem to discuss in class. Maybe next week I’ll devote a longer class period to this process and have the class critique code written by someone in the room!