This is part of the required reading for software carpentry instructor training. While reading it occurred to me that it might also be interesting material for lobste.rs.
This is part of the required reading for software carpentry instructor training. While reading it occurred to me that it might also be interesting material for lobste.rs.
“Software carpentry” is an interesting term that betrays some interesting ideological positions. The first time I heard that term is from Kevin Sullivan at UVa, who uses it to differentiate his class from JavaSchools (software “carpentry” vs software “engineering”).
He teaches CS1 (a mixed class of majors and non-majors) in Idris. I was skeptical at first (Idris? for freshmen?), but the resulting retention rate and “switching intended major to CS” rate were really impressive.
Unfortunately, I can neither remember these numbers off the top of my head, nor find where they’re posted online, but I think it raises an interesting question:
Note that software carpentry is specifically for teaching students in the sciences skills for computational competency, not CS students. I think “carpentry” is an appropriate phrase to use for the sorts of computing grad students in the sciences typically need to do.
Yeah, I think this is exactly the way in which Kevin Sullivan uses it too: He used to say that when building a house, you have carpenters and you have civil engineers. Usually you have both, but they each have their roles and the engineer better be able to know carpentry when necessary, but mostly shouldn’t be a carpenter — but most of the time when you’re a carpenter you’re not building a house or any such large ambitious project that lots of people work on and depend on. Unlike civil engineers, carpenters are more likely to have their own practice and most carpenter-hours are spent (perhaps not anymore with the rise of automation, but for the metaphor…) building furniture by themselves and a few other people.
Ideally, we could answer the question I raised simply with “it depends”. Clearly if someone wants to be a carpenter, you should teach them carpentry, and if someone wants to be an engineer, you should teach them engineering, etc.
But when you have these massive almost “one-size-fits-all” CS1 classes (especially somewhere like UCSD mentioned in the OP, where every year, the department asks for a better student-to-faculty ratio, and every year, the administration sends us students faster than we can hire faculty) it’s not clear at all. Some of your students will go on to be carpenters, some engineers, some scientists, and they don’t know which yet.
And even for the sciences, it’s not always cut-and-dry. Nearly every proteomics grad student is a carpenter, but what does a physicist do? Still mostly carpentry, but there’s also these giant legacy projects in Fortran 77 that you wish involved more engineering and less carpentry. I haven’t been a physicist for a little while, but I have no doubt that there are more of them piling up every day. So we’re doing the right thing teaching scientists carpentry, but it seems that perhaps one of every few should probably still be an “engineer”.
Once I added the term “software carpentry” to my vocabulary, these sort of concerns became immediately visible! It’s a powerful concept that packs up a surprisingly large amount ideas about the structure of writing code itself.
Just for the record, the mentioned instructor training references are at the end of this page. I love Software Carpentry’s work teaching computing skills to researchers. Their motivations are best explained in this paper: Best Practices in Scientific Computing.
Greg Wilson and collaborators also recently published Good Enough Practices in Scientific Computing
This is deeply ironic–in my experience the benefits of pairing in an industrial setting are more about learning and sharing knowledge than they are about pure productivity, so this question just seems backwards to me.
There are many premises in this article that I don’t agree with.
Writing is asocial. People see it as being about sitting with a cup of coffee and smashing words together for hours on end, and that’s just not attractive.
Math is asocial. People see it as being about making marks on the blackboard that almost never amount to something but, once every few months, deliver a creative breakthrough that leaves colleagues stunned– if your findings haven’t been scooped by someone else– and that’s just not attractive.
See what I’m doing here? I don’t buy it. In most interesting fields, solitary focus is key and that shouldn’t be scribbled out because we want to believe that we’re all about teamwork in this world.
I realize that the article refutes this point, but I actually think that computer science is going to be irrelevant to most people until they have an interest in programming. Kids should be playing with robots in Python, not having Idris books dropped on them. Even for those of us who like the deep, mathematical stuff, the things that one can do with computers are the hook.
I never saw it this way, and I especially don’t see it that way now. I have no idea whether I was in the top of my CS classes. My letter grades were strong so I’m guessing that I was in the top half, but beyond that, I haven’t a clue and it doesn’t matter.
Competitive grading (“bell curve”) has its problems, but my general observation is that the good students don’t think about the competition. If you legitimately learn the subject at a deep level, the odds are good that you’ll get a good enough grade– and if you don’t, it’ll be due to some external issue like a health problem and not the other students. Of course, I recognize that it doesn’t always feel this way to an anxious teenager since we’re practically primed to freak out over small things (prom, grades, losing virginity before a certain milestone) at that age.
On the more general topic, I’m not sure that passing more students should be the objective function. I do think that we have to find a fair way of handling the bimodal distribution of incoming student experience, but I’m not sure that it’s a travesty that 30% of students fail (especially in the modern university where most people who fail get to “late drop” and it disappears from the transcript instead of being an F.)
If anything, 70 percent is a generous representation of what the world is actually like. If the corporate world had a 70% pass rate (70 percent of projects actually produce something, 70 percent of people get promoted at least once before being laid off or managed out, 70 percent of executive hires do their jobs well, 70 percent of subordinate hires are given a chance) we’d be ecstatic.
Pair programming: it works for some people. For others, it’s a waste of time. When people choose to pair voluntarily, I think that it’s a good thing. I’d also apply this to students: if you want to work in pairs on your homework, please do. If studying in groups helps you, go ahead. If you do better at 5:30 in the morning when there are no distractions, then do that instead.
As for corporate forced pair programming, it’s mostly a performance-management technique (like most of Agile, which is dressed up in impersonal terms, but actually a way of punishing a team when there’s a perception of at least one bad performer) for when the bosses think that people are slacking and want to use social pressure to get a few hours of honest work out of people. I don’t see a reason to replicate that in education, because if people are slacking, it should show in their grades.
This is not to say that we couldn’t benefit by making CS education more social. There’s a perception in our society that exams have to be (and “have always been”) individual written tests, even though those are a fairly new invention in the West. Exams in the pre-war period were mostly oral: debates, presentations, group discussions. The main reason we moved to written exams is a combination of scalability and fairness (insofar as interview-style “exams” for, say, educational admissions and civil service exams were, at best, biased in favor of pre-existing cultural capital and, at worst, subject to corrupt evaluation with no audit trail of actual performance).