Since 1996 (and possibly until recently as they reorganize), I have taught at what is currently NYU’s Polytechnic School of Engineering, but has been Polytechnic University for most of the time I have known it and more broadly known as the Brooklyn Polytechnic Institute (“Brooklyn Poly”).
Mostly, I taught graduate courses. I initially picked up electives that nobody was able 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.
After that time, 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 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 done over the years.
(Don’t care? Head back to the main page)
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.
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 marketing. 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. Oops! I suppose it’s better than my initial thought, Back Alleys of Computer Science, at least, even though “advanced” is very 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 integrate 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 for 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.
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 might make a course like this even more useful than it would have been in 2002 when I worked on it.
There isn’t a whole lot to say about any algorithms course, I suppose. 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 classes, under the assumption that the details can be researched in books at any time, or on this fancy new thing called the Internet that everybody’s talking about, whereas the Internet has little to no guidance on working through general kinds of problems and what kinds of solutions to expect.
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 have taught it most summers since.
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) 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.
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. 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.
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.
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 associated 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.
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: 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 context were both downplayed.
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 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.
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…even though that’s 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, 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.
Not for Polytechnic University, but rather my local town, for many years I taught a handful of classes for complete novices (an wide assortment of people) in basic computing.
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) and walking them through an application each session—assisted each week by extremely 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 bit 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.
The reaction to the automation lecture was very positive, so we briefly tried to expand it into its own course revolving around handling administration on a home PC. Between a general declining enrollment and probably a non-compelling course description, the course was only ever able to run once.
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 a whole lot to say about it.
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.
In a pinch, 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.
Head back to the main page