This post is part of an ongoing series.
Scary Professor Guy
I brought back Scary Professor Guy to open the class this week when, two or three minutes into our class period, one of my Juniors was still trying to get one of my Seniors to help her with her programming homework.
I barked, “Okay, okay, go sit down. We’re not here to talk about programming, we’re here to talk about technical writing.” She blushed a little and went back to her seat, I had all eyes on me, and said, “Right. Today’s class topic is ‘Programming as a Technical Writer.'” That got a laugh.
Talking Points
Before we got to the lecture, though, I had them go around the room and everyone described his or her semester project. Briefly. I had a couple goals in mind with this, but the main one was just to force them to think about their semester projects. They did that three weeks ago when they wrote up their proposal, and probably not a moment since then. So I sent out an email last weekend letting them know they’d be responsible for talking about their projects during class on Tuesday.
Their assignment today (due next Tuesday) is a progress report, but I was hoping the threat of public speaking would drive them to get started a little sooner, so they’d actually have some progress to report.
I imagined it could take as much as half an hour to go around the room (leaving me forty-five minutes for my lecture) but I went ahead and prepared an hour’s worth of material just in case. In reality, it took fifty minutes to go around the room, so I not only cut the disposable fifteen minutes, I had to do some major compression on my core lesson.
The presentations were useful, though. I’m sure the students were bored of it about halfway through, but most of them were encountering (or will encounter) similar problems and frustrations. Most of those problems are inherent aspects of technical writing, so it’s not like I could give them advice to get around them, but at least they’ll know they’re not alone.
Programming as a Technical Writer
I’d sort of looked forward to this lecture ever since I found out just how many programmers I had in my class — my opportunity to show them how useful programming can be in tech writing and (just in passing) how incredibly cool I am, as I’ve done all these things.
The better I got to know them, though, the more I realized that the stuff I had to tell them didn’t merit a class (or two — I’d originally scheduled another lecture on “HTML, XML, and Structured Documentation,” in addition to this one). I’ve got three English majors who could all really benefit from a course in each of those topics, but I wasn’t going to be able to teach them Python in seventy-five minutes, and I couldn’t justify making all my programmers sit quietly while I tried.
So, instead, I adjust my focus. Instead of trying to teach when and how to use which tools, I converted my case studies into object lessons. That may seem like a pretty narrow distinction, but it’s a matter of scale. I only had twenty minutes, anyway, so I briefly described several of my big projects (in terms of efficiency improvement), and then I leaned heavy on the take-away lesson.
The take-away lesson is this: automating tasks can be difficult to set up, but it makes those tasks easier every time you have to perform them afterward. Your job is to determine (and it’s a matter of constant re-evaluation) if the set-up expense is worth the efficiency reward.
If you’re a programmer, that expense is often just the amount of time it takes to make and refine your program. I have half a dozen examples ready to hand where I was able to save hours and hours off of every document we produced with just a couple hours of research and coding. If you’re not a technical person, though, that expense can require weeks or months learning a new skillset, or days refreshing your understanding of one you haven’t used in a while. Still, there are some projects large enough that a semester of training is worthwhile to write a script to process the thousands of pages of data you’ll be dealing with.
I didn’t try to teach them how to do anything specific. I would have, if the projector had worked like it’s supposed to. I would have probably kept them late so I could show them how to put together a quick VBA macro in Word, but now I’ll just save that for a Thursday tutorial later in the month. As it was, I just told them about a couple times in my experience where quick Python scripts or clumsy VBA macros made my life much, much easier.
Progress Report
Their assignment today, as I mentioned, is to write a progress report on their Semester Projects. I had them create Google Docs account last week, so I decided to make this week’s assignment be a new Google Doc. In their tutorial I showed them how to set up and format a Google Doc from scratch, and then how to load and modify a Google Docs template to achieve a similar (but prettier) effect. Now they’re supposed to fill in one of those two documents with the information required by their assignment, and then share it out to me.
I’m anxious to see how that goes. I’ll let you know.
More next week.