In this reprinted <a href="http://altdevblogaday.com/">#altdevblogaday</a>-opinion piece, Naughty Dog ICE Team's Cort Stratton presents an idea for helping students learn how to read, decipher, and work with others' code through round-robin programming.
[In this reprinted #altdevblogaday-opinion piece, Naughty Dog ICE Team's Cort Stratton presents an idea for helping students learn how to read, decipher, and work with others' code through round-robin programming.] Today I'd like to share a half-baked idea for a programming exercise. But first, some context. One day in a high-school art class, our teacher announced that we would be painting a still life. He placed a jumble of random objects in the middle of the classroom and asked us to set up our easels in a circle around it, facing inwards. We began to paint, but after five minutes he stopped us and asked us all to put down our brushes, move to the next easel around the circle, and continue painting right where the previous student had left off. Five minutes later, up and around again. We continued this pattern for an hour, and when the class ended, we had a dozen truly collaborative paintings of the scene; each student had contributed to every painting. Neat, right? And Now, The Half-Baked Idea: Could a similar exercise could be devised for programmers? If so, I'm pretty sure it would be incredibly useful. Programmers: think back to your formal computer science education. If it was anything like mine, every homework project was either implemented completely from scratch or built atop a skeleton framework with a clearly marked, well-documented "your code goes here"-shaped hole in the middle. In a few rare cases, you might have worked as part of a small group, but in most cases your projects were a solo effort. The projects were turned in and graded based primarily on their functional correctness, with little to no attention paid to elegance or maintainability. Once the grade was assigned, nobody ever looked at the code again. This is how programmers are trained. And once they graduate and enter the workforce, what do we do? We put them on enormous teams, drop them into a labyrinthine and dynamic codebase, and tell them "Hey, Feature X needs to be fixed. The original author left the company years ago, so we don't remember exactly how it works. Oh, and a lot of existing systems depend on this code in potentially undocumented ways, so try not to break anything or you'll be in big trouble. Have your fix ready before the weekend. Good luck!" Why do programming classes focus so heavily on writing code, when professional programmers spend at last as much time reading/deciphering code written by others? We need to start exposing programmers to each other's code earlier. Get them used to working as part of a team! Get them used to thinking of their colleagues as clients! Get them used to stylistic critique, and maybe nip some potentially counterproductive habits in the bud! This should sound very familiar to artists and writers, who regularly face brutal soul-crushing peer review at nearly every step of their education, but somehow programmers are allowed to escape with their fragile egos fully intact. And here's where the round-robin exercise comes in. It would need to be tweaked a bit to fit the new medium; I'm still trying to figure out the logistics, but I suspect it should work something like this:
Assign the class the same problem to solve. The problem should have a number of discrete intermediate milestones to solve along the way.
Each student goes off and individually implements the first stage of the problem. Give them a reasonable amount of time to do so — probably at least a day. It should be long enough to make sure that the slower students can finish their implementation, but not so long that the faster students give in to NIH Syndrome and rewrite the entire project from scratch.
At the end of each stage, each student checks in their project to a central repository (because we all took Lisa's article to heart and taught the students how to use source control tools, right?).
Randomly assign every student a different student's solution to stage 1 to use as their basis for a solution to stage 2. The projects should be anonymized as much as possible, to discourage students from directly contacting the original author(s) with questions.
Repeat steps 2-4 as many times as necessary to fully solve the original problem.
Finish up with a group discussion/post-mortem/critique. Here, the students can talk about the challenges they met at each stage of the problem, mock each other's poor implementation decisions. Eventually, let the class degenerate into an open fistfight over variable naming conventions and brace-matching styles.
Do My Work For Me! I'm actually in a perfect position to put this theory to the test: I'm currently teaching a game programming class one evening a week at a local college. I just haven't figured out the right problem yet. It needs to be an interesting multi-stage task, reasonably difficult but not so tough that anybody's going to run into a brick wall, and with enough flexibility at every stage that there's a number of viable implementation approaches. I'm also not really sure how many iterations to run — ideally, enough to drive home the desired lessons, but not so many that it becomes tedious. And frankly, I've also been reluctant to use my own students as guinea pigs… Do you have any suggestions? Please speak up in the comments! [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]
You May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
