Online Course Attendance


Dave, January 1, 2021

First, and foremost, thanks for considering a course! In different times, we might be meeting here face-to-face in Chicago, but since the pandemic, my teaching has moved to a live-taught online format. This page has a little information about how I offer courses online and what to expect.

General Overview

I have been teaching courses to small groups for more than 16 years, both as on-site corporate training and my open courses in Chicago. Before that, I spent 7 years teaching computer science courses as a university professor. In offering my courses online, my goal is to create an environment where you will be challenged and where you can interact with other participants. All courses are limited to about 12 attendees. They are live-taught and assume your full involvement during the week (meaning approximately 40-50 hours of work). I do not operate a MOOC. Courses are not passive nor do they involve passive content (i.e., watching prepared videos, slide decks, flipped classroom, etc.). Do not register for an online course unless you can fully commit time to it.

Questions and Answers

Q: How is a course delivered online?

A: Zoom is used for live presentation, screen sharing, demos, and discussion. All other interaction, including code review, debugging, Q&A, and other code-related issues take place through a shared private GitHub project. Everyone works independently, but in their own branch of the class repo.

Q: How is course time structured?

A: All of my courses involve coding projects. In a typical course, approximately one-third of the time is spent in live group discussion. The remaining time is spent on coding. These activities are spread out throughout the day. A typical day might involve 4-6 discussion periods intermixed with coding work. I find that mixing it up like this provides a better experience--if you're stuck on a coding problem, you don't have to wait too long for it to be discussed.

Q: Are there official prepared "presentations" like at a conference or in college?

A: Not really. As a general rule, I try to structure courses in a way that is more conversational and free-form. The focus is on active problem solving, not prepared presentation. Although I will sometimes use prepared slides to help illustrate complicated concepts (i.e., to talk through an illustration or figure), I tend to prefer a mix of live-coding and group discussion over passive "watching." Much of the course discussion takes place in the context of the current coding problem--so it is more common to review some part of the code and have a discussion centered around that. Topics often vary widely depending on earlier design choices and overall progress. Every course is different.

Q: Do courses involve any group activities, pairing, or forced interaction?

A: No. Although I "get" how some instructors might try to drive group engagement through structured team activities, I've never really liked that sort of thing as a student or a professional. As such, it's just not my style. When taking a course, you choose your level of involvement. At no time will you be forced to work with others, answer direct questions, or involuntarily be called upon to do something in front of the group. That said, I'll still do my best to create an environment where you can engage in friendly conversation.

Q: Do you rely upon any "canned" solution or skeletal code?

A: In college project courses, it is sometimes common for an instructor to provide a partial solution or some kind of skeletal architecture in which you are supposed to do your work (i.e., by filling in bits and pieces of code to an already existing project). You might even get some pre-written tests. As a general rule, I don't do this. Figuring out the system architecture and coming up with a strategy for testing it is part of problem solving in the real world. Although I will often offer "advice" on how to avoid nasty problems that I happen to know about, I am equally likely to let people roll with a "questionable" design decision just to see how it later unfolds.

Q: Do you force people to use a certain programming environment or tooling?

A: No. You can use whatever development environment you wish. Courses usually have no package or tooling dependencies. Project courses such as "Write a Compiler" or "Rafting Trip" don't even have a stated implementation language (although I'll commonly use Python to illustrate concepts).

Q: Do you provide solution code?

A: I work on the course project "live" at the same time everyone else is working on it. I periodicaly push all of this work to the course GitHub repo where you are free to look at it (or copy it if you wish). However, I am often working through the same design challenges, bugs, and other problems faced by everyone else. I will often hit dead-ends and have to refactor parts of my code as I work on it. It's probably better to view this code as "work in progress" as opposed to an official solution. I don't work from a prepared solution--the final code ends up being different every time I teach a course.

Q: Are sessions recorded?

A: Partially. I record all portions of the course where I am officially presenting material or guiding group discussion. However, significant portions of a class involve individual coding and project work. Those portions are not recorded. During work time, it is more common for group-interaction to utilize online "chat" instead. Just to give you an idea, in a recent online version of the Rafting Trip course, I recorded about 14 hours of video. Note: course video is NOT posted in any public forum (e.g., YouTube). The purpose of these recordings is to have a course record (often to help people in different timezones), not to make content for my channel.

Q: How long do I have access to materials?

A: Each course has its own dedicated GitHub project that collects all work and materials. This project lives on indefinitely after a course has concluded. You can access it any time after the course is done. I can't promise that GitHub will exist for all eternity, but my intention is to preserve the course record so that you can look at it later.

Q: Do online courses also include in-person attendees?

A: No. An online course is only offered online and is given my full attention in that format.

Q: In what timezone are courses taught?

A: Unless otherwise indicated, courses are taught 9:30am-5:30pm in US Central Time (Chicago) with approximately an hour for lunch.

Q: Can I take a course and work my regular job at the same time?

A: It depends--do you want to finish the course? If the answer is "yes", then the answer to this question should probably be "no." My courses are intense and demand your full attention. If you are attempting to multitask, you will likely fail. It highly recommended that you ask your employer for time off for training and development.

Q: What are some unexpected benefits of online instruction?

A: You get a far better working environment for coding--you can use your regular work computer with multiple monitors, nice keyboard, speakers for playing music, etc. There are also many opportunities to take a break, go get a snack, walk the dog, and so forth. Ironically, group interaction is often *better* in an online course because discussion has more permanance about it--taking place in an online forum where there's a record as opposed to a fleeting in-person verbal exchange.

Q: How long will you be offering courses online?

A: Although the pandemic prompted me to start offering courses online, I plan to continue offering online courses for the foreseeable future (even when I resume in-person teaching). I've had a positive experience with online courses over the last few years so I will continue to offer that as an ongoing option.

Q: When do you foresee a return to in-person instruction?

A: At this time, it's very hard to say given the current state of the world. However, when in-person courses do return, it will very likely be in the form of a "summer school." I offered a limited set of summer courses in 2023, but future scheduling is currently uncertain.


Copyright (C) 2005-2024, David Beazley