Category Archives: teaching

The Week in Words (August 7)

At the Editor’s Desk

After last week’s big reveal of my other project, I think it’s time to get back to a real focus on what brings us all together here: hating Dan Brown.

Freelance Services

It’s a shame that I’ve never gotten around to preparing a sales page around here, but as some of my blog posts in the last couple weeks have probably hinted, I do have some valuable services to sell. In addition to my own extensive experience with creative and technical writing, I’ve done writing coaching, document design (fiction and nonfiction), story editing, voice editing, line editing, copy editing, and several types of copy writing.

At the moment, I’m working on breaking into grant writing, and I’m in talks to maybe do a ghost writing gig. It all sounds like a lot of fun.

Incidentally, since I don’t have a strong sales process set up at the moment, I’ve got some open availability, so if you find yourself in need of some of those services, you can feel free to send me an email (or use the site’s Contact Form) to ask me for an estimate. I’m not cheap, but I’m terribly good.

The Girl Who Stayed the Same

There’s the technical and the creative writing to do, though, and I’m still going strong on my current work-in-progress. This week I finished chapter seven and started chapter eight of The Girl Who Stayed the Same.

Someone finally asked Jonas if he was an angel (and he answered with a qualified no), and we also learned that Jonas is really terrible at chess. He’s also pretty emotionally unstable, but what do you expect from a dude who hangs around with artists all the time?

On Unstressed Syllables

This week we covered two major topics: following directions and preparing a document according to the rules (specifically grant applications), and following the rules and writing stories with due respect for your readers.

Sunday I introduced the Technical Writing series on grant applications with a story about my three-year-old daughter learning to read…by memorizing the shapes of words. It’s limited in a way phonetic alphabets aren’t supposed to be, but it’s also advanced in a way three-year-olds aren’t supposed to be, so I’m considering the whole thing a wash.

Then on Monday I talked about grant money, selection committees, and how grant writing is just like the slush pile all over again. It’s frustrating in ways, but it also gives experienced novelists a leg up on the competition.

Then Tuesday I took it a step further, saying that grant writing is just like writing Shakespearean sonnets. The metaphor isn’t perfect, but the application is — if you can learn to express your ideas well within someone else’s strict structure, you’re ready to call yourself a professional writer (and start raking in the dough).

On Wednesday, Courtney waxed domestic with a story about sewing up some torn garments, and in the process taught us how to patch up holes in our stories’ plots. It can be a lot of work, and it’s certainly the sort of thing we’re often tempted to let pile up on our To Do lists, but a little extra effort can save a story from becoming scrap, and turn it into a perfectly serviceable Saturday shirt.

Thursday I introduced the Creative Writing series on writing rules with a story about Trish trying to watch The Da Vinci Code in spite of all my lecturing. The lecture’s got to go someplace, though! So I spilled it through onto Friday and Saturday, too.

On Friday I talked about respecting your readers, and specifically focused on understanding and deliberately crafting your book’s reading experience. When you consider how your story affects your readers (and what they’re offering in exchange for your storytelling), it becomes far easier to stick to some of the core rules of writing.

Today’s article tied that up with a detailed look at what some of those rules are: premise, verisimilitude, and the unforgivable sin named “Deus Ex.” It’s been a pretty academic week, and if you’ve followed along you probably deserve a couple hours of college writing credits for it. Alas, my blog isn’t yet accredited.

Around the Web

I also found a couple of good articles around the web this week, that I thought you might find interesting. They’re certainly relevant to our most recent discussion.

  • Writing this week’s aggressive broadside against popular novelist Dan Brown, I couldn’t help thinking about literary agent Nathan Bransford’s fantastic article last week, The One Question a Writer Should Never Ask.

  • Wouldn’t you know it, though, Bransford followed up with another excellent post this week on the same topic, Writing vs. Storytelling. Be sure you read both of these — you’ll be a better writer for it.

The OC (Week 16)

This post is part of an ongoing series.

Final Exam

Two weeks ago, I wrapped up my Technical Writing class with a final exam. It was a little experimental (Courtney said more than once, “I’ve certainly never had a final like that!”), but it went perfectly.

In case I didn’t mention it before, Courtney joined us for the final exam period. I asked the class if they were cool with that back in Week 15, and they insisted they had no problem. She wanted to come out of idle curiosity, mainly as a result of reading this blog, and I had no objections.

So she showed up Thursday afternoon, a couple minutes before one o’clock, and the vast majority of my students were already there and in their seats. I was at the front of the class, by the computer station, getting things ready for the class session, and she came timidly into the classroom, crossed in front of the blackboard, and asked me where she should sit that would be unobtrusive and out of the way.

I’m mean sometimes. I sent her to the chair at the teacher’s desk, front and center.

Cookie Platter

I wasn’t trying to be mean. It was really the only place I had for her. The students were arrayed on the outside of their inverted-U of tables, and though there was a table tucked in the middle of the room (where I’d sat while observing the presentations), I had big plans for the middle of the room, so I couldn’t really send her there.

I was also standing at the computer station and not starting class for a very particular reason. I was buying time, waiting for all of my students to arrive, and also deliberately standing so as to conceal a cookie platter T– had made for my students. I didn’t want to spoil the reveal by having someone walk in late and spot a half-hidden cookie platter, y’know?

Anyway, once the classroom was full, I turned on the overhead projector with just the empty desktop of my school-issued laptop showing, and that got everyone’s attention. All eyes snapped to the screen, and then I stepped back, brought forth the cookie platter, and headed to the table in the middle of the room to set it down.

I was halfway there when someone said, “Are those cookies?”

I explained that T– had wanted to send cookies for my students all semester, but I’d kept objecting because I thought it would be too distracting. Then I finally relented on the one day when their participation counted for 10% of their grade. Hardly fair. Nobody complained, though.

I was in the grip of la grippe, so I left the cookies wrapped in their plastic and stepped back to the front of the room. “I need somebody else to unwrap them,” I said, and about two heartbeats later Sean — seated in the middle of the back row, and as far from the cookies as possible — leaped over the tables to take care of business. He got them unwrapped, then passed the tray around, which was quite calm and orderly.

Chaos and Disorder

The next step was the one that denied Courtney a seat in the middle of the room. I told them I had their graded semester projects ready to return, and I’d call out their names. After they came to retrieve their grade sheets, they were to remain standing in the center of the room instead of returning to their seats. (That was an important step that turned out to be totally useless.)

Once everyone was standing in the middle of the room (and they were sort of packed in like livestock), I explained that we were going to divide up for the day’s activity. Unlike previous activities where each group worked on its own version of the assignment, today’s activity would require three different groups, working on different aspects of one product. So I explained that the table on the right would be for the Documentation Group, the table on the back would be for the Software Group, and the table on the left would be for the Publishing Group. I told them to take their best guesses which group would most suit them, and go sit down.

Everyone sat down pretty much exactly where they’d been before.

The Assignment

Next, I explained to them the assignment. Just as I’ve said here before, my goal was to have the students create a wiki to demonstrate their ability to learn a new document type without my guiding hand. So I pointed to the screen at the front of the room, that showed my blank desktop, and told them my goal was for them to have a full-featured wiki including the contents of all of their weekly tutorials up on that monitor by the end of the class period. By that point, it was a little over an hour and a half.

Then…I sat down at the front of the room. And I looked at them. I may have given a little bit of an indication what each group should do, but it certainly wasn’t anything that could be described as “directions.” I did ask a couple of my students on the back row if they’d completed wikis of their projects for extra credit (Sean and Will, both of whom had asked for permission to do that, and both answered that they had), and that was meant to give them a nudge toward helping the rest of the class figure it out. It worked.

Not right away, though. The next ten minutes were brutal. I had about two minutes of deer-in-the-headlights from the whole classroom, and then my two with experience (both in the Software Group) leaned their heads together and started talking, and got a couple others from the Software Group chiming in before too long. I listened to their chatter for a little while, to get an idea where they were headed, and then gave them a nudge in the right direction, and listened for a little while more.

The Software Group and the Publication Group ended up both being composed primarily of technical people, so by that point the Publication Group was pretty involved in the conversation, too. The Documentation Group (my English Majors) were sitting off on the right still waiting to find out what they were supposed to do.

So I finally addressed that. I explained to them briefly what a wiki was — a type of simplified markup language — and that they would need to take the highly-formatted, styled Word documents I’d used for their weekly tutorials, and convert them into flat text files with some simple markup. I suggested they get to work downloading the tutorials from the class website, figure out how they were going to distribute the workload, and then start making guesses as to how they would do the conversion. They wouldn’t know for sure until the Software Group settled on a wiki platform, but they could do some prep work while they waited.

In Production

Then I headed back over to the Software Group, and I said, “What you’ll probably want to do, first, is choose which wiki platform you’re going to use–“

And Will cut me off to say, “We just did that.”

I went on, “And then this group is probably going to divide up, half of you going to support the Documentation Group as they convert the existing documents into the right format, and half of you going to support the Publication Group as they figure out how to get those documents up for us to see, within the next hour.”

They nodded, then immediately got to their feet. Will went one way, Sean went the other, and they became Management. It was kind of awesome.

After that, I was done. It was their final exam, after all. I sat at the front of the room and chatted with Courtney, eavesdropping on their discussions, but most of the corrections I would have made ended up getting caught by Will or Sean before I had the chance.

It was only a few minutes into that (maybe ten or fifteen), when I asked Will what address they were using, and Courtney was able to pull it up on her laptop. From that point on, while we were discussing writing or Wil Wheaton, or whatever, we were also scrolling through the wiki as it was under construction. I was impressed with the draft version. I was really impressed with the changes they had in place by the half-hour mark. And at the end of the period, while they were still scrambling to get a couple of the more complicated chapters put together, I asked Will to step up to my laptop and present the finished product to me.

He shook his head. “It’s not ready yet!”

I said, “That’s okay. Show me what you’ve got.” I didn’t say it in a menacing way, either. I was prepared to grade them based on what they’d finished, not the page or two that were still undone.

He wasn’t satisfied with that, though. He said, “Give us a few more minutes. It’s almost done.”

As he said that, from one end of the Publication Group table I heard, “Five’s done!” and down at the other end, “Seven should be up now.” And Will scurried off to oversee the finishing touches.

In the end they all stayed a little bit late, just to present a polished product. It was phenomenal. It was so much better than I’d hoped for, especially given the short time limit.

(If you’re curious, you may be able to see a copy of it here. I have no idea how long that site will be live, but it’s there for now.)

I’d had some closing words prepped, to finish off the semester, and after seeing their work I wanted to go into detail with praise, but there was no time. All I could tell them is, “Well done! You’ve earned a one hundred. Thank you guys for being awesome!” And then I sent them on their way.


Knowing what I know now, I could have made the final session go a little more smoothly. I don’t think I could have possibly gotten any better results, but I could have left the students a little more comfortable with their role. Then again, that’s pretty much true for the whole semester.

And I’m not beating myself up for that. This was my first time teaching. Wow.

Anyway, one thing I experimented with there in the final — dividing them into purpose-based groups — is something I think I’d like to do from the start if I ever teach the class again. On day one, I’d divide them into those groups — with those titles — and let them rearrange through the course of the semester if they wanted, and sometimes divide them up in support roles and sometimes combine them, based on the project, but give them a chance overall to develop some sort of consistent group identity, apart from “we’re sitting within arm’s reach.”

I do wish I’d had another assignment or two in there, and I wish I’d had in-class activities for nearly every class I didn’t have one for. I put that down to limited prep time from being a first-timer, though. Same goes for the uncertainty of their schedule (flip-flopping on due dates), but I think I could be a lot more confident about that on a second go-round.

Apart from that…I’m awesome. I know the class was satisfactory to the powers-that-be, I think the class was useful to the student, and I’m amazed how much I gained from the experience. My students were all amazing people, and I’m glad I got to meet them. And, y’know, I discovered I could do something I never would have thought possible. It was bigger and better than NaNoWriMo. I’d never have guessed.

And that’s it. Hope you’ve enjoyed the updates. Let me know if you have any questions. I’ll let you know if they ask me back for more.

The OC (Week 15)

This post is part of an ongoing series.

Season Finale

We have officially left the regular season. Post-season takes place tomorrow. Or something like that. Whatever.

Week 15 marked the last week of regular classes for the semester, and we finished it by finishing up our presentations. Tuesday saw some technical difficulties, and Thursday saw some more, but the brightest minds in OC’s IT department are in my class, so we got it all worked out.

A Polite Reminder

We finished up on Tuesday with fifteen minutes to spare, and I just let them out early. As I headed toward the podium to pack up my laptop I said offhand, over my shoulder, “See you Thursday.”

Then I stopped, turned to glare them all in the eye (that’s right, thirty-two eyes all at once, it’s a professor thing), and I said with a dread pronunciation, “See you Thursday.”

A chuckle went around the class, but I got numerous affirmations from those who’d missed the previous Thursday, and then they fled the room.

It worked. Thursday we had a full class, and I was able to give some last-minute clarification concerning the Final with the confidence of knowing everyone was there. That was nice.

Semester Projects

Thursday was also the due date for Semester Projects. They’d haggled a midnight deadline earlier in the semester, so that held and they had until the very last seconds of Thursday to get the document turned in for full credit. Someone else (I’ll let you guess who) had worn me out with his arguments and convinced me to accept late work, too, but I instituted a 5% per day penalty for it.

There was some discussion whether that should be pro-rated, or lump sum, and the arguments on both sides of the debate were pretty compelling. I ended up pro-rating, because I like my students.

Anyway, I got all the projects over the weekend, and they’re now all graded. They turned out awesome. I remember that being one of the things the class was most famous for when I took it, and at the beginning of the semester when I asked my students what they knew about the class they were signed up for, the project was the only bit any of them had any clear ideas on.

I had some concerns that the reputation of the semester project might fade with a new professor at the helm, but for now I think it’s safe. They did some really cool stuff, and nearly all of the finished projects are going to be terribly useful. Several of them will even be useful to me.


I made that all sound like a lot of fun, but those four words up there — “they’re now all graded” — actually represent a pretty miserable experience. Who knew semester projects could be such work for professors? Both of my parents are teachers, so I’ve heard grumbling and complaining about having stuff to grade all my life, but I didn’t really get it, until I found myself with a mountain of stuff to grade.

It’s no fun at all. Just horrible. I really don’t recommend it. If you’re teaching a class, go all California-hippie on them and don’t do grades. Or quantum physicist and assign grades completely at random. That would have to be better than actual analytical numeration. Blech.

(I’ve also been coming down with a cold in the same days that I’ve been going through that process, so it could be having an impact on my attitude. Time will tell, I suppose.)

Anyway, it’s done. It’s done and it’s done and it’s done. I’ve got Finals on Thursday, and I’m confident everyone will show up, and the minute that’s over, I should be able to turn in final grades and be done with the class. How cool is that?

More next week (or, conceivably, tomorrow).

The OC (Week 14)

This post is part of an ongoing series.

I mentioned it in the last post, but we’re done with lectures and mostly done with the tutorials (more on that in a minute). That just leaves presentations, and the final.

We started the presentations this week, with four presentations a class period over four periods (in two weeks). Two of my four presenters on Tuesday had skipped the assignment that had them sign up for a presentation spot (on Google Docs), so they found out about it for the first time when I sent out a reminder email on Sunday.

To their credit, they both did surprisingly well.

Honestly, I haven’t seen a presentation yet as bad as mine would have been (and, in fact, was, back when I took the class). They’re farther along with their semester projects than I really expected, too, which is encouraging. I’m looking forward to seeing their finished products, so I’m glad to see it’s not all going to be last-minute stuff.

Empty Seats
Thursday’s lectures were a little better, really — which is to be expected, given that they had more time to prepare, and got to learn from the presentations that went before. Unfortunately for the presenters, though, there weren’t nearly as many people around to be impressed. We had right at half of our class show up.

That, too, shouldn’t be much of a surprise. After all, it was the first time all semester that we’d met in class on a Thursday. To be fair, I warned them about that on the first day of class, and before Thanksgiving break, and then I sent out an email last Sunday (as I mentioned) reminding them about presentations this week.

I had a brief bout of guilt, worrying that my own attitude about the last couple weeks (being so much easier on me, since I’m just listening to presentations) had been conveyed to my students somehow, and they were slacking off because I was. Then I remembered the Thursday thing, though (and got emails from a couple of my students citing exactly that), and I let myself off the hook.

Textbook Execution
One thing I had been slacking off on was their final tutorial. All of the rest had to be done by specific dates, to match up with their assignments. There was one last one that I’d promised them, though, that didn’t really map directly to any work they were doing. Way back in week 9, I did a big presentation showing them how to build an automated Table of Contents and generally take advantage of all the extra work we’ve been doing to build a powerful, long-form document. I flew through the process in class, though, and gave them no exercises or anything to reinforce it. Instead, I said, “This’ll probably end up as a tutorial at some point.”

I’d meant to get that to them the week before Thanksgiving, but it was the week before Thanksgiving, so I didn’t. I kept thinking about doing it during Thanksgiving break, but I was on break, so I didn’t. Whenever I started feeling guilty about that, I reminded myself that my students didn’t really care.

Then Monday morning I got an email from one of them asking me how to make a Table of Contents, because she needed it for her semester project, and I immediately felt like a super jerk. I sent her a quick answer, and then got to work writing my tutorial.

It was a complicated one, though, because I had to walk through some of the more advanced tools in Word. Not only that, I had to handle some pretty nit-picky exceptions to make it come out perfect, but I was trying to express how simple the whole process really was, even while explaining why those exceptions were doing what they were doing. Then I needed screenshots to illustrate it, and I needed to put together all the resources they would need to follow along with the tutorial, and make those available on the website.

It was a real task, is what I’m getting at, but I finished it last night. The title for the tutorial was “How to Build a Book,” and it took all the tutorials I’ve made all semester and bound them together in a single textbook. It ends up looking pretty nifty, and it tops 100 pages even without the lecture information and assignment descriptions (that I would definitely include in it, if I were making it a standalone book).

Anyway, I have no idea if that will actually be useful to any of my students (since the one who asked me about it presented her document yesterday, and she’d clearly figured the ToC out using just my quick email), but I’m glad to have it done.

Final Thoughts
The only other issue I’ve been dealing with this week is their Final Exam. I’ve been told I need to have a Final Exam period, but that a test isn’t really necessary. I told them early in the semester that they would have an option of building a wiki instead of taking the Final Exam, just because a big ugly test doesn’t really mesh at all with the way I’ve been teaching the class.

As I really started thinking through the logistics of it, though, the wiki alternative seemed unrealistically complicated, and any test I would have (for those who didn’t want to take the alternative) would be just a huge waste of time. There has been no memorization in this class at all (it doesn’t make sense in tech writing), so I would have just made them show up in class to read a bunch of questions, flip through their textbook for answers, write those answers down, and then go home. I wrote their textbook, and it’s way too straightforward for any of that to be a useful experience.

So I finally decided to nix the original plan, and instead I told them all to show up for the Final Exam period, and we’re going to build a single wiki as a group project. That should be a lot less stressful for those who would have built individual wikis, it should be a lot more useful for those who would have taken the test, and I think it could actually be a fun experience. We’ll see.

Between now and then, though, I’ve got eight more presentations to grade, and about a bajillion pages of papers to grade.

More next week.

The OC (Weeks 12 and 13)

This post is part of an ongoing series.

Week 12
Back in August — back when I had so much delicious free time on my hands that reactivating my WoW account seemed like a good idea — I was just a bright-eyed kid all full of ideas. Those were the good old days, before bitter experience taught me the cynicism of reality. (In case you can’t tell, I’ve been noveling.)

Anyway, back then I made up a course schedule to put in the syllabus, which included lecture topics for every week, and assignments for the students along the way. I mentioned the fallacy of that schedule in the week 11 post about technical writers as programmers, where I pretended a topic of actual interest to them was a topic I knew something about.

Week 12 featured a reversal of that, when I pretended a topic I knew something about was a topic of actual interest to them. The title for the lecture was “Writing to a Deadline and the Publication Process.” I reversed the order for my presentation.

The Publication Process
By “the publication process” I meant the actual physical process that converts a Word file into a paper book. As a technical writer, that’s a process that takes up a lot of my time. After I’ve finished writing a perfectly-crafted, error-free description of my topic, I then have to spend hours and days and weeks reshaping the beast to make it play nice with paper pages.

This reshaping takes two major forms: page design, and print options. Page design is stuff I can do in Word, like adding page breaks (and “Notes” pages, and “This page intentionally left blank.” pages) to make sure new sections start on right-hand (front) pages, and adjusting space between paragraphs and illustration sizes to make nice full pages, and making sure every document’s length (in pages) is a multiple of four.

I went to some effort to explain why that last bit matters. It has to do with printing on both sides of a double-wide sheet, and then folding it in half (producing a four-page fold called a “signature,” which was a word I totally blanked on during the class). The reasons for this are complicated and partly apocryphal, but mostly they’re just uninteresting. I won’t bore you with the details.

Then there’s print options, such as which print method you want to use. Offset printing (using big acid-etched copper plates and rolling rubber mats) is still far prettier than digital printing (using, y’know, lasers), but it’s prohibitively expensive for small press runs (anything less than a hundred thousand copies), and it requires a lot of set-up time. As a technical writer, that’s a really difficult balance to hit sometimes. As…anyone else, it doesn’t matter. Offset printing is just outside the price range of the housewife putting together a cookbook, and printing contracts at most companies are handled by accounting or documentation departments, not the programmers and engineers who are taking my class.

Still, it’s the technical process by which we make real things out of the documents they’re building in Word, and I felt like I should go over it.

I also discussed the various binding methods — from three-ring binders and spiral-bindings to the hardback (“case” binding) and paperback (“perfect” binding) you’ll find on the shelves at B&N. I discussed the benefits and drawbacks of each, showed some samples, and then moved on.

Writing to a Deadline
Writing to a deadline is the biggest challenge of the technical writer (whether it’s a job title or just a job requirement). The nature of the deadline varies from shop to shop, and I demonstrated that by talking about my personal experience again. At Lowrance, we typically received an assignment with three days to build a hundred-plus-page book. Sometimes we had to turn it overnight. At the FAA…the Maintenance Handbook project I just finished was one of my top priorities for most of the last year. Once it was officially given to me, the deadline was a vague “soon” for months before it became, all of a sudden, “Friday.”

There’s a commonality in both cases, though. In all technical writing, really, the information you’re supposed to be putting into a document comes to you at a trickle — an agonizingly slow trickle at times. At Lowrance, we knew what products were in the works for months, but it would be three days before packaging before we had a working model to test and grab screenshots on.

Your job as a technical writer is to get as much information on paper as you can, as early as you can, without wasting too much time. That last bit can be the tricky bit, because we could easily have built a bunch of documents at Lowrance using early emulators, and then had to scrap 90% of our work because of a single software change (and we often did).

The other difficulty you’ll encounter when you’re writing to a deadline, I told them, is that you’ll get called into meetings, or have to attend training, or deal with any manner of pompous windbags who monopolize your time to tell you about something incredibly important to them, but that has no relevance to your project (or your life) whatsoever.

The best thing to do in those cases, I’ve found, is to have your laptop open on the table in front of you and just spend the whole lecture working on your project. (That got a laugh.)

Work Time
That whole lecture took forty minutes or so (as intended), and I left them the rest of the time to work on their projects and ask questions. They did, and some even hung around after the end of the period, so it was 2:30 before I headed home.

I sent out an email later that week to let them know the following Tuesday would be exclusively work time. I promised to be available (in class) if they had any questions or needed advice, but that I wouldn’t have a lecture prepared, and I wouldn’t be taking attendance. I also sent an email to several of the other professors inviting them to stop by and keep me company, because I didn’t expect any of my students to actually show up.

Week 13
Some of them did. Three, actually, which doesn’t sound very impressive, but it amounts to 20% of my class, so it’s not too shabby. I barely broke 50% on Week 12, and I did take attendance that week. (That was my only low week, though, and they did know it was going to be partly a work period.)

Anyway, I had some great questions from the students who showed up, and I’m pretty confident they’re going to have great projects to turn in. I also got to chat with one of my students about Google Wave for half an hour, which was both fun and educational.

Oh, and I got all my dailies done. So it was a productive period all around.

All I’ve got left now is presentations, evaluations, and the final exam. Oh, and the grading. I tremble at the thought of all the grading to be done. Still, the semester is mostly survived, and I think I’ve done some real good. Yay me.

More next week.

The OC (Week 11)

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.

The OC (Week 10)

This post is part of an ongoing series.

Pulling My Punchlines
Last week’s class was disappointing. I think, of all the classes I’ve prepared this semester, the only one I was more excited about (beforehand) was the one with the band flyers. That time I was excited about the in-class activity, though. This time I was excited about the lecture.

Because I had good material. Dad told me before Week 2 that I had to focus on how I could make their lives better, and this class was all about that. I had so much good information to impart, I just knew it would be a great class.

And it was not, by any means, a bad class. The information was good, the students paid attention, I filled an hour but didn’t keep them late. It was a good class, but it lacked punch. None of my excitement really got through, because (for the first time) I felt comfortable enough before class that I didn’t invest much preparation in the presentation. Turns out, I’m still not a natural. I didn’t have any punchlines, so I’d spend ten minutes telling them how cool this feature was, or how that program worked, but I failed to drive home how it would impact them. I guess a good activity could have served that purpose, but I had so much I wanted to cover that I didn’t really have time for one.

Or…well, I did. It just wasn’t in-class. I’ll talk about that more later.

The class covered “Collaborative Writing and Editing Tools,” and the most basic of those is markup. Markup, as I told them, is the process of providing feedback on a documentation product using a consistent, somewhat standard set of marks and symbols. You’re probably familiar with the paragraph mark, which can be penned into the middle of a long paragraph to recommend a good spot to break it up. You might be familiar with the strikethrough line ending in a little swirl to indicate text that should be removed. If you don’t do a lot of markup, you’re more likely to just cross out text you think should go.

There are a bunch of standard marks, but there’s also a bunch of standards, so it’s hard to find one reliable set. Because of that, I s