Tomorrow I start teaching two courses at DePaul. One is Intro to Databases, which I’ve taught before. The other is Intro to Containers, which didn’t exist until I wrote it.

I pitched it and I built the whole thing. Ten weeks of it. Tomorrow is the first time anyone other than me has to sit through it.

The reason goes back to 2017, when I got my masters there.

I went back for it because I knew exactly what I was missing. I wanted to be better at programming and at networking, and that’s what I went in for. It worked. I came out stronger in both, and my career opened up because of it.

Well, stronger in programming. The networking I still lean on my colleagues for, and I’ve made peace with that. Thanks, Thomas!

I’m not writing this as somebody who feels shortchanged by the place. I got what I paid for.

But something else happened while I was there that I wasn’t expecting.

I was already a senior DevOps engineer while I was taking those classes. So I’d sit through a lecture, and then afterward I’d end up teaching other students how to use git. I’d walk them through how code actually gets from somebody’s laptop onto a running system. What a pipeline is, what happens when you merge, how a build turns into something deployed that people are actually using. Nobody was teaching them that. The CI/CD that did make it into a lecture was closer to the early 2000s than to anything running in production anywhere I’d worked.

The gap was never in the fundamentals. Those were taught well, and the fundamentals are the part that doesn’t expire. The gap was everything sitting between writing code and that code running somewhere real. Version control the way a team actually uses it. Builds that happen without a person doing them. What it means to hand your work to a system that packages it and ships it and tells you when you broke something.

Then one day a professor’s emacs stopped working in the middle of class, and I walked him through editing the file in vim so he could keep the lecture going.

That’s when it hit me. There were things I did every single day at work that weren’t making it into that room at all.

I don’t put that entirely on the professors. If you’ve spent your whole career teaching instead of building, you can only teach what you know, and nothing about the job forces you to stay current. That’s a real constraint and I understand it.

But this is technology. It changes constantly. Staying curious about how software is actually being built and run isn’t optional in this field, and I don’t think it stops being true for the people teaching it.

The students are the ones who pay for that gap. They do genuinely hard work for two or four years, they graduate, and then they sit in an interview and get asked how they’d package a service and get it running, and they have nothing to say. Not because they couldn’t learn it. Because nobody put it in front of them.

I’ve been answering the same question in office hours for years. Not about containers specifically. About the jump. How do I get from what I did in this class to what you do at your job. At some point it started feeling ridiculous to keep answering that one student at a time when I could just build the class.

So that’s what this class is. Almost every company I’ve worked at or talked to runs containers, and most of them are running Kubernetes on top of that. It’s not a specialty anymore, and it’s not just a DevOps thing either. It’s how applications get built, shipped, and kept running, and developers are expected to understand that whole path now, not only the code they wrote. I wanted students leaving DePaul having actually done it instead of having heard the words.

The whole course points at one outcome. By the end of week ten, a student can sit in an interview and say they built an application, containerized it, published the image, deployed it to Kubernetes, and watched it roll back when they broke it. Not read about it. Did it.

Here’s how the ten weeks actually work.

Every week has two pieces. A lab we do together in class, and a homework assignment that takes whatever we just did and applies it to their own project. They’re on teams from day one and they choose what they’re building in week one, so nothing is a throwaway exercise. Every assignment is another piece of the thing they demo at the end.

Week one is concepts. Images versus containers, the core Docker commands, and a lab where they run containers I hand them and document what those containers actually do. Week two they write a Dockerfile from scratch and containerize their piece of the team project. Week three is Compose and standing up a two or three service stack locally.

Week four is where it changes. That’s CI/CD and GitHub Actions, and the homework is a pipeline that builds their image and publishes it to a registry on every push. From there on the registry is the handoff point. CI/CD isn’t a topic they finish and move past. It’s the thing everything after it runs on.

Week five is the midterm, conceptual, covering the first four weeks. The second half of that class is a guided Kubernetes orientation so nobody walks into week six cold.

Week six is the mental model: pods, deployments, services. Their lab is deploying the image their own pipeline built to a local cluster. Week seven is configuration and secrets, scaling, and readiness and liveness probes. Week eight is networking and ingress, and that’s the week their services have to talk to their teammates’ services. Week nine is the reliability pass: resource limits, rolling updates, logs, and a rollback drill where they break something on purpose and recover from it. They also write up their architecture and turn in an individual reflection that week, because I want them explaining their own decisions in their own words.

The pipeline grows the entire time. Build and push in week four, linting and validation in week seven, Kubernetes manifest validation in week eight, and by week nine it has a deploy step and a rollback. By the end they haven’t just learned what CI/CD is. They’ve watched one get more serious as their application got more serious, which is how it actually happens on a team.

Week ten is presentations. Each team builds, containerizes, deploys, and demos the whole thing live.

That’s the part I’m proud of. It’s also the part that scares me.

When I picture this going wrong, I don’t picture a bad lecture. I picture week six, the first real Kubernetes week, and half the class is lost.

The students walking in tomorrow are not starting from the same place. Some have done an internship and already live in a terminal. Some have never installed anything more complicated than an IDE. Ten weeks is short, and with a team project running the entire time, that gap compounds. By the time we’re deploying to a cluster, the ones who fell behind in week two aren’t a little behind. They’re gone.

Then there’s the team part. Every group project I’ve ever been in had one person carrying it. I wrote the assignments to make that harder, individual components and reflections, but I’m not naive about what actually happens.

I don’t have this solved. I have a plan, office hours, and a willingness to slow down and lose a week if I have to. I find out in about six weeks whether that’s enough.

The other thing I didn’t expect was how it got approved.

The course had to go through a curriculum committee. I wasn’t able to present it. Someone delivered it on my behalf, and I was never told why it worked that way.

I don’t think anyone was working against me. That’s not what this is. But I wrote it, I knew why every single week was where it was, and the case that got made in that room wasn’t the case I would have made. Somewhere between my hands and that meeting, the context thinned out.

It got approved, and that matters. But it runs once a year, it’s an elective, and it’s undergrad only.

That last one is the one I keep chewing on. I asked for it to be open to masters students too and I lost that. Masters students had already come to me asking about this exact class. A lot of them are working now or trying to move into tech, which puts them closer to needing this than anybody. They’re interviewing next year. Telling them the class exists but not for them is a hard thing to say.

A couple weeks ago I wrote about decisions getting made in rooms you’re not in. I meant it about careers, about who says your name when a project comes together. It’s the same thing here, and I didn’t see it coming, because I assumed a curriculum proposal would be judged on the curriculum.

It’s not only that. It’s also who’s in the room, and how well someone else can carry an argument that isn’t theirs.

So that’s what I’m taking into next year’s version. Not a better syllabus. A better sense of who I need to talk to long before it reaches a committee, and what they need to already believe by the time it does.

None of that matters tomorrow. Tomorrow there’s a room full of students who signed up for a class that didn’t exist last year, and I’m the one who has to make it worth their quarter.