I’ve had the chance during the last few weeks as the quarter winds down to think about my own philosophy behind teaching. This stems out of both my work as a writing tutor in the College’s Writing Center and as a lab aide for Logo programming with the Designing Languages and Algebra to Algorithms programs this quarter.

I’ve always had a deep appreciation for teaching, which has deepened since I started working in tutoring positions, and deepened even more as a lab aide. As a lab aide, the strategies are basically exactly the same as they are when tutoring — lead the student to the answer for whatever question they’re asking. However, the process requires more breaks from that strategy: if a student doesn’t understand something, lab aides are expected to clue them in a bit with a nudge in the right direction, which usually means giving them some portion of the answer.

I’ve found that, as a lab aide, it’s very easy to understand what the lab is asking for, and it’s also easy to know the answer to the lab (so long as you’ve done the appropriate preparation beforehand), but it’s very hard to convey what the lab is about, much less convey the answers, to students. Thus, I’ve really been struggling this quarter with coming up with good ways to explain and relate concepts back to work that they’ve already done.

I found this especially true while in the lab last Thursday. The lab itself had to do with fractals — specifically, the Koch Snowflake (also known as the Koch Curve). The process of creating the fractal is very easy — using a standard triangle, “kink out” each side in order to create a level two Snowflake. Then, to create a level three Snowflake, use all the sides in a level two snowflake and “kink” those out. The Wikipedia entry has a graphic that shows the progression quite nicely. This is basically just the same idea applied over and over. It can be applied recursively (though that’s not really a great solution), but it’s actually better to implement it recursively for levels three and up. For levels two and one, it’s better to have a separate procedure to draw them, since the logic is so different.

Relatively straightforward, but very hard to explain when you’re not supposed to give students the answers.

While the strategies are really quite similar, the result is quite different — as a writing tutor, the final result of any session with me isn’t necessarily an answer, unless the student brings in a very specific question. Most often, in addition to an answer, students get an idea of what needs to be done next in order to allow their writing to grow. Not so as a lab aide — the process stops once the student gets the answer. They can certainly move on to other projects, and we, as aides, will help them find the answer for that project, but there is no sense of programming as a process. Which is ironic — programming is a process, but that process isn’t as obvious as it is in writing.

My philosophy as a tutor has always been that writing, as a process, needs to be nurtured and recognized. Academic writing may be perceived as boring, but it sets students up with an important life skill if taken advantage of properly: the art of written communication. My job as a writing tutor is to help inspire and install that art, and to help students realize that the process is ongoing. You can’t stop after a single draft (though there are exceptions to this); one has to keep going. With programming, the process very definitely stops — once the program’s written and it runs, at least in an academic environment, you’re done with it and probably won’t touch it again.

It’s true that that’s not true in the software world at large, but for the purposes of my lab aide work, it’s good enough.