The Third Bit

From the announcement:

The University of Toronto Department of Physics hosts Toronto PyCamp 2010. For beginners, this ultra-low-cost Python Boot Camp makes you productive so you can get your work done quickly. PyCamp emphasizes the features which make Python a simpler and more efficient language. Following along with example Python PushUps™ speeds your learning process in a modern high-tech classroom. Become a self-sufficient Python developer in just five days at PyCamp! Conducted on the campus of the University of Toronto, PyCamp comes with your own single OS/single developer copy of Wing Professional Python IDE.

Python, Teaching

From “Proving and Improving Teaching Programming Languages“:

SIGPLAN Education Board has produced a report “Why undergraduates should learn the principles of programming languages”  which was presented at the ACM Education Council meeting.  It makes four claims for why students should study programming languages:

• Students learn widely-applicable design and implementation techniques.
• Many students will need to create new domain specific languages or virtual machines, so it’s useful for them to study what’s known about languages.
• By learning programming languages, students learn new computational models and speed learning of new languages.  ”The best preparation for quickly learning and effectively using new languages is understanding the fundamentals underlying all programming languages and to have some prior experience with a variety of computational models.”
• Students learn how to choose the right programming language for a task.

The problem is that we have empirical support for none of these claims.  People are amazingly bad at transferring knowledge.  People tend to learn about a specific situation and not recognize when the same idea applies in a new situation—or worse, they transfer negatively, mistaking the similarity and using older knowledge in an incorrect way.

Research, Teaching

In 2009-2010, almost 90 students from over a dozen universities across the country earned a course credit by working in teams on a variety of open source projects. Thanks to our friends at Google, O’Reilly, and CACS, the program is going to run again this fall and winter — see this announcement for details, and the new web site for more information.

So, if you are:

• an open source project looking for some talented help,
• a professor in a Canadian computer science department who’d like to help students learn how to work on real software in distributed teams, or
• going to be enrolled in CS at a Canadian university this fall, in your senior year (or grad school), with strong grades and a sense of adventure,

then please give the organizers a shout at admin@ucosp.ca.

Announcements, Teaching

The announcement is a couple of weeks old now (I’m still juggling things as I transition from U of T to Software Carpentry), but Google has released some deliberately bad code to help teach software security. Very cool idea; it certainly raises the bar for our work…  There’s more material here as well.

Teaching

I got email yesterday from Sylvain Thénault, one of the PyLint developers:

I would like to thank you and the team for your contribution to the pylint project! Your students have actually contributed some useful stuff which have been included in pylint. I can’t tell that from all students I had working on my projects… If you have another students team next year, I’ll be happy to work with them

I’m glad we could help; I know the students who worked on the project learned a lot about code analysis and open source development practices.

Teaching

A month ago, I gave myself a mixed performance review for my time at U of T. Turns out a few people think I deserve better: enough to scare the bejesus out of me last night when they all yelled, “Surprise!” It was one of the nicest things anyone has ever done for me, and I’m grateful to everyone for making the end of my time at the university a memory I’ll treasure for the rest of my life. So without further ado, here are the pink hippo cake:

and the plaque listing all the projects my students and I have worked on in the past seven and a half years:

and my daughter, celebrating as only a three-year-old can:

Thank you: Abayomi, Ainsley, Alecia, Amy, Andrew, Aran, Blaaaaaake, Brent, Catherine, Cordelia, both Davids, Delphine, Diane, Dominique, Ellen, Florian, GregL, Clumsy Igor, Irving, Isaac, both James, Jason, Jennifer, Jessica, Jon, Jonathan, Jorge, Justin, Karen, Kristin, Laura, Laurie, Lila, Lilian with one L, Lillian with two L’s, Luis, Madeleine, Maria, Matthew, Michelle, Mike, Miles, Misa, Pat, Rory, Sadie, Sana, Sean, Sukhmeet, Tom, Val, Veronica, Victoria, William, Zuzel, and everyone else who couldn’t be there—thank you all.

Later: so it turns out there’s video as well…

Teaching

Congratulations to Jason Montojo and Jon Pipitone, who have just completed their Master’s degrees in Computer Science at the University of Toronto. Jon was one of my very first CSC49X students in September 2002, and Jason was in the second batch in January 2003. I’m proud to have worked with them, and wish them all the best.

And in other school news, Alecia Fowler is still looking for people to participate  in her web-based study of how people understand maps. If you have a few minutes, and would like to help her help the visually disadvantaged, please send her an email at accessiblemapping@gmail.com.

(And in other school news, I handed in my final set of marks two days ago. Yee hah!)

Announcements, Research, Teaching

The April 2010 issue of Communications of the ACM has an article by Keith Wright titled “Capstone programming Courses Considered Harmful”. Dr. Wright teaches business intelligence courses at the University of Houston-Downtown, and once you get past the three and a half columns of autobiography that he opens with, his thesis is:

1. Enrolment in CS programs is down. OK, no problem so far.
2. “…a lucrative United States career as a generalist professional programmer [is] a thing of the past” because the jobs are being offshored. Hm… OK, it’s not that clear-cut, but I’m still on side.
3. Further, there has been a “…dramatic decline in demand for U.S. programmers over the period from 1974 to 2004.” Uh, what? Oh, there’s a footnote (pg. 126): “Demand for database, ERP, and ecommerce servers skills are on the rise.” I’m confused: does he think that making Oracle, SAP, and WebSphere behave doesn’t count as programming? And even if that’s true, demand for programmers has declined from 1974 to 2004? Crap.
4. “When designing computing curriculums, it is useful to first consider the capstone courses.” Not the way I’d do it, but OK.
5. I need to break the next paragraph down line by line:
   • “Many of today’s capstone courses involve locating real programming projects in the community.” Sure, the good ones.
   • “However, this is often too time consuming.” Compared to what? And why does he think it’s any harder for CS than for the engineering schools (most of which have to include a year-long capstone to keep their accreditation)?
   • “Furthermore, real projects are usually too difficult for college seniors.” Crap. There are projects of all shapes and sizes out there, from porting Django to Python 3 down to tweaking the web site for a local community group.
   • “Other capstone computing courses have students working individually on imaginary projects, giving them a chance to build something they own.” OK.
   • “Unfortunately, this may give students a poor understanding of the real world.” Well, sure, if it’s done badly, and the same can be said of any coursework.
   • “Finally, we do students a disservice if capstone courses give them the impression they are likely to become professional programmers.” Ah, now we come to it…

That last point is, I think, the hinge of the whole article. Wright thinks that most CS graduates are going to go off and do things that aren’t programming (like, you know, building web applications ‘n’ stuff), and that having them do a big programming project in their final year is therefore misleading. His solution?

I believe part of the answer lies in industry best practices like those captured in the IT Infrastructure Library (ITIL) and the corresponding international standard—ISO 20000. So I suggest…that capstone programming projects be replaced with the following internships:

• Service desk (first-line customer support).
• Change management.
• Programming (good to see this hasn’t been thrown out completely).
• Networking (configuring, diagnosing problems, etc.).
• Problem control (by which he means operating system administration).
• Service level management: “Emphasized would be the writing of ethical service level agreements, underpinning contracts, and operational level agreements.” Yee hah, I can feel my heart pounding faster already.

I find it hard to think of a better way than this to drive bright students away from computer science: if we offered the UCOSP students job training for Fortune 500 IT departments, we wouldn’t have any UCOSP students. Yes, a stint on the help desk is a good reality check, and it’s important for computer scientists to realize how confusing our creations are to the 99.5% of humanity who can’t think recursively. And yes, software engineers should know what a service level contract looks like (preferably an ethical one, whatever that means), but computer science is supposed to be exciting, dammit, and Wright’s vision of computing is about as exciting as a vending machine ham-and-cheese sandwich. Compare his ideas with those of real innovators like David Humphrey (who, by the way, has actually tried his out), and it’s painfully clear who’s looking backward, and who’s going to lead us forward.

Teaching

The full title of Kirschner, Sweller, and Clark’s paper is “Why Minimal Guidance During Instruction Does Not Work: An Analysis of the Failure of Constructivist, Discovery, Problem-Based, Experiential, and Inquiry-Based Teaching“. It was published in Educational Psychologist in 2006, but the whole text is available online. If you’re a parent, teacher, or student, it’s well worth a read. From the abstract:

Although unguided or minimally guided instructional approaches are very popular and intuitively appealing…these approaches ignore both the structures that constitute human cognitive architecture and evidence from empirical studies over the past half-century that consistently indicate that minimally guided instruction is less effective and less efficient than…approaches that place a strong emphasis on guidance of the student learning process. The advantage of guidance begins to recede only when learners have sufficiently high prior knowledge to provide “internal” guidance.

A few selections from the main body:

Minimally guided instruction appears to proceed with no reference to the characteristics of working memory, long-term memory, or the intricate relations between them. The result is a series of recommendations that most educators find almost impossible to implement…because they require learners to engage in cognitive activities that are highly unlikely to result in effective learning. As a consequence, the most efefctive teachers may either ignore the recommendations or, at best, pay lip service to them. (pg. 76)

Inquiry-based instruction requires the learner to search a problem space for problem-relevant information. All problem-based searching makes heavy demands on working memory. Furthermore, that working memory load does not contribute to the accumulation of knowledge in long-term memory because while working memory is being used to search for problem solutions, it is not available and cannot be used to learn… The consequences of requiring novice learners to search for problem solutions using a limited working memory or the mechanisms by which unguided or minimally guided instruction might facilitate change in long-term memory appear to be routinely ignored. The result is a set of differently named but similar instructional approaches requiring minimal guidance that are disconnected from much that we know of human cognition. (pg. 77)

None of [this] would be important if there was a clear body of research…indicating that unguided or minimally guided instruction was more effective than guided instruction. In act…the reverse is true. Controlled experiments almost uniformly indicate that when dealing with novel information, learners should be explicitly shown what to do and how to do it. (pg. 79)

After a half-century of advocacy associated with instruction using minimal guidance, it appears that there is no body of research supporting the technique. In so far as there is any evidence from controlled studies, it almost uniformly supports direct, strong instructional guidance rather than constructivist-based minimal guidance during the instruction of novice to intermediate learners. Even for students with considerable prior knowledge, strong guidance while learning is most often found to be equally effective as unguided approaches. Not only is unguided instruction normally less effective; there is also evidence that it may have negative results when students acquire misconceptions or incomplete or disorganized knowledge. (pg. 83)

There are well over a hundred references into the literature. I’m going to have to think hard about how I’ve been teaching, and how I should teach. I’m also going to keep an ear open when my daughter starts junior kindergarten to see whether her teachers are basing their methods on evidence or wishful thinking.

Teaching

On March 24, a post appeared on the Code Anthem blog titled “Don’t Judge a Developer by Open Source“. Since it starts by saying that the authors are big fans of 37Signals, I skipped over it (I’m not), but when links to it started appearing elsewhere, I went back to have a read. The post’s thesis is that judging developers by looking at their open source contributions is a bad idea. I’ve been doing that for several years (and telling my students that they should contribute to open projects in order to get noticed), so I expected to disagree with the post, but that’s proving hard. In order, the author’s points are:

1. It’s an arbitrary distinction.
2. There are smarter ways to spend your time.
3. Requiring open source contributions is sexist.

The first is moot, and the second is arguable, but the third hits home. Open source is overwhelmingly male: depending on how you count, only 1-2% of OS developers are women, compared to 12-15% in the industry as a whole [1]. That means that if OS is your selection pool, in the long run you’re going to drive the proportion of women in programming down.

My “solution” is to address the underlying imbalance by evening up gender ratios in open source, but (a) that’s going to take a long time (particularly because so many men in open source still refuse to acknowledge that there’s even a problem to address) and (b) even the way I’ve phrased it is a sign that I’m reluctant to admit the problem too. As another poster says elsewhere:

If you insist on a lot of experience in a particular male-dominated sub-culture as a prerequisite for a job, that reads as “we prefer [a subset of] men, basically, or at least people willing to work hard to minimise all the ways in which they aren’t [part of the subset of] men” even if you didn’t intend it to and even if you didn’t want it to.

I hope that course projects like those in UCOSP will prove to be a workable middle ground, i.e., a place where young programmers can build their portfolios and reputations without having to worry that some crank is going to be allowed to sneer, bully, or troll without being held accountable. We hope to know soon whether we’ll be able to run the program again this fall…

[1] The article’s 28% is much higher than any number I’ve ever seen quoted elsewhere, and the source the article cites doesn’t cite an original source itself.

Equity, Teaching