Note: This post is based on an old page from the main site that makes more sense here, now that the blog is finally up and running.

Old classroom

From 1996 through 2013, I taught at what is currently NYU’s Polytechnic School of Engineering, but had been Polytechnic University for most of the time I have known it and was more broadly known as the Brooklyn Polytechnic Institute, often referred to as “Brooklyn Poly.” If you’re interested in this sort of thing, it’s the second-oldest private engineering school in the United States.

The Original Polytechnic Campus

Mostly, I taught graduate courses. I initially picked up electives that nobody else was available to teach, but as other professors retired or moved on, I was asked to take on courses more in the mainstream of the curriculum. And, once in a while, I cover courses elsewhere.

Because of that, I have piles of lecture notes and scripts to package the lecture content.

So, while I decide what I want to do with my old lecture notes (post them as-is, rewrite them and do the research to make sure they don’t contain anybody else’s intellectual property, or some larger transformation), I’ll provide some information, here, on what I’ve worked on over the years.

Administrative Software

As mentioned elsewhere, I finally abandoned word processors in favor of what I believe to be a mostly future-proof system involving Markdown passed through GPP, Pandoc, and PDFtk to produce the final handouts.

The results look crisp and the workflow is straightforward. For more detail, give Class Management a look. If you don’t have notes that already look like mine, it shouldn’t be too difficult to spot where the scripts need to change to support any other format.

Individual Courses

Most of the rest of this goes into details on how I handled specific courses. You won’t hurt my feelings if you stop reading now, or even if you didn’t get this far…

Advanced Programming Concepts

In 2001, I had…an incident. The department had a hole in the schedule and asked me if I could come up with a new elective. I contacted some students and hammered out a provisional curriculum with content that interested a lot of people but wasn’t covered anywhere else.

What I didn’t hammer out was a title. I assumed that the school had people who did that, maybe a marketing team. So, when they asked me for a title, I came up with the laziest thing I could, hoping that someone would have a better idea: Advanced Programming Concepts.

And that’s the title they ran. Nobody questioned the objectively terrible name. Oops! I suppose it’s better than my initial thought, Back Alleys of Computer Science, at least, even though “advanced” is so much less accurate.

The course wove through development best practices of the day, the implementation of linkers (the typical final step of compiling), the use and implementation of debuggers, and some optimization techniques. One intended purpose for the course was to build on material from other courses, such as Introductory Programming, Software Engineering, Assembly Language, Compilers, Programming Languages, and Operating Systems.

Overall, I think the concept of the course was solid, and students were able to create both a linker and debugger as course projects, but it would have been more useful if it had been better organized and built around a more cohesive narrative or spread out and integrated to various other courses. Given the amount of programming expected, this might also have been a better choice for an undergraduate class.

Software Integration

Sprouting out of the semi-successful Advanced Programming Concepts class, I worked on developing a course revolving around the creation of solutions through integrating components with various scripting and middleware tools.

While the course never ran, the proliferation of application frameworks and other Rapid Application Framework tools since that time might make a course like this even more useful than it would have been in 2002 when I worked on it.

Design and Analysis of Algorithms

There isn’t a lot to really say about any algorithms course, I suppose. Just about every school uses the same graduate textbook and covers roughly the same material. It is a core part of the curriculum, after all. But even so, I tried to give it what in my mind (and I believe most of the students’ minds, as well) a more solid organization more deeply related to the design process.

Specifically, I try to focus more on structuring the problem-solving process, finding general forms of algorithms, and looking at what an understanding of complexity gets beyond comparing algorithms for speed. Less important are the individual algorithms, themselves, which I only cover in broad strokes and as categories—under the assumption that the details can be researched in books at any time, or on this fancy new thing called the Internet that the kids are talking about—whereas the Internet has little to no guidance on working through general kinds of problems and what kinds of solutions should be expected from them.

Client/Server Programming

This more or less became my baby, and something that I’m occasionally recognized for, locally.

Shortly after I graduated, the department needed someone to cover an elective at the last minute, and none of the available staff had any experience with writing network programs. I had taken the course the previous summer, had written some utilities in use around the school, and taught an occasional review course with the tutoring office, so they asked if I could make myself available. I taught it most summers over the years, I believe only missing one year until the campus closed.

The course has been a survey of networking technologies common to the time of teaching. While I started with BSD socket and TLI—known today as the X/Open Transport Interface—using both UDP/IP and TCP/IP, plus RPC in a few different ways, later versions of the course dropped TLI and downplayed UDP and RPC slightly to make room for Java’s RMI, the CORBA and D/COM distributed object systems, .NET remoting, and occasionally other technologies.

The bigger changes I’ve made to the class, though, are administrative. The syllabus I inherited required every student to produce a client/server database of books using each major technology and only in C. Limiting languages became impossible within a few years, leaving students to verify that an API comparable to BSD sockets and RPC were available on their platform. A standard project quickly became boring (and not particularly suited for the content), so I had students develop their own ideas.

The best story? One of my earliest students (who later formed a consulting firm with clients whose names you would recognize and not find repulsive) initially planned to build a distributed matrix resolving system, a somewhat classic example of the field. He ended up submitting a game, instead. When I asked about the change, he explained that the resolution worked fine, but was slower than doing the work locally, so he started over with something less counterproductive. That’s dedication and craftsmanship!

Database Management Systems

While this is mostly the typical “core” database course in any graduate program (usage, design, modeling, and implementation), I have tried over the years to give the content a better flow from topic to topic. Mostly, this became a “top down” process, starting with theory and user concepts, and working our way down pretty close to the “bare iron” implementation, splitting each major layer into a single “unit.”

I start with the theoretical side of the systems, minimizing the “fake theory” like relational algebra that’s just a query language made to look like math. From there, I usually turn directly to where those theories are applied, by looking into query languages and how they are processed by the managing software. Queries being useless without data to act on, I dig into how to model data and organize it into a database, including normalization and optimization techniques. Capping that process off, I head down to the basics implementing database management systems, including concurrency, distribution, and so on.

With that done, finished with the “main thrust” of the course, I then finish off the course discussing a handful of advanced topics (data mining, data warehousing, and the like) as time permits. Sometimes, if students happen to need a particular topic (hierarchical databases are common for many), I cycle it in earlier, usually with modeling.

Operating Systems

Like the Algorithms course, there isn’t much to say about another core class with fairly standard textbooks, in this case an operating systems course. Unlike the algorithms course, I don’t think my approach to the course has ever been unique, unfortunately.

Part 2

More interesting—though I seem to have lost the material for the moment—I once had the opportunity to teach an advanced version of the operating systems course, which had no set syllabus.

There, I discussed the topics that don’t generally get covered, like file systems, user interfaces, and so forth, instead of the usual scheduling and memory management work. This has been my only course with a regular reading assignment, as each lecture was paired with a research paper on a prominent or historically important operating system’s key feature of relevance. So, students were exposed to the original thinking on the Xerox Alto’s desktop interface or Unix’s file system before walking into the more abstract lecture on the topic.

Smalltalk-76 on the Xerox Alto

It was fascinating format that I’d like to see more of in the industry.

Programming Languages

Similar to Client/Server Programming, this course changed significantly while I taught it and became fairly unique. From early on, I resisted dogma and doctrine: I deliberately downplayed coverage of specific languages (even as “case studies”), under the assumption that a student can get the basics of an arbitrary programming language down in a couple of hours at most, and—especially—judgment of languages or features as specifically “good” or “bad” except in very specific contexts.

Instead, the first half of the course generally works through how different kinds of concepts (choices, repetition, and so forth) are expressed across at least a majority of languages. The second half takes the experience with features and looks at significant programming paradigms in terms of their models of computation. Some years, depending on interest and time, topics such as implementation (compilers and interpreters) and bridging between languages gets some time, as well.

Along the way, assignments spotlight different programming languages in the context of features or aspects discussed in class and exams focus on using comprehension of the material to (loosely) design custom programming languages for specific problem domains.

On the topic of individual languages, depending on the year, I changed the mix of each assignment to either mostly include three or four small languages (with abbreviated tutorials to get students running) or fewer new languages with the rest replaced with a highly customizable BASIC interpreter I created for the purpose.

Windows Programming

One year in the pre-.NET days, I was invited to teach a course in programming applications in Microsoft Windows for a local company and (obviously) took the opportunity.

It turned out to be a strange experience, because the company’s needs changed as we made it through the course. I started out working through the Win32 API in C, but the company decided they wanted to use MFC, which I had avoided learning because it revolved around coding behind an interface and so seemed clunky at the time…even though that’s obviously more or less standard procedure, today.

I ended up with a hybrid, starting with Win32 and bridging into manually programming MFC without Visual Studio’s layout facilities. This was because we had limited time left when the company made its decision, and I concluded that the students should be able to pick up the graphical interface on their own, making it a waste of time for me to actually show them the process of dragging a button.

Obviously, these days, the course content is mostly obsolete. I’m sure there are some people still programming against the Windows API as a hobby, but I haven’t heard of anybody making products that way in at least ten years, and it’s non-trivial to even find a compiler that will still work.

Adult Education Courses

Not for Polytechnic University, but rather my local town, for many years I taught a handful of classes for complete novices—a wide assortment of people—in basic computer use.

Introduction to Computers

In discussions with the staff who ran the local adult education program, we realized that these sorts of classes and books are pretty universally terrible. They teach procedures that assume a certain kind of user running a certain computer and become more obsolete as the student gains more knowledge and the systems change.

So, I built a new course from scratch. The premise, which I feel is still legitimate, was that developers and software companies should work hard to ensure that everything a user might need is obvious and convenient for all users. But since the technical people often seem unwilling or unable to do this, the best way to teach the class was to help them understand how programmers think and (to the extent that such a thing exists) the shared culture among software shops.

Starting with getting them familiar with the mouse using the local paint program (I’ve heard of other classes using Solitaire, which strikes me as nonsensical, since it doesn’t provide any persistent feedback) and walking them through an application each session—assisted each week by comically old computers on a slow network—I showed that everything on the screen is a window composed of windows, explained the common desktop metaphors and features, talked about how computers store information (and why it matters to a user, even though it shouldn’t) along with how companies organize ideas based on ownership, and even taught them a little about automation (using the Windows Script Host with very simple VBScript to automate Microsoft Office). I also used the delay in making the computers do, well, anything to explain what was (probably) going on and tell an occasional story of things going catastrophically wrong for the insight of how things work.

Advanced Introduction to Computers

The reaction to the automation lecture was very positive, so we briefly tried to expand it into its own course revolving around handling automation on a home PC as a sneaky way of introducing programming to people. Between a general declining enrollment and probably a non-compelling course description, the course was only ever able to run once.

Introduction to Microsoft Office

Partner to the introductory computing course, I also covered a Microsoft Office course for a few years. I brought the same sort of approach to the course, trying to bridge the user’s mental model to the actual model used by the software.

It was largely successful, but the material was drier, so there isn’t too much to say about it.

Introduction to the Internet

This was an odd course that was briefly tried based on student requests, but didn’t have much more of an agenda than “teach the Internet.” I tried to balance the interests of the students against worries over sending students to commercial sites.

I dug into browser operation, security practices, and the flow of information between websites, in addition to what I considered useful and safe news sources and download sites. It sort of worked, but probably wasn’t very appealing for students who all certainly had different interests and just wanted to shop, play games, and check retirement funds.

And yes, I could have made them more immediately happy by pointing them to Flooz, Pets.com, and Classmates.com, but I suspect that my way probably had longer-term benefits…

Other Teaching and Training

In minor emergencies, over the years, I have also set up less formal training sessions for customers on software and colleagues on new technologies. I don’t have any “materials” on them, since most of the opportunities came up on the spur of the moment and a lot were transient information, but they’re probably worth mentioning for completeness.


Credits: The header image is Classroom by Peter Heeling, made available under the CC0 1.0 Universal Public Domain Dedication. The picture of Polytechnic’s original campus at Brooklyn’s 99 Livingston Street is in the public domain, found on Wikimedia Commons. The Xerox Alto screenshot by SUMIM.ST is made available under a Creative Commons Attribution-Share Alike 4.0 License; the Alto software itself should be in the public domain, since the United States didn’t extend copyright protections to software until 1980.