By Students, For Students:
Informal Peer Instruction and The
At 3:05 p.m. on January 15, it was -4 degrees Fahrenheit in Madison, WI, with a windchill of -21. Four students from the Engineering Physics Department pulled up weather.com and posed for a very silly victory photo.
They'd just finished straightening up the large Unix teaching lab in the Computer-Aided Engineering building after the last session of a four-day workshop for computational researchers. The four had designed the workshop on their own and served as instructors and coaches for the eighteen participants from across campus (representing twelve research groups in eight different departments, including Biomedial Engineering, Electrical and Computer Engineering, and Engineering Physics). They'd had to turn away would-be registrants because the room only has eighteen computers.
About two months later--nine months after the group they'd started held its first meeting--they did it all over again. This time, they taught more difficult material to thirty-six participants (half brought laptops). One of the instructors' advisors actually enrolled. Their other advisor, I secretly suspect, had his feet up in his office, grateful he hadn't had to teach the mini-course himself.
Full disclosure: one of those instructors was me. I hope that in exchange for the time we've saved him, the recliner-in-question (Associate Professor of Engineering Physics Paul Wilson) will keep me on as his advisee for a couple more months, despite the joke at his expense. I don't really think he'll mind, because the opportunity to play around a little bit is a not insignificant part of why he encouraged us to start The Hacker Within (THW), an "informal, student-led, skill-sharing group" that meets every week or two to talk about a computation-related topic.
The point of this article, though, is not to toot his horn or ours. It's to examine the much more serious reasons why the group was formed and has arguably flourished. The story of THW is an interesting case study in student professional development and informal peer instruction.
Wilson first suggested a group like THW after a conversation with a colleague in computational science. The two were lamenting what for their field has been a perhaps unexpected consequences of the dramatic increase in personal computer usability.
"Students just don't know how to be hackers anymore," Wilson's colleague apparently said. "They no longer have to be." (Note that the usage of hacker here should carry no criminal connotations and refers to "the computer programmer subculture [that] originated in the 1960s in the United States academia" and is marked by "a spirit of creative playfulness and anti-authoritarianism." Yes, that definition comes from Wikipedia; it's hard to imagine a more authoritative source in this context.)
Wilson then developed an analogy to describe the problem more fully:
"In experimental work, there are skills researchers just have to have in order to do their work effectively, like knowing what cables to use to connect different electrical components," he begins. If a student enters a department and wants to work on experiments, he or she is expected to either have those skills already or take the appropriate laboratory class where they're taught.
There exists an analogous set of skills for computational researchers, Wilson continues, but today it's much less likely that incoming students possess them already. Why? Because those skills are no longer prerequisites for simply getting a computer to work. Moreover, there isn't usually an analogous course to which researchers can refer their students in order for them to efficiently acquire these skills.
About the closest thing is a free online course designed by Greg Wilson (no relation), an Assistant Professor of Computer Science at the University of Toronto.
"I spent ten years doing high-performance scientific computing and data visualization and programmed massively parallel computers," Greg Wilson said in a Sept. 6 2006 talk describing the course.
"By the mid-1990s, I realized I was doing more harm than good. Most scientists don't need massively parallel computers. What most scientists and engineers [need] is somebody to teach them how to program, so that they're not wasting hours, days, months, years doing things the hard way."
(Paul) Wilson began referring others to (Greg) Wilson's online content, and eventually decided to plan his own week-long boot camp for the students in his research group. During that session, the hypothetical "Hacker Within" came to personify the urge to build on these new skills and better deploy existing tools and techniques in order to become more productive and accurate computational scientists. Some months later, that moniker served as the natural name for the student group that formed to continue this training mission.
The group has been meeting regularly since June and--thanks to the bump in membership that occurred after they took over teaching Wilson's boot camp as a sort of campus outreach event--may be on the brink of outgrowing their usual meeting room in the Engineering Research Building. The wide variety of past meeting topics (see the list under "Past Events" at hackerwithin.org) is a function of the diversity of interests and experience within the group; their philosophy is that if someone knows about a software tool for, say, data analysis or debugging, there's a good chance others in the group would benefit from a quick tutorial.
That peer training aspect is what drives Milad Fatenejad, the Engineering Physics grad student who led the effort to found the group.
"I had to learn all this stuff myself," he says. "I don't want other people to have to go through that." When you see him teach, you know he means it, and you also begin to realize what's so powerful about the group's pedagogical model.
"I'm meeting a lot of students from outside the department and seeing how they write programs. We're forming a community where anyone who's interested can come and talk about their programming experiences. These people don't have a place to go to talk about what they're doing," Fatenejad says.
And because at most meetings "the instructors" and "the students" are all peers engaged in the same research tasks, the former are especially adept at both pointing out common pitfalls and making suggestions that bear immediate fruit.
By all accounts, participants appreciate the assistance. Feedback from the January boot camp's summative assessment (a technique Fatenejad learned about when he took the Delta program's course "Informal Science Education for Scientists: A Practicum") was generally positive.
"The general intro to the UNIX shell was immediately useful," one participant wrote. "I found myself using commands we learned in the workshop later that afternoon."
The assessment feedback also ended up being rather generative. The attendees' suggestions for more advanced topics helped form the curriculum for the mid-semester follow-up, a "first-principles" introduction to C++ for programmers who had at least some programming experience but were tripped up by this important (and notoriously tricky) language.
But frustrated student researchers aren't the only demographic who benefit from these meetings and workshops about content that most academic departments and software training outfits on campus don't cover. A growing number of their advisors have expressed support as well. They now serve as an informal cross-campus advertising and recruiting network. One investigator even sent the group a job posting to advertise on their website.
The final beneficiaries are the rotating student instructors. Many are academic-track research assistants who don't have lots of obvious opportunities to gain teaching experience. In preparing longer workshops and even single meetings, they get to take a stab at lesson planning, note preparation, sample problem design, and the act of teaching itself. And the materials they develop get distributed online, so remote learners can also benefit. (See, for example, these online notes from the group's recent C++ event.)
"Teaching is something I've always wanted to do," Fatenejad said. "And I've taken teaching courses, but in teaching courses you don't really get to teach except for occasional activities. Running these Hacker Within sessions has helped me realize that I actually like teaching and it's something I really want to do after I leave grad school."
For more information about the ideas in this article:
2) Greg V. Wilson (2006), "Software Carpentry: Essential Software Skills for Research Scientists," http://nanohub.org/resources/1811.
Overview of Wilson's arguments about the need to teach software development skills to research scientists and engineers. Available as audio or video podcast with presentation slides. See also http://swc.scipy.org/ for the lectures from the course itself.