In 2023, I spent 6 weeks leading a section of about 14 people hailing from China, Brazil, Germany, India, Japan (and more countries!) as part of Code in Place, and got to experience the joy of seeing people write their first for-loops :) We met for an hour a week on Zoom, but my personal estimate for how much time I spent on Code in Place including preparation + writing weekly recaps was about 4-5 hours a week (including class time).

If you’re someone who’s wondering about whether to apply for Code in Place as a section leader, I hope this encourages you to give it a go. I had a really good experience. Applications open around April each year.

Code in Place is a really special thing to me, because:

  1. It’s free! (invites a more diverse student body)
  2. Everyone’s attending because they want to (as opposed to it being a compulsory class in school)

Being a beginner is a gift

I worried about whether I was qualified enough as a programmer to even try teaching anyone since I wasn’t a CS major, nor do I work as a developer professionally. But in this case, being a beginner is a gift if it helps you empathise with your students more easily.

At the time I was teaching, I was also in my first semester of taking CS classes part-time. Before that, I’d never had any formal education in CS, and my undergrad degree wasn’t “technical” (non-STEM). This is something I usually feel awkward/ashamed about, but here it became something that helped me build rapport with my students.

Finding the right format for the class: Pair programming + weekly roundup posts on the class forum

Pair programming

My first class ended up more like a lecture, and I felt terrible at the end of it because I felt I did poorly at engaging students. I wrote this on the class forum after class:

Forum post to a class titled: “Next week - changing formats”. The content is as follows: Today, we did a big group gathering where I was in charge of coding, and asked all of you for help about what to do. Next week, let’s try out a different format: Everyone will be put into pairs for breakout rooms where you will collaborate with your teammate on the problem. Afterwards, we will discuss the problem together, and talk about how your breakout room’s experience was like. This will be a chance for everyone to try out pair programming. I’ll talk more about it at next week’s session. Sorry if today was not a great experience — I am trying to figure out what works best, and to become a more effective facilitator. I want to make this as good of an experience for you all as I can, because I really appreciate that you’re taking time out of your busy schedules to attend Sections. I want to make Sections a good use of your time. Thank you for your patience and see you all next week 💞

The following week, we tried out pair programming and the feedback from the class was much better – I realised that I should be trying to maximise the amount of time they have to collaborate with others and do coding themselves.

Our weekly Section ended up being structured like this:

  1. Introduction of the problem for the week
  2. Breakout rooms for pair programming
  3. Code Show & Tell by each pair/group on:
    1. Their approach to solving the problem
    2. Challenges they faced
    3. Any interesting things they came across?

Weekly forum posts

After each section, I’d write down a recap of what we worked on and + responses to questions that I couldn’t respond to on the spot in class. Having a record of what we did helped in the following ways:

  1. Students who couldn’t make it for class that week could still get an idea of what happened, and
  2. Students who attended class get to a chance to recap and review, and
  3. I get more time to think and respond to questions, as opposed to having to say something on the spot. I also get to highlight some really good observations made by students in class :D

Random aside to just talk about some really great questions

Teaching is fun because of the questions you get. One really fun one was “If we’re writing code in Python, then what language is Python written in?”. This was something that I didn’t really know how to answer on the spot, so I ended up looking into it and responding in the weekly forum post. I got to learn more about language specification vs implementation. The TL;DR of this is that there are multiple implementations of Python, but the one that contains the specification of Python is CPython. Very fun :)

Norm-setting in class

Accessibility

Some things that I’d do from the start if I did this again:

  • Start enabling Closed Captioning by default on Zoom (I realised students were enabling this themselves when I should’ve just enabled it by default)
  • Check if there are students who don’t have access to a laptop. I had a student who was using a tablet which made it hard to be on a Zoom call and code at the same time, so they were usually assigned to the “navigator” role in pair programming.

The hard problem of coming up with introductions/ice-breakers that don’t feel weird

It’s really hard to think of good ice-breakers. The usual one I had in university as a student at orientation activities was “Tell us one fun fact about yourself”, which inspired the same kind of mental glitching/short-circuiting that “What do you want for your birthday?” creates.

A good ice breaker would ideally give someone a lot of autonomy over what to answer, reveal something about their personality/values, and make as few assumptions as possible.

As an illustration by counter-example, here’s what I think is a terrible ice-breaker (just for illustration, I hope nobody sincerely ever asks this):

So, what does your father do for work?

What I eventually used for introductions was:

  1. How should we pronounce your name?
  2. What’s something that you’re proud of yourself for?

This ended up being a great icebreaker but the mileage might vary for larger classes (maybe doing this over forum posts would work better instead).

Normalise making mistakes

An important part of teaching is trying to remove the moral element of failure – where making mistakes seems to involve some kind of judgment that you’re “bad” in some way. As Jake the Dog from Adventure Time says: “Sucking at something is the first step towards being sorta good at something”.

I try my best to model treating mistakes with a sense of curiosity. If there’s an error, what does it show us? Are there certain things we now know about this bit of code that we didn’t notice before? Isn’t that nice? I also got to model failing with that first class’ format, changing formats for the next week and getting the help of the class to give me feedback on which format they liked more (pair programming won by a very far margin).

Changing the way I talk about myself

Code in Place made me stop talking down to myself. I have a tendency to hedge my language a lot and minimize what I do. I say I am just a hobbyist, or I only do very basic things like some web scraping or whatever because I don’t think I’m skilled, I don’t have a CS degree, I’m not a professional software engineer blah blah blah.

I never had a strong wake-up call to change the way that I talk about myself until I started teaching, where I realised – as a teacher who has had more programming experience than my students, if I talk about myself like this, what am I inviting my students to think about themselves???

It’s kind of like that therapy thing where you have to take what you say to yourself, and imagine that you’re saying it to the 5 year old version of you. Would it be okay?

Now, even when I’m not teaching, I try to focus on introducing myself with what I’m learning and what I’m curious about, rather than hedging/minimising.