The Third Bit

Back in the late 1990s, I volunteered for a while with the CNIB helping a young woman finish off her high school diploma. (She was already in college, but they wouldn’t let her graduate until she’d officially completed Grade 12.) The first course I helped her with was Family Studies, and I remember very clearly how I felt when Question 1 on the final exam began with the words, “Examine the graph in Figure 1…” This course was officially rated “Accessible to the Visually Impaired” by the Ministry of Education, but clearly, somebody hadn’t actually tested the materials. As an answer to the question, she had me write, “I can’t—I’m blind,” but it still took four months of phone calls and letters to get someone to mark that exam out of 75 instead of out of 100.

Jump ahead to the fall of 2010. I had (literally) bumped into a computer science instructor at the University of Toronto who happens to be unsighted, and I mentioned the videos I’d been posting on the Software Carpentry site. He was teaching an introductory programming class; maybe the material would be useful to his students? He hemmed and hawed for a moment, then admitted that he’d actually visited the site, but hadn’t been able to follow the lectures. Yes, there were full-text transcripts of what I was saying, but (and here he actually sounded apologetic) he wasn’t deaf: he was blind. Whenever I referred to a diagram or mentioned “the highlighted bit of code”, he lost the thread. Those diagrams and highlights only existed as pixels, not as some kind of markup that a screen reader or other tool could “render” for him.

Now, take a moment and go pretty much any online education site, like the Khan Academy or MIT’s OpenCourseWare. Close your eyes, and see how much of the lecture you can follow. Some aren’t bad—Prof. Wyn Kelley’s American Literature course, for example, works almost as well on an iPod as it does with video. But every time an instructor actually relies on a diagram to explain something, everyone student who’s visually impaired loses a couple of marks, either because they can’t follow at all, or because the extra time it take sthem to figure it out is time their sighted peers are spending mastering the next topic. Things like the in-browser “code and sketch” tool that John Resig is building for the Khan Academy may look very cool, but what happens to people who can’t look? It’s no good saying, “Let us figure out how to teach online, then we’ll worry about special needs,” because experience shows that adding accessibility after the fact works just about as well as adding security after the fact (i.e., it doesn’t).

Ed-tech’s advocates keep saying that they want to make the best teaching accessible to everyone. Respectfully, they’re not doing that, and as schools rush to get students online in order to save money, people who are already disadvantaged will be left even further behind. I don’t have any answers—I don’t think there are any easy ones—but those of us who can see shouldn’t lose sight of the needs of those who can’t.

Equity, Teaching

Joseph Hellerstein, a professor in the Computer Science department at UC Berkeley, posted an article on his blog a couple of weeks ago titled, “Is Teaching MapReduce Healthy for Students?” His conclusion?

I have begun to think that Google’s MapReduce model is not healthy for beginning students. The basic issue is that Google’s narrow MapReduce API conflates logical semantics (define a function over all items in a collection) with an expensive physical implementation (utilize a parallel barrier).

I had reached the opposite conclusion, so I forwarded the link to a colleague who runs training at a supercomputing center. His response (edited only to fix autocorrect-induced typos) was:

See, this is why by the time students get to me, they have no knowledge of even the most rudimentary concepts of parallelism; existing solutions are insufficiently pure for CS profs. (And yet what they end up learning is Java!? How did we find ourselves in a position where Java is the default, and any attempt to add other things to the curriculum is killed dead because of lack of conceptual purity? We’re raising a generation of CS students who think the world of programming starts and end with a JVM, or for really well-rounded students, some C++…)

I’m not a huge fan of Hadoop, or even MapReduce as a model, but it works really well for a lot of things, and it’s a completely different mental model. Different models which work well in some sufficiently large domain should presumably be Good Things. I’m sorry its runtime semantics cause this guy to cry inside and everything, but life is tough.

If we’re waiting for perfect languages in some domain before teaching them to students (again: Java?) then we’re basically asking those people who task is to eventually build those perfect languages to do so without having any grounding what’s come before. And we’re living the inevitable outcome—endless wheel re-invention, endless grinding gears.

Teaching

Mark Guzdial recently posted another thought-provoking piece on computing education that has some direct implications for a project here in Toronto called Ladies Learning Code (and for other projects Software Carpentry). In his post, Mark summarizes a 1996 paper by Greeno, Collins, and Resnick that summarizes three views of education:

1. Behaviorist: education is a matter of stimulus and response.
2. Cognitive: education is about building and applying knowledge structures.
3. Situated: education is about making people more successful members of a community of practice.

All three views are valid: they all provoke useful questions, make testable predictions, and so on. #2 (which is associated with people like Piaget) is probably the dominant paradigm today, but Mark’s point is that #3 is equally important. Real-world problems are rarely solved by hermits working in complete isolation; instead, we go through apprenticeships, share sub-problems with colleagues, and hang out on Stack Overflow.

So what’s this got to do with LLC? Well, if you’re going to teach people to program, you have to pick a programming language. As a computer scientist, I’m drawn to elegant little languages like Scheme—but that’s paradigm #2 talking. “We must use language X, so that we can focus on fundamental principles that students will use for the rest of their lives” isn’t useful if those students are going to be interacting with people who speak a different language, just as teaching the fundamental principles of grammar and composition in Latin isn’t useful if people are going to work in English or Mandarin.

Mark knows better than anyone that Java is a bad language to use with novice programmers—he and his group have been studying the broader question for years. Despite that, he accepts that computer science students have to learn Java at some point in order to take part in the community of practice that is professional programming. It’s an echo of Joel Spolsky’s argument that every serious programmer has to learn C: other than examples in class, I haven’t written any C (or C++) in almost ten years, but I simply couldn’t take part in some discussions with my peers without knowing what structs and pointers are.

I personally think that Javascript is a less-than-ideal language for teaching novices: it violates the Principle of Least Astonishment almost as often as Inglish speling. Despite that, I think it’s the only sensible choice for something like LLC: like it or not, it’s the lingua franca of the web. If the goal of LLC is to get participants to the point where they can bootstrap themselves in the time they can actually spare for this (remember, they all have jobs and families—they’re doing this on the side), then Javascript’s flaws are less significant than its community and utility.

This still leaves a lot of questions, of course. Should it be taught language-first, or should libraries like jQuery be introduced right from the start? What about things like Processing.js: after all, Guzdial’s research shows that a media-first approach attracts and retains a wider range of people. I think trial and error is the only solution, but even the “errors” will be useful and fun, and how often can you say that with a straight face?

Teaching

That was my daughter’s reaction when I came downstairs in a suit on Friday morning .  But it was all in a good cause: Zuzel Vera Pacheco and Mike Conley, my last two grad students, received their degrees that afternoon, and I was pleased and proud to be there to shake their hands.

Teaching

I got mail yesterday from a former student of a friend of mine who has just been told that he has to teach an “Intro to Software Engineering” class this fall to a bunch of third-year undergraduates. He’s not an SE guy—his background is operating systems—so he asked me what he should read to get one step ahead of his future students. As regular readers will know, I don’t think much of most traditional software engineering books: I’ve never seen most of what’s in them in the real world, and most of what I’ve needed to know hasn’t been in them.

So what did I recommend instead? Here’s my list:

1. I think that what we prescribe in software engineering should be based on what we actually know from empirical studies, just as it should be in medicine or business, so Making Software is first on the list.
2. Karl Fogel’s Producing Open Source Software is number two, as it’s the best description I’ve ever read of what good developers do day by day (rather than minute by minute: for that, there’s Neal Ford’s The Productive Programmer).
3. I’m also partial to Henrik Kniberg’s Scrum and XP From the Trenches; it’s a bit more ideological, but still packed with lots of “been there, done that, here’s the t-shirt” advice.
4. Reekie & McAdam’s A Software Architecture Primer and Rosenberg & Scott’s Use Case Driven Object Modeling with UML are the two “traditional” books on my list. They’re both slim and uncluttered; the first presents the only useful notation I’ve ever encountered for describing applications’ architectures, while the second explains what the core elements of UML are for and when to use them.
5. Michael Feathers’ Working Effectively With Legacy Code remains the best book about making large systems manageable that has ever been written. It is also one of the few that acknowledges the reality most students will encounter all too soon—that of tangled, poorly documented legacy systems that cannot just be thrown away.
6. Finally, The Architecture of Open Source Applications contains, as far as I know, the only lengthy descriptions anywhere of what software engineering is meant to produce: large, long-lived programs.

I feel a bit uncomfortable listing two books I’ve worked, but my conscience goes back to sleep when I remind it that my frustration with existing books was a big part of why I started Beautiful Code, which in turn led to MS and AOSA. BC is the most wide-ranging of the three, but the other two are more focused. I hope you find them, and all the others on this list, useful.

Later: someone asked why the Gang of Four Design Patterns book isn’t on this list. The answer is:

• Undergrads don’t seem to connect with it—I had much better luck using material Freeman and Freeman’s Head First Design Patterns (but not the book itself—most of my students found its format as offputting as I did). My favorite DP book is Olsen’s Design Patterns in Ruby, which I blogged about a couple of years ago, but since most of my students don’t speak Ruby, I haven’t actually taught with it. Now, if Russ ever does a Python version…
• Software design and software engineering are obviously related, but they’re not the same thing. In my mind, software engineering is how we produce software, while software design is what software looks like when it’s built. Both are important, but trying to cram both into a single course is a disservice to both. (Of course, that’s an argument for not including AOSA in this list either…)

Teaching

Jon Udell’s 1999 book Practical Internet Groupware was a revelation for me: it was the first coherent explanation I’d ever read of how the disparate collection of technologies and social conventions that we call “the web” fit together, and what the deeper patterns and concepts beneath them are. After a lot of further work and thought, Jon has condensed those ideas into seven principles—or as he puts it, “Seven Ways to Think Like the Web“. These concepts are the most meaningful definition yet of what the phrase “computational thinking” actually means, and of what people who aren’t programmers need to know in order to use the web effectively. But it raises a question: what would a high school course that focused on these concepts, rather than on Excel or Java, look like?  Is it even possible?  Is there an equivalent of “Civics 101″ for the web?

Government 2.0, Teaching

I’m three weeks into 2011, and two weeks behind on everything. Where does the time go?

1. I’m supposed to be working full-time on Software Carpentry, but between Jon Udell’s visit, the architecture book (#2 below), and trying to help the professional master’s students find internships (#3), I only booked 19 hours last week. Most of that was spent trying to raise more money, and trying to get people to contribute content. I did get some of the high-performance computing lecture drafted, though, thanks to help from Jonathan Dursi and Andrew Petersen, and I hope to post the first couple of episodes this week.
2. The Architecture of Open Source Applications is winding down, but there’s still a lot of editing to do, and several contributors to chase up (if only to confirm that they’re not actually going to contribute).
3. Last fall, the University of Toronto launched a new M.Sc. in Applied Computing. I finally got to meet the first six students a week and a half ago; they’re an impressive bunch, but I was dismayed to discover that no one had done anything about lining up the eight-month internships that are supposed to be the core of their degree. I’ll post again soon with a longer description of who they are and how they can help move new ideas and technology from academia into the real world.
4. Ellen Hsiang has finished storyboarding the artwork for And Then…, a children’s book about the history of, well, just about everything. We hope to have a draft of the book on the web in about a month.

Tomorrow’s another Monday; let’s see if the week coming up is more productive (sorry, if I’m more productive) than the three gone by.

Architecture of Open Source Applications, Teaching, Uncategorized, Writing

We all know it’s not true, but it’s still a useful story: if you put a frog in hot water, it will jump out, but if you put it in cool water and slowly boil it, it’ll just sit there, because there’s never a moment when it says, “Wow, this is hot!”

As with frogs, so with computing education. This post on “The Collapse of Computing Education in English Schools” could just as well have been written about Canada, the US, or almost anywhere else. It’s been a crisis now for so long that many of us have stopped really noticing how much trouble we’re in—certainly, I see no sign that the people with the power to change things have this on their “must fix” list.

Which makes this post by Mark Guzdial all the more poignant. iPads in the classroom? It’s the kind of thing that gets someone headlines, but if teaching methods don’t change—radically—it will have just as much (i.e., just as little) impact as all the other tech-in-the-classroom wizardry that has failed us over the past century.

We’re about to start another online run of the Software Carpentry course with almost 100 participants from half a dozen countries. A lot of things didn’t work in last fall’s run; we’re hoping to fix some of those this time around, or at least make different mistakes, so that we can learn a little more about how teaching and the web can be adapted to one another. It may not give school trustees a pile of boxes to stand beside at a photo op, but changing practices is a lot more important than any number of shiny new toys—and a lot harder.

Software Carpentry, Teaching

After cursing PowerPoint for eight solid months while building screencasts for Software Carpentry, I think I have figured out what I want instead. Here’s a top-down view of a PowerPoint slide (drawn, ironically, with OmniGraffle):

Here’s the same slide seen edge-on:

The vertical axis in this view is time: all of the objects in the slide are created when the slide is created, and are cleared away when we advance to the next slide.

When I’m presenting in person, I budget roughly three minutes per slide. I don’t worry about losing the audience’s interest by keeping a static image up for that long because I’m a fairly animated presenter: I point at things, walk back and forth, make eye contact, and so on, all to provide the motion and flow that my slides don’t. Many good presenters, though, prefer to keep things moving on screen as well, and PowerPoint supports that by allowing items to be revealed progressively. If we do that, the side view looks like this:

When I first started creating screencasts back in May, I quickly realized that my “static slide for three minutes” style didn’t work: unless something was changing on screen every 15 seconds or so, viewers’ attention would wander. I experimented with using progressive reveal in PowerPoint, but discovered three shortcomings. First, there is no easy way to sync my scripts (written in the notes portion of the slide) with the reveal of particular elements. Second, when slides are exported to PNG or PDF, the progression is lost—everything comes out together. Third, there’s no way for an element to span several slides: PowerPoint insists on a strict slide/object hierarchy.

The third point is the key to what I want instead. I want to be able to create “slides” like this:

Here, there’s no longer a notion of “a slide”. Instead, there are graphical objects with lifespans, and slides horizontally across the timeline that display whatever is “alive” at that moment. This model seems better suited to creating screencasts (or other continuous video), and I suspect it would be better for traditional live presentations as well (particularly if it was possible to modify the properties of objects as a function of time, e.g., to change an object’s location between one snapshot and another).

I think I could create something like this in an image editor that supported layers (one layer per object) and scripting (to turn layers on and off), though that would be a fairly clumsy user interface. A more elegant one doesn’t feel like it would be hard to design, but I’m hoping someone has already built this for me. If so, I’d welcome pointers.

Teaching

Yet another good post from Mark Guzdial pointed me at an article in The Economist about the value (or otherwise) of a PhD. Key stat (bold emphasis mine):

A study in the Journal of Higher Education Policy and Management…shows that British men with a bachelor’s degree earn 14% more than those who could have gone to university but chose not to. The earnings premium for a PhD is 26%. But the premium for a master’s degree…is almost as high, at 23%. In some subjects the premium for a PhD vanishes entirely. PhDs in maths and computing, social sciences and languages earn no more than those with master’s degrees. The premium for a PhD is actually smaller than for a master’s degree in engineering and technology, architecture and education. Only in medicine, other sciences, and business and financial studies is it high enough to be worthwhile. Over all subjects, a PhD commands only a 3% premium over a master’s degree.

Research, Teaching