Teaching Tech: My Adjunct Experience in Academia

I’ve always liked Chef Gusteau’s motto, “Anyone Can Cook,” especially when you apply it to writing code. It perfectly captures how I feel when introducing people to the world of software creation. In my various software engineering roles, I’ve always tried to carve out time for teaching or training, as it is a passion of mine.

Recently, I took this a step further by becoming an adjunct CS instructor at my alma mater (Go Bucks!). In this blog, I’ll take you through my experience, and maybe convince other engineers to give it a go as well!

My Journey to Teaching

Teaching to Learn

Teaching has always been the way that I learn. Throughout school, I would grasp a concept and then try to explain it to anyone who would listen. If they didn’t get it, I’d change my approach and explain it differently. This cycle solidified concepts for me, and I got to see the joy in people’s eyes when something “clicked.”

When I started learning more challenging subjects like advanced math and programming, people often assumed these concepts were too complex for them. But since I learn by teaching, I had to find ways to strip away the jargon and fluff, breaking down these concepts into simple terms. Before I knew it, my friends who had no prior interest in CS could write simple programs.

Teaching in College

This all led me to more “structured” teaching in the form of tutoring. At Ohio State, I tutored various CS classes such as Intro to Programming, Algorithms - Runtime Analysis, and Information Security. This brought different expectations; now, rather than just helping someone learn, I was also helping them improve their grades, which can be very different. I was used to helping people apply concepts, rather than simply pass tests. Even though this shift was grosser, it was still fun and rewarding. However, it did curb my desire to teach academically...temporarily.

Teaching In Corporate America

Once I entered the workforce as a Software Engineer, I found ways to continue teaching. Luckily (and unfortunately), I was in an organization that was shorthanded from an engineering standpoint. This allowed many new hires like myself to shape technical direction and up-skill people in non-technical roles. For about three years, I taught Python, React, CI/CD, and serverless architecture to anyone who would listen. This was a much more enjoyable experience because I could focus on practicality and directly tie content to people’s current problems.

A Few Lambda Lessons Later -> $20

Motivation

Even though I had carved out teaching roles within my engineering roles, I knew I still wanted to teach “for real.” Some of the most impactful professors I’ve had were adjunct professors. In my Systems 1 class, our professor introduced us to a “Terminal.” I wondered why I’d ever use this to list or create files when I had a perfectly good File Explorer. Then, I saw the myriad of ways my teacher used the Terminal in his actual job. Later that semester, instead of working on more theoretical low-level systems material, we learned how to use IDA to reverse engineer a real piece of software! These practical applications inspired me and planted the idea of teaching on the side in my brain. Shout out to Domas!

Taking The Leap

I saw a LinkedIn post from one of my old professors saying that they were looking for CS adjuncts for the next semester. The process was refreshingly simple compared to what I was used to in the SWE world. I sent an email and my resume and with a few of my old professors vouching for me, I heard back that same week with potential class times. I opted for a 3 credit hour Intro to CSE class with 200 students from 9-10 AM Wed/Fri.

Now, I just needed to make sure my day job was cool with it 😅.

Dramatization

Alright, time to teach!

Teaching

The Logistics

I accepted the role to teach CSE 1223 at tOSU. The class was around 200 students, but I would have 2 GTAs for labs and 4 TAs for grading and questions. The school also had a curriculum and some starting content that I could use to prep my lectures. With all this help, it didn't seem like a big time commitment. I thought I'd be able to spend 2 hours in class and then ~4 outside of class creating content and answering questions.

Optimistic adjunct professor

In Class

Class time was always a blast! My approach was to always connect the material to real things I do as a software engineer. I also made sure to emphasize the relative importance of topics. For example, although the course weights them equally, debugging is a much more practical topic that java method decoration. Additionally, while slides were useful context, I spent at least half of class stepping through real code examples and having students write code live with me. This, was a very effective way to help simplify hard sounding concepts. Most importantly, whenever I was about to move on I would do a heat check with students: "Does this make sense". If I saw any confused faces, we would take a step back and build back up to the problem, or try a similar example.

Outside Of Class

Remember how I thought I'd spend 4 hours a week on questions and content preparation?

My face after a 20 hour week

The extra time I spent wasn’t always bad. I frequently worked on real-world code examples to support the topics we were covering. This helped students understand the material better, so it was a win! I also enjoyed spending time in office hours working with students who were stuck on a project or wanted to dive deeper into a topic. However, the vast majority of unplanned time stemmed from the same source as it does in the workforce.

To make matters worse, 96% of the emails (yes I counted) were grade disputes, assignment extension requests, assignment drop requests, or some other grade related thing. It is worth noting that this class had very liberal policies, dropping the lowest 2 quizzes, homeworks, and projects. This drop policy was intended to allow students to be able to miss some assignments and still do well in the class. Alas, it did not stop the daily emails requesting more tweaks to grades.

As a 20-something yr old cool adjunct professor I made the mistake of accommodating too many people early on. I'd re-open a homework for a student who overslept, or give a second attempt on a quiz when someone's internet dropped. However, if you make these concessions for the first few students, it wouldn't be fair to deny the ones who come later. So, I fell into the trap of enabling students to grade grub, which is a huge time sink. 0/10 do not recommend. I fully understand why so many of my professors were sticklers to their policies. It's simply not manageable to hear everyone's reason they need a quiz re-opened or an extra point back on a question.

I will note that students who were engaged, came to office hours, or put in a ton of effort, I was always happy to discuss potential ways to improve their grade.

Thoughts

Me at the end of the semester

I love teaching. I hate most emails.

How'd I Do?

Either my students are liars, or they loved me I'm not sure which yet. On the last day of lecture a bunch of students let me know how much they appreciated the way I simplified coding concepts and did so many live examples.

My instructor evaluations were great, and more importantly I made it to RateMyProfessor 😂

Would I Do It Again?

I would will, but there are caveats.

Money

One thing I neglected to mention is the compensation. It's known that teachers are extremely underpaid. However, for many college majors, academia can be one of the more lucrative options. This is not at all true for Software Engineers. To the point that a bi-weekly paycheck from your day job can be larger than an entire semester's pay as an adjunct. If you are an engineer that plans to teach, it should be because you are passionate about teaching, definitely not for the money. Also, I had to pay for parking which made me sad.

Time

I talked about the issues I ran into that made it a time sink. I believe that being more strict on policy could largely resolve this. Next time I teach, I plan to automate as much as possible. Specifically, I’ll keep the policy the same and require all students to email me in a structured way: Subject: CSE <class_name> - <assignment> <request>. This will allow me to write automation that grants each student at most one out-of-policy exception and auto-ignores any other emails. This would even be some cool code to use in class examples :)

Alternatives

Right now, I’m not teaching professionally. Instead, I’m scratching that itch by volunteering and teaching family and friends. I’ll probably teach again at some point in the near future. As a worst case scenario, I’ll teach when I retire from my day job, assuming that I would still be effective. Until then, everyone around me will have to continue dealing with me teaching them concepts that they probably don’t want to learn!