Toggle Mode

Reflecting on Stanford's Code In Place 2025

Clock Icon 22 minutes
grid image taken from our final 'yap' session. posted with consent of displayed people
TOC iconTable of Contents

Introduction

Sometime in early April, a former teacher of mine let me know about Stanford’s Code In Place Program, an online 6-week course offered by Stanford aimed at teaching introductory CS content from their flagship course— CS106A— for free.

I first considered joining as a student— I mean, It looked great! Attend a live zoom with a teacher every week, get certification, and work on a final project (I LOVE final projects).

But then looking at the content, it seemed pretty rudimentary.. This was meant to be an introductory course after all. I had known Python pretty well, so I decided to instead volunteer to become a Section Leader (SL)— the person hosting each of the “sections”: Zoom meetings where 10-15 students join and work on a problem together and clarify any of their concerns.

But then again, I’d have to teach for 6 weeks, spanning my school exams, APs, and even graduation. I was worried I wouldn’t be able to keep up with the responsibilities.

Still, I applied anyway. And now, two months later, I’m sitting here writing this reflection—having just finished leading a section of 16 students through CS106A. Fittingly, at the time of writing this, I would usually receive a reminder telling me section is in 24 hours :(

Applying

The application process to become a section leader was pretty simple:



Onboarding

After getting accepted, I had to pledge that I would make and prepare for section over 6 weeks. I then had the option to choose what time and date I wanted to hold section, and there were offerings from Wednesday to Saturday if I recall correctly. I personally picked Friday 4 PM my time. I also notably had an option to refer two students to the program and they would be automatically accepted.

I now had access to the Code In Place platform. A small on screen tutorial showed me around the website. I will attempt to summarize each tab.

The Website

The Teacher Home:

would allow you to view all your students, the number of assignments they’ve completed, the number of lectures (online videos) they’ve watched, and which sections they have attended. Additionally, it would allow you to go to their actual solutions for each assignment and run it for yourself on the Stanford provided IDE.

The Student home:

emulates what a student would see, as expected. It is neatly organized into week by week lectures, assignments, and any additional tests or events.

In this tab, you would be able to create your own projects and run them with the Stanford IDE or access a list of all assignments and work on them. There are also optional questions which are much more algorithmically challenging to solve.

It also had bonus optional extensions for each of the problems, which my students found particularly stimulating.

Main Forum:

Everyone in the program can access this forum

Section Forum:

Only you and students in your own section had access to this forum. On the Section forum, you also had an option to email all of your students and make announcements which would appear at the top of the forum.

Teacher’s Forum:

A forum only with Code In Place staff and teachers.

Main X Forum:

A forum with experiences students: students not assigned to a section who would navigate the course alone.

The forum/platform’s WYSIWYG text editor was very convenient, as you could format text in several different ways and also embed links, code, quotes, images, and a lot more. You also had the option to make your posts private or anonymous.

Training for Section

Before leading my first section, all section leaders had to join a 1.5 hour live training session where we went through the course expectations and standards. It was led by a head Teaching Assistant (TA) who was a former SL herself. She was our main point of contact regarding any issues or problems we had with section, including if we couldn’t make section. We were also put into breakout rooms and practiced teaching with other section leaders and shared feedback together. We had to do this twice throughout the course— once before our first section and once after— for a total of 3 hours of live training. The second session was particularly productive as we all shared resources we were planning to use for section. Further practice sessions were also carried out at the same time weekly, but they were not mandatory.

First Section

Finally, it was time for my first section. I remember being insanely nervous for it, so much so I thought I’d develop a case of restless leg syndrome because of how much I was fidgeting. I also remembered the founders of Code in Place— Mehran Sahami and Chris Piech— sharing tips they had for what to do before teaching and tried to go through them. I played some of my favorite music, and when I could finally open the meeting, I did.

At first, I only had 2-3 students join despite having 15 students in my section. I told them (and myself!) people would start joining and that we were quite early. I was luckily right, and soon I had to constantly accept people from the Zoom waiting room. This was actually one of the technical difficulties I had in the first section— I would have to constantly accept people manually. Luckily it was resolved by my second section.

What struck me the most was the great diversity of people wanting to code— medical students, entrepreneurs, chemistry majors, flooring professionals, and even other CS students looking to learn Python. This diversity was motivating, but beyond that it also became a great way to show how in-demand basic coding skills have become. I tailored a few analogies to the students’ backgrounds; I showed the flooring professional a Karel assignment we had where we had to tile the grid in a specific pattern, similar to actual tile layouts.

I really emphasized setting the culture for my section in the first session we had, and it percolated over to the next sessions very well. When we had everyone in the meeting (I think 13-15) people, we all introduced ourselves for a good 10 minutes before moving on to the actual problem, which was a vestige of Code in Place’s COVID origins: We had to use Karel (a small robot guided by Python) to “build hospitals” on a grid of cells given a certain condition was met.

Karel only had four commands, which made it very easy to learn. It could turn_left(), turn_right(), move(), put_beeper(), pick_beeper(), and also had a few methods which returned booleans like front_is_clear(). This made it really useful for practicing functional decomposition and teaching core programming paradigms. Furthermore, you weren’t allowed to use variables or return statements with Karel, forcing experienced students to come up with algorithms they wouldn’t have thought of before (see Section 2 problem!).

Before starting to code, I made it clear that I would prefer if everyone had their cameras on, just so I could gauge their understanding by looking at their faces every now and then. I think this was super important and it set the standard for the rest of section, as I would always have a majority with cameras on.

The problem itself went by pretty well, we went through different routes and explained why they wouldn’t work or how we would adjust them. I also tried as much as possible to let the students themselves write the code, so in the end we could have a chimera of code and functions working together to solve the problem.

Another aim was to handle off-by-one errors. The Stanford IDE made this very convenient: it allowed us to see code execute line by line. I think a great advantage of Code in Place was the ability to code in front of the students. It allowed us to actually run the code and see what happens in real time and how simple changes, even in code order, can lead to very different results. We also had built-in Karel & basic Python documentation which allowed us to quickly check for what method names or outputs. Overall the coding experience was great and I did not run into any technical difficulties on the IDE.

Teaching the problem and seeing how curious and willing to learn the students were quickly chipped away at my angst and moved me to the “zone” I’m sure you’ve felt if you’ve taught before. Everything just comes out smoothly and if it does not, it becomes a learning opportunity.

We finished teaching the problem and I clarified any concerns the students had. We finished just in time, and I had a bit of free time afterwards so I decided to stay in the Zoom meeting just to see if anyone would warm up and feel more comfortable to ask more questions or just have a little chat. Thus, the after-section-yap-session was born, a huge part of our section’s culture. After every section, I would let the students know that section was over and they were free to leave, but I would remain in the meeting if anyone would like to ask anything or chat. This worked super well, as people started asking me more about coding and also myself. Maybe 8-9 students stayed every time, and we would start by clearing up some more important concerns about Code in Place or CS, then moved on to just chatting about our lives. We got to know each other very well as a result of these “yap sessions”, and a student later said they always looked forward to them after section.

Missing Section Protocol

Before I move onto the remaining sections, I’d also like to highlight what would happen if you missed a section. Thankfully I made all of my sections (there was no WAY I was missing my yap sessions), but Stanford had outlined what would happen pretty clearly:

Students evidently had similar conditions, I think it went something like:

Subsequent sections and some section culture

After the first section, I realized how special section really was to me. I first thought that the responsibility of managing section would be too great for me to manage— that I’d be overburdening myself in peak exam season. But section was a place where I could go to give back to the community and also “zoom out” from all the stress of exams. It genuinely had such a positive impact on me that I’ve vowed to volunteer to lead section again next year. However, I will always look back at this first group of students with beaming pride and gratitude. They truly made section so lively and enjoyable.

In my next sections, we had 2 new students who were joining from other sections— one to join a temporary make-up session and another looking for a new section. I wear it as a token of great pride that the second student liked us so much (I hope!) that he joined us for the rest of the course! So I now had 16 students every section.

Section 2

The second section had a more algorithmically challenging problem– Karel had to distribute a pile of $n$ beepers across the row it stood on. Again, Karel cannot count (no variables or returns), so this problem was a bit harder for the students.

We went through different algorithmic ideas and wrote faulty code before reaching the canonical solution. Writing the faulty code was very productive– both the students and I got to brush up our debugging skills!

I also started trying different things for upcoming sections.

bCode

I needed a platform allowing several people to collaborate on one IDE while also allowing me to monitor everyone’s work. bCode fit the bill perfectly.

For my third section, I decided to use bCode to allow people to all work on the problems in either breakout rooms or individually. The UI is pretty intuitive, and you’re able to set starter code up and allow students to run their code. We organized everyone into groups based on their breakout room number, and everyone got to work. I think this was one of the most productive tools I used. I would check in on all the breakout rooms periodically to check for issues and ensure everyone was collaborating. It worked especially well with some of the people who used chat to communicate, because they began to open up and interact via mic in these breakout rooms.

Beyond highlighting the obvious wide variety of solutions that existed for a single problem, it also allowed for some pretty neat (and funny) learning moments afterwards when we reviewed everyone’s code.

GPT antics

One of the funniest moments (in my opinion) in section occurred when we were working on building a program to convert weight on Earth to any of the 7 other planets (sorry Pluto..). For context, the conversion factors were given in the problem. But we had also recently learnt how to call GPT within the problem. So when we were reviewing everyone’s code at the end of the bCode session, I moved to someone’s code and noticed the first line was from ai import call_gpt.

Oh no. Had they just asked GPT to solve the entire problem?

No. They had taken the planetary input and asked GPT to generate the conversion factor for them. This avoided checking against the user input, something I’m assuming they struggled with. After realizing what he had done, the entire section burst into laughter and the incident became a running joke in section.

Menti Polls

Another tool I used were polls, via Menti. They allowed me to give the students some freedom, and I allowed them to vote on if they wanted to work individually or in breakout rooms. It was also completely anonymous. We also used Menti to simulate the behavior of a short game we were tasked with building. Overall, Menti was easy to use and I would definitely use it again for polling.

Extensions to problems

One of the most enjoyable and productive things we also did, in my opinion, was build our own extensions to the problems. It allowed us to really get into the programming mindset and think of how the different parts of our program worked together, beyond what was given in the problem. A notable example of this was in a problem where we were tasked with using graphics to draw a bunch of random circles. The function generating the random color was already given to the students, but our extension involved building it ourselves with random.randint() instead. And later, we extended that beyond the predefined colors and into any hex color.

I also tried encouraging this mindset by telling them to think of how some of the predefined methods (eg: for the random package: shuffle(), etc.) worked under the hood before telling them to try building their own implementations of them.

Discord Server

In our 5th section, I decided to make a small discord server for the students, just so we could stay connected in the future and also if any of them needed help with their final projects, they could communicate together there. This worked pretty well, and people are sharing their projects and also asking for help decently often. We also made a resources channel with some resources for if they want to further their knowledge.

Moving away from Karel

Another fun moment in section was when we finally moved away from Karel and into actual Python. In the last Karel section, I had expressed my disdain for Karel’s unintuitive orientation.

See; at first glance, you’d assume Karel’s “left” refers to the cell to our left. But no—Karel is viewed from above, and her left is actually the cell above her in our perspective. Still, the little feet at the bottom suggest a side view. It’s confusing, and methods like left_is_clear() don’t help.

By our final Karel session, I changed the Karel icon in the IDE settings to a turtle—which made it clearer that we were viewing the robot from the top. This led to a cathartic rant during our yap session… and a celebratory meme in the next week’s Python section:



Yes, I’m very proud of my meme-making skills :P

Final Section

And finally, one week ago, I hosted my final section. It was bittersweet, but the problem we worked on was quite fitting for the final section— it involved making a terminal game of Heads Up, and everyone would get a turn to describe a word that I had to guess. After finishing section, I had planned out a Menti game where we would all vote on a few superlatives for each other (“most likely to forget an indent..”, etc.), which gave us a bit more closure. We also had a longer than usual yap session and also took a few pictures together.

And that was it— 6 weeks of Stanford Code In Place, ending with a click on “End Meeting for All” :(

What I would do differently

Honestly, this was one of the best experiences I think I could’ve had. My students were ideal, the technical issues were minimal, it was easy to navigate and explain the content. I would genuinely recommend volunteering as SL to anyone reading this, regardless if you have prior teaching experience or not.

I’m having to think really hard in order to point to something specific to change, but here’s a (non-)comprehensive list:

I suppose I will update this as list as things come to mind :)

Closure

Leading section was an incredible opportunity that I am infinitely grateful for discovering. It genuinely surprised me how close we grew in such little time— how rewarding it felt to be able to give back to a group of people looking to learn how to code. Despite starting off quite anxious, I found myself energized each week by the diversity and also growth of my students. Teaching really challenged me to think more clearly, communicate effectively, and build a fun environment worth coming back to every week. It was also a lot of dedication for these students: show up every week, do 30+ assignments, watch lectures, build a final project, and do a final test.

I’m leaving this experience with a full heart, a screenshot of a zoom grid, and the certainty that these students— whether they keep coding or not— will do incredible things. What started as a spontaneous application between my exam prep ended up becoming one of the highlights of my year. I’m incredibly thankful to my students (I know I’ve said this ad nauseam), but also to the entire Code In Place team who made all of this possible behind the scenes.

I walked in hoping to give back— what I didn’t expect was how much I’d take away.

I can’t wait to do it all over again next year.

Thank you, CIP 2025 <3