Want to double your tutoring productivity, or the productivity of your teachers?
As a TA, I realized last year that I spent most of my tutoring time helping students figure out exactly what their problems are. As an engineer, I know that once you clearly define a problem, you’re halfway to its solution. And as a programmer, I’d learned about a particularly efficient way of defining a problem: writing a bug report. In geek parlance, bug reports are standard “I found a problem!” forms that testers and users fill out to tell a development team what they need to work on. It details precisely what actions lead to what results, allowing the coder to get down to the business of fixing things.
Bugs aren’t so clear-cut in academic situations, but I wondered if formalizing the action of pinning down your problem before asking for help would make any difference in classes. One of the big things students need to learn in school is how to ask for help well, but nobody ever explicitly teaches you that. Once I began using these bug reports to formalize my own questions, I found that I was able to ask for help much more effectively; last semester I started asking my students to use them to explain their problems concisely and well to me - and to themselves. It’s too soon to see any effects, but I’m hoping to roll it out in my tutorials at the start of next semester and see what happens.
Here’s the explanation and request I send out when people ask me for help. Some of you might already do this in one form or another. Feel free to hop in, comment, or tell me this is obvious and everyone else has been doing it for years. Do you think bug reports are useful outside the realm of software development?
Bug Report Explanation
Dear [Name],
Thanks for emailing me and saying you’ll stop by. Before coming in, it would be awesome if you could write up a bug report. I’ve found that they help me focus my thinking and solve problems in my own work much faster. So I thought I’d try it with other folks too. Explaining the problem quickly with bug reports also has the side effect of making it a lot easier for my teachers to help me, so I do have some ulterior motives here.
Here’s the format I use; answers aren’t long, just 1-3 sentences or coherent fragments thereof. (I make one for each issuse I’ve hit).
[Coursename] Bug # [Positive Integer]
About:
(What homework problem, lab, reading, proof, or page am I talking about? As specific as possible - topic, book, page number, problem number, or even which sentence of a problem the issue is with.)
Problem:
(What, exactly, am I stuck on? What specific piece of information is it that I don’t have but need desperately?)
Tried so far:
(What have I tried so far to fix the problem myself? What happened and why did/didn’t it work?)
Request:
(Given all this, what would I like the prof/TA/whoever to do for me?)
It’s really short and easy to hack out the couple sentences once you get the hang of it, and half the time writing a bug report actually fixes the problem for me, which is totally sweet.
Give it a spin and let me know how it works for you - either come in with these or shoot them off to me beforehand.
Thanks,
-Mel
1 comment:
This comment is from DJ.
So I realize that the example I think of first when I think of debugging in an academic context is not the same thing everybody encounters (god forbid), but I still wanted to share. It may be of relevance that some problems just resist being bottled up from an engineering perspective.
I think of freshman year, sitting in a prof’s office trying to explain why I, veteran of two years’ study of calculus and linear algebra, was suddenly feeling like I didn’t know any math nor could seem to learn any. That conversation was the single most painful debugging session I have ever experienced or hope to live to see. It went something like this:
Q: It’s not like I’m not trying. I have a serious problem trying to learn the material.
A: And what do you think that might be?
Q: The book, maybe? Definitely. It’s at least partly the book. I think it’s too vague.
(A proceeds to debunk this argument)
Q: Then it’s too specific. I need clear generalities.
(A insists that the book is by far the best one available on the subject, having just switched from last year’s book)
Q: Well I don’t know then. Maybe it’s my learning style. Maybe it’s your teaching style. Maybe it’s…
(Q & A proceed to butt heads to no avail for 30 minutes straight)
What bothers me about this isn’t even how close I came to breaking down in the man’s office (I’ve heard enough war stories to know that’s actually a respectable thing to do). It isn’t the fact that to this day ODEs are a slippery subject, or that I’ve been forced to find new and different maths that I can truly grok (I’m rather glad I did). As Mr Wronkowski said to me in 11th grade, only a genius gets all the math he encounters. The rest of us have to be prepared for the day we hit a brick wall - a concept that’s just too much for us to digest. I have come to terms with this.
What bothers me is that in that moment I felt powerless because I could not diagnose the problem. Self-awareness is very important to me, it’s one of the strengths I get by on. And in that moment I was absolutely clueless. I wonder if other people go through life feeling like that constantly, and it’s a creepy idea. Without introspective capabilities and some rudimentary meta-education, how does anyone get by? And then I remember, they don’t. Most of them don’t become engineers, they become philosophy majors or drop-outs, and then later waiters and janitors and laborers and what-have-you (it’s thoughts like that that make me begin to understand why you’re drawn to both fields). ^_*
As for me, I spend a lot less time debugging nowadays because a) the work has gotten a little easier and b) I’m generally aware of the problem. Most often it’s just that I have ceased to care about the subject in question and cannot force myself to study.
Post a Comment