This post was originally written Fall 2017 for CS 61A staff.
The purpose of discussion and mentoring sections is to provide a space for students to recognize patterns and construct mental models for solving programming problems. To achieve this broad goal, we’d like for students to spend time thinking critically about not only the concepts themselves, but their perceptions and understanding of the material. Through discussion section and mentoring, students have a unique opportunity to get hands on with problems while still supported by your guidance. The importance of having a trustworthy mentor throughout this process is hard to understate.
Here are a few universal principles that encompass the majority of the feedback I give to teachers.
Focus on ideas
- Design lessons around ideas. Before showing how to solve a problem, present the intuition and ideas in plain English. Better yet, come up with a more general approach, write it on the board, and have students try out a problem with the most general instructions in mind so they can compare their application of the general rules to your intuition.
- Don’t let the worksheet shackle your ideas. Your ideas and experience comes first and foremost. Share what’s really important to you with students. The worksheet questions only serve to provide structure to help guide the experience. (Coverage is an important concern. Be thoughtful and communicate with others to make sure that your pedagogical choices support student mastery of the concepts that they are ultimately responsible for learning in the course!)
- When polling for responses, ask students for their ideas in plain English. Asking for “the answer” often results in a confident student spelling out their code to you, which is not only hard for students to decipher but often just as difficult for you to understand. Encouraging students to respond in plain English helps make sure ideas are clearly communicated and outlines the more general strategy behind a problem. In this way, we also encourage students who don’t necessarily have the complete answer to share their ideas.
- Deflect unproductive questions. While it might be said that “there are no bad questions”, there most certainly exist unproductive questions. A good rule of thumb is that you should strive to say only things that benefit most students in section. Usually, focusing on the ideas will help shift the concern and focus from the minutiae of the code to the larger ideas at work. “That’s a great question; talk to me about it after class,” is a way to table discussions, though you might want to briefly justify your thought process to acknowledge the value of the question.
- Encourage incremental progress. Encourage students who push the discussion one step forward. It’s often more useful to explore the solution process step-by-step instead of focusing on the solution so that everyone can learn the general process for solving problems. Everyone can look up the solutions, but our job is to leave students in a place where they builds a problem solving strategy for coming up with new solutions.
- Be careful with slides. Ideas are often diluted or split piecemeal. With environment diagram presentations, for example, details are often split across several slides, making it difficult to see the full picture. In addition, slides tend to be like kryptonite to teachers: it makes them move slowly and removes interaction from the lesson. If you like using slides, make sure that you have a plan for engaging students throughout the presentation and that the information is all sufficiently laid out on any one slide. Think of it as a digital whiteboard, rather than a presentation.
Communicate intentions clearly
- Make your expectations and classroom decisions explicit, but also explain why. “In this discussion section, we will rarely ever cover all the problems. I think it’s important that we learn the process of solving problems, so depth is more important than breadth. There will be plenty of opportunities to practice and review before the exam, but the time we spend here is short, so it’s important that we learn in class prepares you to keep on learning and solving problems more efficiently outside of class too.”
- Give clear and precise instructions. Don’t half-heartedly say, “Work with your neighbor if you want to,” but instead say, “Turn to the person next to you and share what you have so far.” Use physical cues, gestures, and act out what you’d like students to do. Enact your decisions with energy and make it clear what will happen next. What you say is important; otherwise, you wouldn’t be saying it! Build a rapport with students so that you don’t need to shout at them to get their attention.
- Understand your unconscious biases and choose your words wisely. We might not necessarily realize it, but we often have unconscious biases, or implicit prejudices, toward others that manifest in unusual ways while teaching. For example, we might unconsciously pick on certain students (often, those who look like us) over other students which could make other students feel excluded. Be consistent in how you address students and their questions, in particular. Students notice.
- Develop a personal self-presentation. Some teachers have a style that is more calm and focused. Others prefer high-energy and flow. You’ll find your most natural voice come out when you take-on a comfortable self-presenation style. Together with ample practice and an experienced eye for students, you’ll always know what to do next because you’ll know what the teacher you’re imagining would do.
- Modulate your voice, body language, and behavior for good effect. Use your voice and body to highlight the important details. If you normally move quickly, slow down for dramatic effect and you will get students’ attention. If you normally move at a measured pace, consider modulating your voice to demand attention. Control the physical space of the room. You are the section leader; do not hide.
Prepare lessons with students in mind
Before the first session, reach out with emails and check-in with them so they’re more comfortable with talking to you. It’s hard to break the ice after two or three sessions. Getting students to buy-in to what you do in class is important. If you want them to talk with each other, expectations should be setup early. Make it both your goal and a goal for the students to get to know students in section. Even if you run into difficulty remembering students’ names, demonstrating consistent effort to get names right is appreciated.
Experiment with having students work independently at various points and also working together on paper or at the board. Think, pair, share is a great learning technique, with the caveat that students might need some help getting started with a problem for the “thinking” portion to be effective. It can be hard to know where to start without explicit guidance. Simply showing examples is not enough; we need to talk about how those examples represent an application of a more general problem solving process. Include things to look for in a problem and guiding questions that you ask to yourself when working on a problem. These metacognitive questions can help students construct their understanding of how to solve problems and for coming up with their own sets of questions for evaluating their progress on a problem.
Studies have shown that students ask better, directed questions and monitor their own progress through a problem better by having a concrete framework and set of steps to follow. Our job as instructors is to provide a more detailed application of some of the trickier concepts in the course in the framework of a generalizable problem-solving strategy. With recursion, for example, we might want to:
- Ask questions that pertain to the idea of functional abstraction, for example, when reinterpreting the problem prompt. What are the inputs and outputs to this function?
- After having first identified that the problem is solved recursively from reinterpreting the problem prompt, search for analogous problems by recalling the fibonacci sequence or recursive factorial examples from lecture, or other examples from lab.
- Take the analogous problem and adapt the solution by identifying its constituent parts, the role of those parts, and the kind of adjustments that will be necessary. The oft-repeated three parts of recursion might fit in here.
- Then evaluate the solution by thinking like Python and asking increasingly specific questions that expose problems with the current implementation. Step through and verify the solution by first executing the base case, verifying correctness; then executing the next larger case, verifying correctness; and so forth.