On office hours

I feel like bitching about something. Let’s see . . .

. . . yeah, office hours; that’ll do.

I ought to enjoy office hours. I’m just a TA, so students generally bring all of their really tough questions — and all of the nasty angst-dripping personal issues — to the prof. I rarely get any complaints worse than grade disputes, and when I can’t resolve one of those amicably, I can always pass the buck to the prof. So, I don’t especially dread office hours.

The other thing is, I love one-on-one teaching. I enjoy sitting down in front of a keyboard (or standing up in front of a whiteboard) with students who want to learn something and working with them until they do. When the lights go on and they get it — that makes my day.

I used to teach labs. I’d get up in front of two dozen students in front of two dozen computers, give a twenty-minute lecture on malloc() or something, and spend the next two and a half hours answering the questions everyone was too shy to ask during my lecture. That was great. Office hours are the next best thing for one-on-one teaching.

So why do I bitch about it?

Well, to start with, I don’t have an office. (TA, remember? This department doesn’t have office space for grad students.) So instead of giving office hours in a comfortable, well-prepared space, I get to saunter over to the undergrad computing labs and hole up amid the incessant drone of students, cell phones, and too-damn-loud iPods.

This would be less of a problem if I had a steady stream of eager students (or hell, let’s not be greedy — panicked and/or resigned students, too) to chat with and — maybe — enlighten. That is, after all, why I give office hours in the first place. Problem is, those students don’t show up. When I give office hours, there’s a better than even chance that no-one will show up. In fact, since I stopped teaching labs and started giving general office hours, I don’t think I’ve seen more than eight different students show up for any given course.

That’s not to say that I’ve only heard from eight or so students. No, I get plenty of email. Quite often, I ask whoever emailed me to come to my office hours for a better explanation (it’s amazing what you can do with a whiteboard and a little bit of interaction). Invariably, whoever it is says “sure”, and promptly forgets about it. I’m not surprised — coming to my office hours is far less convenient than sending me a peremptory and poorly-written email. Pisses me off, though.

I wonder if reminding my next set of students that they’re paying for me to give office hours, whether they show up or not, would get any more of them to come pay me a visit. If they pull the “I’m paying your salary” attitude, I can point out that their tuition pays — maybe — five cents of my wages, toss them a nickel, and call it even.

The really fun part about my office hours — beyond the tedium of the undergrad labs, beyond student absenteeism — is that everyone gets to evaluate them. It never fails: I see half a dozen students over the course of the semester, but all thirty enrolled have an opinion of how I ran my office hours — and scribble it on my evaluation forms.

Preparedness vs. the Just World hypothesis

Let’s begin with a few introductions to the Just World hypothesis (or theory, or phenomenon):

• The Just World Theory by Claire Andre and Manuel Velasquez
• Just World Hypothesis by Liz Carmona et al.
• Just-world phenomenon on Wikipedia

You can probably tell that I find the Just World hypothesis rather disgusting. There’s more to it than the obvious “she were askin’ fer it!” aspect, though: I think a lot of people fall back on a Just World outlook to justify ignoring threats.

Let’s start with one of my favourite hobby-horses:

“Oh, I don’t need to worry about violent crime, I live in a nice neighbourhood.”

I guess there’s something magical about high property values that repels muggers and rapists. Sarcasm aside, this is the Just World hypothesis hidden behind a little bit of middle-class self-righteousness. I live in a nice neighbourhood, which means I deserve to do so. (After all, this is a Just World, and if I didn’t deserve it I wouldn’t live here.) That confirms my opinion that I’m a Good Person. Now, in this Just World, violent crime only happens to those who deserve it — namely, Bad People. Since I’m a Good Person, violent crime can’t happen to me — I don’t deserve it.

Incidentally, put yourself into the mindset of this sort of person if, through bad luck and/or bad planning, they actually do get attacked. They’re not just getting punched in the face: their whole world-view is being violently destroyed.

Now, the problem with this Just World outlook is that it isn’t supported by the data. Consider, for instance, the 2004 Boxing Day Tsunami. Are you really going to tell me that the roughly two million people killed, injured, or displaced had it coming? I find that somewhat difficult to believe.

Just World thinking gets even more obnoxious when it leaks into politics. First, Just Worlders tend to oppose any legislation (or lack thereof) that allows people to deal with problems on an individual basis. Individual preparation is anathema to the Just World mindset: it shouldn’t matter what you do about something, it’s all about whether you deserve it or not. So, Just Worlders crank down on whatever freedoms they can find that let people address their own problems, whether that means smoking pot to deal with chemotherapy or owning a handgun to deal with burglars.

Second, Just Worlders have to address the problems they fear in a nebulous, broad-strokes approach that doesn’t threaten their dessert-based world view. This is where we get shit like Prohibition — instead of accepting personal responsibility for how they behave while drunk, Just Worlders ban alcohol. Now anyone who drinks is obviously a Bad Person (after all, they broke the law!) and deserves what they get.

It’s easy enough to fall into the Just World mindset. It’s a fairly short step from “Failure to prepare on your part does not constitute an emergency on my part” to “You must have made some horrible mistake in preparation, therefore you had it coming”. Preparation mitigates disaster, it doesn’t prevent it. The overriding lesson taught by reality is that shit happens — from the three laws of thermodynamics on down.

But if shit’s gonna happen, you’ll be much happier if you had the foresight to bring an umbrella.

The Beer Diet

You think I’m joking, but I’m not.

Okay, here’s how it goes.

1. You’re going to eat five to seven small meals a day, focusing on meat, fruits, and vegetables. Eggs count as meat. You get to drink coffee or tea if you want, as long as you drink at least four litres of water a day. Oh yeah, and you don’t get to eat out. You have to cook all this stuff yourself.
2. You’re going to lift weights two or three times a week, doing big compound lifts, not fucking around on the curl machine. Each workout has a push, a pull, and a squat. Use whatever rep scheme you want, as long as you get 15-25 reps (total, not per set) on each. On days when you don’t lift, you’re going to get some light exercise to keep your metabolism up and aid recovery.
3. You’re going to get no less than eight hours of sleep every night.
4. If you’ve done 1, 2, and 3, at the end of the day, you get a pint of your favourite beer. I recommend Guinness, Tree’s London Spy Porter, or anything from Flying Dog — but that’s just me.

I’m going to fluff this out, turn it into a book, and find a publisher. How many people do you think will buy a book called “The Beer Diet”? I’m gonna be a fucking millionaire.

(This could just as easily be “The Scotch Diet” or “The Martini Diet”, of course.)

Against fixed syllabi

Have a read at this excellent article on Inside Higher Ed:

• Moving Past Survival by Shari Wilson

I like it, but I have problems with the idea of a detailed, fixed syllabus. (Wilson isn’t quite advocating that, but the attitude comes across in a number of her points.) I dislike detailed, fixed syllabi for the same reason I dislike detailed, fixed software designs: I can’t predict the future.

Here’s an example. The last calculus course I took (on multivariate calculus and ordinary differential equations) was taught by a new prof . . . with a detailed, fixed syllabus. We got behind the syllabus rather quickly, and — just like in software design — every effort we took to catch up to the schedule made things worse. (I didn’t properly learn Green’s Theorem until this year.)

The worst part, though, was the fixed grading scheme. Okay, yeah, students want to know how they’re doing in a course, and fixing a grading scheme is a simple way to do that. But this prof had no idea how hard we found the exercises — after all, he’d been doing this stuff for about a decade: ODEs were pretty simple for him. The syllabus fixed a passing grade at 50%.

After the midterm, the class average was 44%. (I was doing somewhat better, with a 46%.)

Oops. Even in a 200-level class, you can’t fail that many people without the department chair taking notice.

Now, this is all hypothetical: my teaching experience comes from TAing, which means I’ve never had more than fuck-all control over a course syllabus. But reasoning by analogy with software development, I’d prefer a more flexible syllabus.

Okay, going from Wilson’s article, students tend to want to know where they stand in a course, and they tend to want to know what’s coming up next in the course. That’s entirely reasonable. Trying to make the rest of the semester conform to a syllabus you wrote up the night before the first lecture, though: that’s not reasonable.

Instead, I’d like to try an incremental syllabus. Sure, the marking scheme has to be fixed ahead of time — it’s not at all fair to retroactively change the weight of an assignment — but the grading scheme can be more fluid. The only requirement of the grading scheme is that students can figure out how they’re doing at any given point in the course (perhaps by showing up to office hours). Well, that’s an entertaining interpolation problem. Let’s punt on it for now.

I’ll need to make the subject schedule flexible, though. I can see two ways of doing that: either build in some “slack” lectures — with nothing scheduled — every few weeks, or only schedule topics two weeks (or so) in advance. Show up on the tenth, and find out what we’re going to cover on the twenty-fourth. Show up on the twelfth, and find out about the twenty-sixth. Miss a class? No problem, it’s on the course website, with suggested readings and exercises.

Of course, I probably won’t be able to get away with this stuff until I have tenure, so the whole exercise is what you might call academic.

I’m not a mathematician (yet)

My supervisor took a brief look at the math I’ve been studying lately, and asked:

So, how does this affect your dissertation research?

Brilliantly and eloquently, I replied:

Um . . . .

So much for geometric algebra as a topic of primary research. Instead, I’m going to tell you a bit about multiresolution meshes, focusing on level of detail techniques.

Wait, Matt, what’s a mesh?

A mesh is a computer model of a surface, composed of connected polygons — usually triangles, although quads are also fairly popular in some cases. Nearly everything of any consequence in computer graphics is drawn as a triangle mesh.

So, here’s the problem. You have a mesh you’d dearly love to do something with — draw it on screen, maybe, or print it on a 3d prototyping machine, or send it over email to all of your friends.

Trouble is, this mesh consists of roughly six billion triangles. You can’t deal with all of them at once, it’ll just take too damn long. (Impatience is one of the cardinal virtues of the programmer.)

The obvious way to cope with this situation is to simplify the mesh — get rid of triangles that aren’t contributing very much to the overall shape of the mesh and stretch the remaining triangles to cover them. David Luebke’s written a pretty decent survey of mesh simplification techniques (PDF). So you can take your six billion triangle mesh, simplify it by a factor of (let’s say) ten thousand, and get a six hundred thousand triangle mesh. That’s fairly large, but routine. Obviously, the smaller mesh won’t look as good as the bigger one — up close. We’re counting on the idea that the user won’t notice the difference if the mesh is far enough away.

If you want to draw a bunch of these meshes at once, you might create a lot of simplified versions — one at six hundred tris, one at six thousand, and so on. Meshes that are far away from the viewer use the most simplified version. When the viewer gets a bit closer to one of the meshes, you replace it with the six thousand triangle version, and so on. You can get fairly sophisticated with this system alone — it’s how just about every video or computer game handles complex objects.

Let’s get a bit more specific. Suppose this mesh is a computer model of downtown Vancouver. You want to be able to look at fine details close to the camera — a full-resolution chunk of the mesh — but you can’t just draw the whole mesh at full resolution. Now the problem changes — you can’t just simplify the mesh without caring about where the viewer is. The old version is called view-independent level of detail — what we’re after now is view-dependent.

Now, people have been drawing terrain this way pretty much forever (or since the late ’80s, which in terms of multiresolution meshes is basically the same thing). Any terrain model of interesting size is big enough that you don’t really want to draw all of it if you can help it. View-dependent LOD got a bit more general when Hugues Hoppe published a paper on view-dependent progressive meshes in 1997 — short version, a progressive mesh is a (coarse) base mesh, together with a set of instructions telling you where and when to add triangles to (triangle by triangle) turn it into a full-resolution mesh. With a progressive mesh, you can add or delete triangles until you get to exactly the resolution you want — and with a view-dependent progressive mesh, you can do it only where you give a shit.

The problem with progressive meshes is that you rarely want to add (or delete) just one triangle. Remember that six billion triangle mesh? Yeah, getting that down to six hundred thousand tris, one triangle at a time, is going to suck up a lot of computer time. Starting with a six hundred triangle base mesh and adding five hundred and ninety-nine thousand four hundred triangles is a bit better — well, more accurately, it sucks less. The basic problem is this: if it costs you more to simplify your mesh than it does to just work with the large mesh, you haven’t gained anything.  (To be fair, when Hoppe published his VDPM papers, it cost a lot more to draw a triangle than it does now, nearly ten years later.)

The key here is to add (or delete) fairly large clusters of triangles all at once, rather than one triangle at a time. This is, for instance, the approach taken by the BDAM terrain renderer. It works pretty well, but you lose some control over what gets simplified when.

Notice that I haven’t said much (yet) about when to add triangles. You can get pretty much as complex as you want to, but the two basic approaches are:

1. Use as many triangles as you can, up to a set triangle-count limit
2. Use as few triangles as you can, without breaking a set mesh-quality limit

Lately, people seem to be gravitating to the latter, and trying to make sure that all triangles are approximately pixel-sized. The assumption is that modern graphics hardware is efficient enough to fill the screen with pixel-sized triangles sixty times a second. That’s pretty much true . . . if all you want to do is display a single, fairly simple, model. If you want to draw other stuff — special effects in a computer game, for example — you might need to be a bit more clever than that. (And guess what I’m working on now?)

“Self defense” vs. “Personal security”

I’m not a big fan of the term “self defense”.

Usually, when someone starts talking about self defense, they’re thinking of fighting off muggers or rapists or kicking ass in a bar fight. (Either that, or they’re trying to sell you on an overpriced oversimplified combatives course or a flashy sport-based martial arts programme of dubious effectiveness. Most of the martial arts I’ve seen needs a bit of modification to make the transition from wrestling mats to concrete.)

The point is, “self defense” seems to mean “fighting” to most people. That’s an awfully narrow outlook.

As Marc MacYoung ably points out, there’s a lot more involved in not getting hurt or killed than being able to throw a right cross or fire a handgun. Mr. MacYoung puts physical violence at the tip — that is, the smallest part, and that least missed — of a pyramid of personal safety. Being able to kick ass is less important than developing the habits and awareness that keep you out of situations where ass needs to be kicked. It’s hard to argue with stuff like that.

Okay, go read Marc MacYoung’s site for a while. It’s well worth it.

The other thing I don’t like about the term “self defense” is that it’s too passive. You go about your business, and if you’re threatened, you defend yourself. Self defense. Right?

That’s just as narrow as the idea that self defense is nothing more than legally permissible violence. It’s much more effective to take control of — and responsibility for — your situation, and turn it into something that’s less likely to involve, say, an angry drunk guy coming at you with a beer bottle.

Let’s take a broader view.

What I’m calling “personal security” — or just “security” over there on the sidebar — is actively protecting yourself from external threats. When I say “threats” here, I’m not just talking about violent people — I’m talking about anything external that stands to seriously fuck you up if you’re not prepared to deal with it. A pack of bored, high, and aggressive teenagers? Sure, that’s a threat. So is a yuppie in a status-slutmobile yakking away on a cellphone. (Don’t believe me? Try crossing a street in Coquitlam.) Both of them can put you in the hospital — or kill you — if you aren’t paying attention.

Natural disasters are also threats. (Tsunami, anyone?) So are identity thieves, economic recessions, and asshole managers — those three aren’t likely to kill you, but they can sure mess up your week and your economic well-being.

What’s the common thread here? Gain confidence and security through knowledge and preparation. Stay aware of things that threaten your life and livelihood and avoid them as much as is practical. Once you know where the risks are, you’re better equipped to decide whether or not to take those risks — and to deal with them if you do.

Canada’s diet (poorly) criticized

Take a look at this pile of journalistic crap:

• Canadians not eating a balanced diet, report suggests

Looks to me like shallow, crass fear-mongering. Let’s see:

First, the report focuses on fat. “Fat bad!” (Try saying that in a James Hetfield voice, it’s funnier that way.) Limiting fat consumption is, it seems, the biggest deal in nutrition. Protein? Vitamins and minerals? Never heard of ‘em. Essential fatty acids? Oh my fucking god, they’re fat, they must be bad for you!

Come on, that just isn’t so.

The report (or perhaps the report of the report, it’s hard to tell) is so fixated on fat that it neglects to mention the possibility that eating too many junk carbs might possibly be bad for you. I guess I’m better off choking down a cup of white sugar — no fat — than chowing down on a salmon steak. Remember, salmon’s a fatty fish, and fat’s gonna kill ya!

Right. Have these yahoos heard of adult-onset diabetes?

Here’s some serious fuckupery, directly from the article’s focus on fat as the evil dietary mastermind:

The main contributor to fat intake, 15.9 per cent, wasn’t snacks like potato chips, but sandwiches, a group that included pizza, submarine and other sandwiches, hamburgers and hot dogs.

[...]

Sweets such as cookies and doughnuts accounted for 8.5 per cent of fat intake.

See? Chips, cookies, and donuts are good for you. Instead of hard-boiled eggs, hit Krispy Kreme for breakfast. Less fat!

Speaking of breakfast:

Snacks eaten between meals accounted for more calories than breakfast, a meal many people said they skipped.

Every time I hear or read about people habitually skipping breakfast, I have to take a deep breath and remind myself that this stuff isn’t obvious without at least a little bit of study. Come on, people. You’ve been starving for six hours or longer. Don’t you think some fuel would be a good idea? Maybe an omelet and a glass of milk?

So the study’s basically parroting the party line, but even the government can’t fuck everything up. Here’s some concern that’s actually valid:

More than one-third of children aged four to nine did not get the minimum recommended two servings of milk products a day, the study suggests.

[...]

Of children aged four to eight, 70 per cent didn’t eat the recommended five servings of fruits and vegetables. Neither did about half of adults, Garriquet said.

Yeah, that vitamins and minerals thing? Where do you suppose they come from?

Oh, right. Flinstones Chewables. Forget it.

Learning undergrad Computing Science

Let’s start with a brilliant rant from Joel Spolsky:

• The Perils of JavaSchools

Spolsky points out that people who spend their entire undergrad careers writing Java never run into hard enough problems to really teach them CS. (Or maybe that Java isn’t hard enough to weed out the people who really shouldn’t be CS majors in the first place.)

I have a little bit of experience with undergrad Java programmers. Back when I was a precocious third-year undergrad and thought I knew all there was to know about software engineering, I TAed CMPUT 201, our intro software engineering course. 201 used C, C++, and Unix to teach people who knew how to write code (this is a variable, this is a function) how to write programs (this is a module, this is a unit test). The first-year programming courses — CMPUT 114 and CMPUT 115 — had recently switched from Turbo Pascal to Java, so I got to TA a mix of students: some knew Pascal, some knew Java.

The students who’d learned Java in first year couldn’t deal with resource allocation to save their lives. That was something the runtime did for you, or maybe — maybe — a constructor or destructor in a library class. Resource management was Someone Else’s Problem, right up until the point where I wrote “malloc(foo)” on the whiteboard.

More recently, TAing an intro graphics course, I ran into a student who had no clue what pointers did or why his code segfaulted. This guy was in his fourth year, about to graduate. I had to explain stacks and addresses to him. That wasn’t necessarily his fault: I’d be willing to bet that nobody had ever told him he’d have to give a shit about such “low-level” concepts.

These same students are going to spend their first year or two as grunt programmers — er, I mean “Junior Developers” — bitching and moaning about how university didn’t teach them anything they needed to learn.

But that’s not such a big deal: after all, all ANYONE looks at is how well you did. Right?

So what does a bright young undergrad CS major need to learn?

Look, CS programmes can’t teach everything you’ll need to know to do your job. They can’t teach in-depth web development in PHP and Python and Ruby and Perl (in case you get a web-dev job) at the same time they’re teaching database wrangling in a bazillion different dialects of SQL and how to do it in DBI and ODBC and Delphi or whatever toolkit catches your future manager’s fancy (database hacker) and VHDL and C and FORTH (embedded systems) and Java and J2EE and design patterns and the Rational Unified Process (oh, you poor bastard) — just in case you get a job in one of those areas. Further, they can’t teach you about your future employer’s internal APIs and procedures

What they can do is teach you enough different styles of programming to give you a broad grasp of the basic problem: telling a computer what to do.

A friend of mine teaches Haskell and Prolog to generally disinterested third- and fourth-year undergrads. He doesn’t do it because he wants to prepare them to use Haskell and Prolog in the private sector — he does it because until that course, their worlds have been limited to procedural and object-oriented programming in C++ or Java, and they’re going to be screwed if they end up working on a project written in a particularly functional style of Python.

Suppose you’re an undergrad, and all this is making you a bit nervous. If you can’t trust the course requirements to teach you what you need to know, what can you do?

Get as much breadth as possible in terms of programming and symbolic reasoning. You’ll probably have to learn the details in your first few months on the job, so don’t waste time worrying about how you’re not being taught design patterns or eXtreme Programming or whatever the fad-of-the-month is. You want to learn as many programming styles as possible, so that when your manager sits you down in front of a system you’ve never seen before you can say “Oh yeah, pattern-matching, this is a bit like the regular expressions stuff I did in my compilers course” and get to work.

You should probably also take an operating systems course. It’s handy to know about how process environments change and how things like fork and exec work when you’re trying to figure out why your code works fine from the command line, but fails miserably when it’s called by the web server.

That happened to me when I helped judge a programming contest. Hint: initialize your variables. That memory won’t be zeroed when it comes from a lighttpd process that just exec()ed to you.

Besides, OS courses usually teach multiprocess and multithreaded programming, and with all the multicore chips coming out odds are good you’ll have to do some of that.
Take a database course. Pay attention to the SQL, of course, but pay more attention to normal forms. That’s what your data structures should look like.

Take some algebra courses — group theory, rings, fields, linear algebra — and some logic courses. Those courses teach abstract reasoning, and they’ll make you a better programmer.

Take at least one english composition course while you’re at it. You will have to write.

Stay away from area-specific courses — graphics, user interfaces, processor design, and so on — unless you’re dead set on getting a job in the area (or have some credits to spare). Compilers courses are tricky: some of them are low-level nuts and bolts lexer/parser design; some are more abstract formal-languages courses. The latter are better.

I don’t think it’s possible to teach good software engineering practices in a three-month university course. The scope is too small: you’re never going to need to maintain a fifty thousand-line codebase for two or three major and dozens of minor revisions in a single course. The best you can hope for is a brief introduction to design patterns, unit tests, and encapsulation.

All that said, you have to seek it out, not just endure thirty-six one-hour lectures, get a B+ on the final, and hope you learned something.

And when the guy next to you complains that “we’re never going to need this ‘lambda calculus’ stuff in the real world”, smile.