Lectures: Good, Bad and Ugly

Lectures are an important part of college, but it has always been surprising to me that many of them aren't that well done. I know it takes a bit of work to prepae for each talk, typically 2 to 4 hours per hour of lecture, sometimes more if the topic has interesting demos. But it appears that many professors don't even do the minimum preparation.

And it’s not just professors. Corporations also have the equivalent of lectures, presented either internally or externally. When I did external talks at Microsoft, there was extensive coaching and prep work for each talk given by subject matter experts or people who knew the ins and outs of giving any decent presentation. Having done some demos in my lifetime, it amazes me how well done public presentations by companies like Microsoft or Apple are.

A good lecture can make you understand something, or if really well done, can inspire you to change your life's work.

For some reason, I don't tend to remember the good lectures. The ones that stand out in my mind are the bad ones:

When I was a freshman in college, I was taking some honors math class. We had classes 3 days a week and one of those days was Saturday. As a freshman, we were required to attend all classes and attendance was taken. On the Saturday of our school’s away football game at Harvard, we had a one hour class that started at 9am, and the kick off was at 1pm with a 2+ hour drive to Cambridge. The professor said he understood that everyone wanted to leave ASAP, so all he had planned was one proof which should be easy and fast. He tried FIVE times to do that proof and we ran out of time before any of them worked out. Needless to say, I avoided taking classes from this professor after that.

My brother was an undergraduate at CalTech where all freshman were required to take the same Calculus course taught by Tom M. Apostol from his famous two volume book. But he taught straight out of the book with no new examples, and if I remember right, he did not take questions. Out of a freshman class of 200, he was lucky to get 10 people to show up at the lecture, and they were there in case some assignments or test dates were announced.

When I was a test lead in a small group in Windows NT, I would get people outside my group to come in and speak to us about their work. We had international testers, reliability testers, and some developers, all of whom talked about challenges in their areas. One day, we invited THE security penetration tester to talk to us. He gave a 60 second definition of what his work was, and then opened the meeting up for questions. Needless to say, most of the people in the room didn't even know where to start. David Shiflet and I spent the rest of the hour meeting asking leading questions in the hope that he would start talking much more. In all fairness, he didn't know exactly what we needed to know, so he didn't prepare anything.

He might have gotten his idea for preparation from the talks Hunter S. Thompson used to give on college campuses. Hunter would get introduced, pour himself a glass of scotch and ask for questions. But Thompson was (in) famous, so people had lots of questions that he could respond to. {BTW, I learned from this experience to ask speakers for their slide presentation a couple of days before their talks. The requirement for a written presentation improved the value of these talks.}

Despite my selective memory for bad talks, I do remember the spirit if not the content of lectures given by John Kemeny. John was an inspiring teacher who other teachers looked up to. Years after I graduated, some friends and I started a company with John to develop an ANSI standard BASIC system that would run on various microcomputers that were coming out at the time. We would sometimes meet after his classes, so I would walk over early to see the ends of his lectures. He always did good demos, took questions from the class and his answers did a good job of making things clearer, even if it meant dodging some of the more subtle problems.

The one thing that consistently amazed me was that his talks ALWAYS ended on time. There was no apparent rush to fit something in, or some extended question-and-answer period at the end. The lectures ended as if by plan exactly at the end of the period. I always figured it was years of experience and attention to preparation that got him this result.

Well, apparently he had a trick. I was recently sharing a wonderful birthday dinner with one of John’s co-authors, Laurie Snell, when this topic came up. Peter Doyle, who is now a math professor at the school, was amazed by the same trick and had asked John how he did it. It turns out that John prepared three different-length endings for each talk. He would consult the clock and depending on how much time he had left, he would pick the one that would fit. Perhaps this is commonly known trick, but it is new to me.

Notepad stories part III

When Notepad was converted to be a Unicode application in 1993 for Windows NT, there were no fixed width fonts available. This meant that the code for printing was pretty broken. The old code assumed that all the characters were the same width and, as I remember, used the average character width as the width. This leads to truncated lines or undersized lines.

The first fix involved the GetTextExtentExPoint() API which computes how many characters fit into device context (i.e. a video display or printer) for a given string. This calculation is not simple because of the different widths of each character and the possibility of kerning. Kerning allows two characters to be squished together and is typically done for aesthetic reasons. For example a V followed by an A may be kerned.

So, each line is printed up to the right margin or the end of the line whichever comes first. If there is anything left over, it will be printed on the next line. One problem with this naive approach is that it may break a line within a word, so it won't look like what Notepad displays on the screen when word-wrap is on. And there are other considerations like what to do with horizontal tabs, right-to-left languages, and any special Unicode control characters. Working out these details is not rocket science, but the resulting code may not track improvements made later in system provided edit control.

Ideally, Notepad would use the same code as the edit control, but instead of displaying on the screen, each page would be "displayed" on the printer. In 1993, there was an API called DrawText() which did this, but it would stop when it filled up the space and not report back where it had stopped. This API would work fine if there was only one page to print, but Notepad wouldn't know where to start for the second page. Windows 2000 introduced the DrawTextEx() API which returns where in the input string it stopped displaying, so now Notepad printing will track any improvements made in the edit control.

Over the years, many of the dialogs in Notepad were implemented in the system, and I would rip them out of Notepad and save some space. I had the advantage that there was no program management telling me what I could or couldn't do. If anyone asked, I would typically just say I was following the new standard. In the mid-90s, there was a UI person who tried to clean up all the hotkeys for various apps in Windows, and Notepad was changed to follow them.

One advantage to using the common print dialog was that the dialog got a lot of usage testing. Print testing has a huge problem because of all the different printers that are supported. Notepad is often used just to test simple printing internally to Microsoft, but it is also used outside of Microsoft too. When N-up printing was added during Windows 2000 development, our test team was having a hard time testing this feature. Hearing about this in a meeting, I volunteered to enable the feature in the Notepad print dialog, and this helped quite a bit. It also put pressure on other apps that printed to enable the same feature.

Someday I'll post about a bug I introduced that only hit Dave Cutler when he was using his MIPS machines.