Cluelessness

It is a not uncommon experience in an engineering program to have lectures in which only the lecturer understands the material he's discussing. The class will watch, with varying degrees of attentiveness, as the lecturer attempts to explain concepts that most of the students in the class truly would like to understand, if for no better reason than to not fail the exam. The lecturer will occasionally ask the class if there are any questions, a moment of silence will ensue, and the lecturer will say "great!" and carry on lecturing.

A budding philosopher of mind might, at this point, question my assertion that the lecturer is in fact the only person in the room who understands the material, as the behaviour of the class would tend to imply that they do in fact understand, having declined the obvious opportunity for clarification. I direct this hypothetical philosopher to Berkeley's Treatise Concerning the Principles of Human Knowledge which has little to do with the present discussion, but should at least occupy him while I continue this discussion.

The reason we can infer that the class is indeed not following the lecture is that when the lecturer later asks a simple question there is once again a moment of silence. This isn't the same sort of silence as before, however. It is a rather more pained silence, the sound of a few dozen people realizing that they are expected to know something that they simply don't know. These moments only end when the level of awkwardness has risen to the level where the lecturer is forced to reject the hypothesis that there are students who know the answer but are reluctant to voice it. This realization can come slowly to some lecturers.

This post is not about what happens once the impossible question has been asked. At that point, there is no longer general cluelessness on the part of the instructor or the class about everyone's level of knowledge. The students are still certainly clueless about the lecture material, but that's something that can then be addressed. What I find interesting are the situations in which the question is never asked, where the lecturer never realizes he is alone, and where the students may eventually get fooled into thinking that they're alone in not understanding the material or (even worse) that they do understand the material.

The reason I mention this scenario now is that I happened to hang around after my PHIL 255 class today, talking to some budding philosophers of mind. At that time, some people came in and asked whether they were in the right room for an iGEM meeting. Unbeknownst to me, it turns out that they were. So yes, this whole post so far has been a setup for an iGEM post.

It's not that there was anything particularly clueless about today's meeting (on the contrary, I found it informative and am generally glad I accidentally attended), but there were definitely occasions where the above too-confused-to-question scenario was evident (as usual this becomes obvious only when the question "does everyone understand this?" is followed by "does anyone understand?" — neither of which anyone will answer in the affirmative). Thinking about it, it's almost difficult to imagine an iGEM meeting with new members in which there are not some people who are so lost that they don't even know where to start asking questions (aside from the always versatile "huh?" or "huh?!?" or "*sob*?").

Talking with Dan after the meeting, it's clear that the issue of getting people into biology, math, and programming who are not from biology, math, and programming backgrounds is still problematic. Unfortunately, the odds of someone having an academic program that teaches them everything they need to know to work with all aspects of iGEM is roughly zero (exactly zero unless they happened to be on a different iGEM team), so some teaching is necessary. This is not a new revelation.

What is perhaps a more debatable suggestion is that the lecture format is not the best approach. We talk a lot in iGEM and by 'we' I mean the team leads and advisors. That's fine to an extent, but the point of any student team is that it's not a lecture; it's a group of people getting work done. I knew nothing about our intron project until an hour before the last software meeting when I forced myself to learn it so I could describe it other people. I still might not have done a very good job of it, but I know more than I did, particularly because people who were better informed than me corrected me when I screwed up.

This is my main point. We're trending towards handling new recruits with kid gloves, developing the design behind the scenes, trying to turn every meeting into a lecture, and so on. Throwing everyone into the deep end isn't desirable, but neither is having them sit by the edge of the pool (or even in a classroom nowhere near a pool) and read swimming manuals. We need to give people the opportunity to screw up somewhere harmlessly and early on. Swimming manuals might have their place, but we need to get a shallow end.

I was going to end this post there, but there's one other thing I wanted to mention: this doesn't just apply to new members. I think there's a great deal of value in getting currently active members to describe what the heck it is they're doing in a way that is understandable by other people. It's too easy to arrive in a situation where everyone thinks someone else knows what's going on and no one actually does; we seem to be more on top of this now than before with the "whatever's Dan's position is called" position, but being forced into explaining exactly what you think is just a generally useful exercise.

tl;dr: Don't ask "are there questions?" ask "could you build something with this?" Also, that line in bold.