# Teaching Tips ## Veer Dedhia - Ask questions in the negative, because people default to not answering at all. - Don't let the class control the lecture too much; if the questions start getting off topic, ask them to put it in a help ticket and you can get to it later. - When one person asks a question, but they don't seem to be in sync with their partner, ask a question to bring them together. Something like "what did your partner say when you asked them?" Don't be afraid to pull them away from the keyboard if you need to work on their concept map! ## David Yang - During live coding having a strong student control the keyboard, lets you think and gives students a chance to see that it’s possible - Asking the audience to see if they have an answer to the question if you don’t have it - Show how you would solve something you don’t understand ## Sarah Zhao - A little vulnerable but, when there’s a bug in my live code and I don’t know where it’s coming from, I may panic internally, but externally it’s a really great chance for the students to understand how I debug something to understand some more logic flow. So… live debugging with the class participating so we can learn as a group. ## Eric Katz - I hand out paper and pencil the moment class is scheduled to begin and have them hand write a solution to a coding challenge. This gets the students engaged early and since I use that paper to document attendance becomes a strong motivation for students to arrive on time. More importantly it gives me a quick way to see if they understand key concepts. ## Ben Rodriguez - Depending upon what part of the lesson I am on, I make the live code into a “class code” by having students help fill in some things. “Okay, we have coded these functions out, can someone help me with this function?” This can be done as a class wide lesson or someone can volunteer to navigate me. - Showing my process in how to search for things and how to read error messages and documentation. - +1 to Sarah on live debugging - working through data flow/function flow - +1 to Noelle on constant student engagement ## Travis Stratton - When a student has a question and you don’t have time to sit with them, do not outright dismiss them but try to quickly give them a place to start looking themselves, and also offer an alternative time to meet with them - takes a few seconds but it helps them not feel ignored - Never say, “It’s simple” or “It’s easy” when discussing a problem no matter how trivial it may seem. Some students won’t be at that level yet and it can be frustrating. - When possible during live coding, have the students navigate a bit and let them give their own answers. You can transition this to peer-to-peer discussions on if it is a correct solution or not and it gives them confidence that they can do it or at the very least identifies misconceptions about how to code that problem ## Noelle Laureano - Empathizing with the students. I’ve been in their seat so this is only natural. - Live debugging and stepping through code on a whiteboard (including drawing the call stack). - Constantly engaging the students to participate. ## Dan Sohval - Using multi-modal engagement. As an instructor I included few act-out theater moments demonstrating processes like HTTP, Redux state management, and counting in different numerical bases ## Frank Rose - When I live code, I use the debugger to troubleshoot issues. Many students don’t know about it, and a live demo of its usefulness encourages students to use it more. ## Scott D’Alessandro - When a student is having difficulty forming a question, I have them Rubber Duck Debug to me so I have a better understanding of how they are internalizing concepts and how they go to where they are stuck. - For beginners, have them fill in the blanks when learning to read documentation. I generally have them start with functions/methods they are familiar with, but afterwards I have them fill out a sheet while reading documentation and I have them fill in the blanks. It’s common that students lose scope of what the input and output is of a function, especially when they are learning a lot of new methods/functions for the first time. I feel this exercise makes the review their own code in more depth and they review variable assignments, method calls, etc. and they don’t just copy patterns, but they ask they “why am I using map instead of filter?” - At the end of these exercises, students have their own mini documentation set of their own explanations of methods and their own code snippets that they can relate to. I find this also helps students improve their ability to read documentation ## Finn Terdal - When doing a live demo, make intentional mistakes from time to time. Wait for someone to point out the error and respond with a “Thanks for pointing that out!”. If no one points it out, walk through the error message and your debugging strategy. Students need to see that mistakes are normal and appropriate. They also need to see an example of how to respond to corrections respectfully. - When a lecture begins, the first thing on the projector is the cohort's Google Calendar. This way, they immediately see what's in store for them in the short-term, as well as how it connects to content later / earlier in the week. Additionally, since it's the first thing in the lecture recording, it's a lot easier for students to connect the lecture recording to their notes for that day (it's immediately obvious when the lecture began). It also helps other instructors to place the lecture recording in the curriculum (e.g. which week was this recording, and what workshops are associated with it). - Emojis are great! On a Mac, you can open up an emoji keyboard anywhere with the shortcut Ctrl+Cmd+Spacebar. I insert emojis all over my code demos. It adds a bit of humour, and helps to create a visual language for the cohort (e.g. 😈 for a tricky bug, 🙀 for a surprising effect, 😎 for a neat trick, etc). ## David Patlut - Whenever doing a formative assessment (or some kind of code snippet I am showing) first I give the students about 30 seconds to really think/understand the code/question before asking them to answer your question about it. - Using exit tickets as a way to do the peer challenge. Some of the questions have multiple answers they can choose and it is a good opportunity for them to discuss with each other why they chose their answer. - If I do not know the answer to a question, I feel comfortable to admit that and do research with the students to show how I would go about researching the question. This will help them learn the “what” in their search. I also ask students “What should I be putting into my google search here for this problem?” ## Dakota Blair - This is kind of specific, but I like using algorithms and math facts for surprising effect in counterintuitive situations. For example, using the birthday problem to find students with matching birthdays when talking about hash collisions. Another example is using binary search to guess a number from 1-1000 in 10 or less guesses. ## Collin Miller - You’ve gotta say everything like… at least three times.