Skip to main content

Posts about work

Academic culture shock

I think I'm suffering from academic culture shock. The two sides of the Atlantic seem to have very different views of undergraduate teaching. From my Canadian standpoint, UK universities seem to have shockingly little regard for (what I would consider to be) one's duties to one's students -- from administrative staff, as well as from teaching staff.

Before I continue, I guess I should admit that I'm only basing this on what I've seen from half a dozen courses in one department at one university in the UK, plus a few discussions with students in other departments (but at the same university). So I guess one should take it with a grain of salt.


I think the best way to sum it up came from a Discworld book. I can't remember the exact quote, but it was something like: "Professors put students in close proximity with books, in the hopes that something would flow from the latter to the former. Students placed themselves in close proxmity to the pubs, for exactly the same reason". The overall attitude seems to be that learning happens somehow, but it's not worth trying to figure out how it happens, how it could be improved, or how to ensure that it actually occurs.

For example, the class schedules are very elastic. In my department, they don't even try to start scheduling the labs until Thurs or Friday after lectures begin. For my 1st year programming class, we only have labs scheduled for the first half of term. We've repeatedly told the person responsible for lab scheduling that we have labs for the entire term, but his only comment (two weeks ago) was that it would be "tricky to fit it in". I have no clue what happens next week. Or the week after? Or hey, maybe it's this week that we lose our scheduled lab times!

From my flatmates, I hear that graduate classes might occur one day, then not for another week, and then they discover that they changed the schedule and they missed a previously-cancelled class that was un-cancelled. They're from the US, so they're also used to regular classes, and find this quite annoying.

I guess it stems from the old style of university, wherein students went to a university to "read" a subject -- meaning that they literally read books, and had lectures as special events. Now, there's nothing wrong with that if the universities are only taking the top 0.0001% of the population (or whatever it would have been in the 16th century). If somebody is truly intelligent, it's not possible to stop them from learning, so it doesn't matter if you make any attempt to teach them at all.

But as 1%, 5%, 10%, and IIRC over 20% of the population goes to universities, you're going to have students who can't teach themselves. Now, I'll be the first to state that universities shouldn't be taking that many students -- everybody would be better off if the technical colleges took the bulk of adult education. Businesses would have better-trained workers for their jobs, the vast majority of non-academic-oriented students at a university would have better skills for their careers, professors could focus more on research, academic-oriented students could get more theoretical/research-oriented instruction, governments would have less people exposed to critical thinking... everybody wins! To be fair, this shift has already started in British Columbia; I'm not claiming to have a new idea here.

But until such thinking spreads -- say, by cutting undergraduate intake by more than 50% -- then I think that universities have a duty to teach. Not just go through the motions of giving the same lectures you've given for the past 10 years and failing 40% of the students, or treating programming labs as an afterthought to the class schedule. If you're going to do it, do it right.


Part of the problem is the department-specific nature of UK universities. In Canadian universities, students take classes from many departments, and switch between majors quite easily. I recall hearing that the average is switching one's degree 4 times throughout an undergraduate degree; that sounds quite believable to me.

As a result, most academic departments in Canadian universities view their first-year classes as being partly a recruitment drive. In most first-year classes, only 10-30% of the students will be specific to your department. The other 70-90% are potential students. And since a great deal of department funding within a university comes from the number of students they have, the department really wants to recruit those students! Of course, they also want to retain their "declared" 10-30%. "Recruitment & retention" are big buzzwords.

But over here, all courses are offered by your department. There's "mathematics for electrical engineers" and "programming for electrical engineers", all taught by the department of electrical engineering, not math or computer science. Students don't have a chance to really see the other departments, so there's not much opportunity for being recruited away. And even if they did want to switch departments, it's quite hard. Oh, there are provisions for switching, but there's a lot of steps. It's almost like getting a divorce -- discuss it with your advisor to see if there's any alternatives, have a cooling-off period, etc. In some Canadian universities, it's as simple as clicking on a few buttons on the web-based administrative system.


Other differences I've noted are much more specific to my previous department and this one -- or even to the instructors of the courses I've TA'd for. For example, everybody knows that you can't learn programming a lecture; the only way to learn it is to do it. At UVic, the course instructors therefore make the lectures subservient to the labs -- they make sure they introduce material to students in the lectures, so that students will be better prepared for the labs. I remember one instructor being very apologetic because I had to teach one lab when students had only received one lecture about relational databases.

But over here, they use the reverse strategy. Students encounter material in the labs first, in the hopes that they can better understand the lecture about that material. This seems completely backwards to me... although I guess it depends on what the goal of the course is. If the goal is to prepare students to understand computer architecture (which I guess is appropriate for an electrical engineering department), then I suppose that focusing on academic knowledge and preparing students for an exam might make sense. It's absolutely terrible for their programming skills, ability to build stuff, and general enjoyment of programming, of course, but I must admit that university courses aren't supposed to be about practical skills (that's the job of technical colleges).

As a result, the lab instructor to student ratio here is half of UVic's. While I was teaching at my old university, I'd handle 28 students by myself with no difficulty. Over here, we need a ratio of 1 lab instructor to 10-14 students. Not just for programming; that's what we did for digital+analog electronics. Now, I never taught breadboards and soldering at UVic, so I can't speak to the difficulty of that... but I'm totally certain that the first-year programming labs could function with half as many demonstrators if the course was run like the UVic courses.

Granted, the problem doesn't only rest with the teaching and administrative staff here. I can't recall having students show up drunk back at UVic, but we seem to get at least one each day over here. I can't fathom the logic... "yeah, this programming class is hard. I know! I'll get smashed before the lab. That'll help!"

But still, I don't really blame the students. I mean, kids will be kids. They're a blank slate when they arrive at university. It's our job to make them less blank. If that means that we need to teach them how to read text (which seems to cause them problems!) or how to think, then that's our job. If students show up drunk, it's because we've let them know (consciously or not) that it's ok to do that. If we were clear about our expectations of them, it wouldn't happen.


All in all, I haven't been very happy with this programming course. I love programming, I love thinking logically, so I want to brainwash the fresh blank minds into loving programming. But after the first week, it was abundantly clear that they weren't "feeling the love". Lots of confusion and frustration... and when I stepped back and looked at the situation, I couldn't blame them at all. I mean, I found the lab sheets to be confusing and boring, and I've been programming for over 20 years and work on program build systems for fun. There's no way that they could work with new programmers.

So I spent the past two weeks totally rewriting and expanding the labs. It's still not ideal, but they're way better than the old ones. I did my best to include all the institutional knowledge+research about teaching introductory programming from UVic. I got my teaching award for teaching programming to economics + business students, so I'd better be able to get (presumably) technically-inclined electrical engineering students up to snuff.

Now, I've written up labs before, but this was my first time designing an entire course -- and all at once! Previously, the instructor would say "ok, we'll do if this week... I was thinking about having the students write an adventure game like Zork." Then I'd say "ok, I spend 2 hours writing up a lab and send it to you around midnight for approval" (UVic was very strict about keeping track of your time spent; the TAs were generally hired for 120 hours each term). I'd go off and do that, then the instructor would (presumably) glance at it and tell me it looked great and that I should upload the lab. A week later, he'd give me a plan for the next lab, and I'd go and do that. But in this case, the only plan I had was the final project -- I looked at each step of the end-goal, figured out what they needed to learn to do each step, and then started trying to figure out interesting+easy exercises from there.

It was a bit similar to writing documentation, which I'm an expert at. Teaching last week was a lot more fun, since I could see how students were finding the new lab sheets. I got daily feedback on my work, which was great! Normally with documentation, I only see the effects of 20 hours of doc work by noticing a reduction in a certain type of questions on the mailing list over the next 3-6 months. Having immediate feedback on my educational work is fantastic. After 2-3 iterations of the course, I'm sure that I'll have a great set of labs.


Speaking of the labs, here's the link. If any programmers want to take a glance at them and let me know about problems, that would be great. We can't change the minefield exercises this year, and it's too late to change labs 1-3. I'm keeping a list of things to change for next year, though.

new labs

Oh, and a special message for my brother: don't complain about the lack of memory and pointers. I totally agree that teaching C without doing pointers is like building a bicycle without wheels, but it's not part of the minefield exercises, and I just don't see how we can find time to cover it. We lost the first two weeks of the labs due to confusion, and since pointers aren't required for the graded labs, I dumped them. I'll be making lots of changes to the minefield exercises for next year (for mao's sake, at the very least we should malloc the game board!), but we can't change these exercises now. :(

Thirty hours later

My plans to managing my LilyPond addiction have been working well. Ten days ago, I began restricting myself to 3 hours a day; I've managed to stick to that. It's been immensely refreshing -- I'm no longer managing a beast with an unending list of problems to work on. Instead, I look at the problems, pick out the most important or most unique (i.e. difficult for other people to work on) issues, and work on those for my allotted time. Other issues are filed away in the bug database, where somebody (possibly me) can work on them later.

Quite apart from the morale boost, this has given me time to get back to my actual research. I have to admit that I was a bit surprised about how easily I got back into it -- I'd forgotten how interesting it was. I'd spent over a month working other stuff, both lilypond-specific, and helping out other people in the lab.


I've decided to reduce my lilypond time to 2 hours a day for the next few months. This isn't part of a gradual withdrawl from lilypond [1]; rather, it's because I have a few conference paper deadlines in April and May, and I want to make sure I do a good job on them.

(I'm not ruling this out at a later stage; it's a great way to force other people to take over your tasks).

So the general rule is 2 hours a day. Any day that I'm not at home (i.e. wake up and sleep at home) is an exception; depending on the circumstances, I might spend more than 2 hours, or not do anything at all. For normal days, my time will be prioritized as mentioned before: urgent emails, mentoring contributors, non-urgent emails, then working on various problems or feature requests.


PS. no, this is not a "new year's resolution"; it's pure coincidence that I switched to 3 hours ten days ago and started looking ahead at what I wanted to get done in the next few months.

Managing my LilyPond addiction

Since it's the end of term, it's time to look back and reflect. When looking back, I see that I have a problem. I seem to be addicted to working on LilyPond.

Like all great addictions, it doesn't even make sense. Yes, I first got involved because I was using it for composition, it was a great piece of software, and I wanted to give back to the community.

After a few years, I stopped composing, as I shifted from music composition into teaching/performance and then into computer science. But I kept on working on LilyPond. In fact, I did more than ever. I kept on doing more and more.

In the past three days alone, I've exceeded 20 hours of LilyPond work. Not "using lilypond for composition", not "using lilypond to generate images for my PhD research", and definitely not "using lilypond to research music notation or presentation or computational aesthetics" or anything research-oriented like that. No, 20 hours of mentoring new contributors, preparing the build system for the new website, getting the 2.12.3 release out, discussing documentation restructuring, etc. No wonder I've barely done 1 week of actual research over the past four months!

This has to change.

I hereby announce that starting tomorrow (21 Dec 2009), I'm only going to do 3 hours of lilypond work each day. That's still 21 hours a week, which is very respectable for a volunteer job. And it's not going to count working on other open-source projects; that time is separate from lilypond time.

My time will be carefully prioritized:

  1. Urgent emails.
  2. Mentoring contributors, new and old.
  3. Dealing with non-urgent emails.
  4. Working on stuff that only I can work on (the Grand Unified Builder, releases, and the website).
  5. Working on complicated stuff that I can do much faster than other people (large-scale documentation rearrangements, build system stuff, etc).
  6. Working on other issues.

I'll record time in 15-minute blocks; when I reach 3 hours, I'll stop for the day. My apologies in advance to any contributors who send me questions after this cut-off; you'll have to wait until the next day. Speaking of that, I define "a day" as "the period between waking up"; my sleep schedule sometimes has no relation to the visibility of the sun.

This will undoubtedly slow down lilypond development -- if we have a lot of new documentation contributors, then I'll be doing less release work. And it would be quite difficult for anybody else to pick up that slack; GUB is a beast to get running.

I make no apology for this; my time is my time, and I consider keeping new contributors happy to be more important in the long term than having more releases or better-quality releases. If anybody wants to volunteer to mentor a few people, that would obviously reduce the burden on me, thereby allowing me to spend more time on releases, the build system, or whatever else occurs at a lower priority level.