Goal 1: Make 'em smile!

• Current state: frustration
• Desired state: 

Convey this is solvable

• Seriously, half of the job is just
  • 1. Believing in them
  • 2. Conveying an unstoppable confidence that this problem is solvable
  • 3. A belief that there is a path forwards from here

Tactics:

• Always show up with a smile and a positive greeting:
  • ​"Hey team! What do we get to work on today?"
  • "Hey guys! What are we figuring out right now?"
• Empathy: 
  • "Yeah, I remember this was a confusing one for us when I went through it."
  • "Yeah, we've gotten several questions about this part."
• Leave with cheer and belief:
  • "Have fun working on that!"
  • "That'll be a cool one to puzzle through."
  • "This has been fun, thanks for sharing this puzzle with me!"

Tactics:

• Get excited when you get new error messages
  • This means that you're making progress- you probably just solved the problem you were originally stuck on
  • This also gives you new and valuable information to solve the problem
• Most students will claim to love solving problems and puzzles. That's all debugging is. Tell them so. 

Paul Graham on Debugging:

• "In hacking, this can literally mean saving up bugs. I like debugging: it's the one time that hacking is as straightforward as people think it is. You have a totally constrained problem, and all you have to do is solve it. Your program is supposed to do x. Instead it does y. Where does it go wrong? You know you're going to win in the end. It's as relaxing as painting a wall.
  "
  • http://www.paulgraham.com/hp.html
• "Few people know so early or so certainly what they want to work on. But talking to my father reminded me of a heuristic the rest of us can use. If something that seems like work to other people doesn't seem like work to you, that's something you're well suited for. For example, a lot of programmers I know, including me, actually like debugging. It's not something people tend to volunteer; one likes it the way one likes popping zits. But you may have to like debugging to like programming, considering the degree to which programming consists of it.
  "
  • http://www.paulgraham.com/work.html

Goal 2: Something to Work on

• Your threshold for when to move onto the next group:
  • ​"I know you don't have a solution yet, but do you feel like you have something you can work on?"
• We give you full permission to leave students when they're still in that state of slight frustration because they don't have an answer, but do have a path forwards they can work on.

Do not give students the answers

• You'd be robbing them of valuable learning opportunities. 
• They paid to come here to learn, and to be fantastic engineers, not to get spoonfed the answers easily. 

Tactics:

• "And that seems like a solvable problem to work on."
• "And that seems like a thing you two can investigate on your own."
• "And that seems like the type of thing you can pick up from the docs."
• "Do you think that you can figure that out from here?"
• ​"If that doesn't prove fruitful in 5 minutes, submit another help request and we'll be back over!"
• "That'll be a cool thing to work on."
• "Have fun figuring that out!"

Debugging Process

• You don't need to know Angular to debug Angular code!
• Debugging is a super valuable skill that is distinct from the ability to write code in that framework/language.
• Don't worry about not knowing the answer- you don't have to. You just need to know how to debug. 

Debugging Process

• Look at the exact error message. Oftentimes there's a ton of information in here the students are ignoring.
  • Don't forget the Network tab in the console has useful error messages too!
• Investigate each line of code
• Find the last point where it is behaving as we expect/ the first place it isn't behaving as we expect
• Investigate each portion of the line that's not behaving as expected, further narrowing down the scope of the problem
• Awesome, now you've just identified the specific thing the student can go off to work on!

Debugging Process

• You don't need to know what each line of code is doing- keep asking the student "Is that what we expected to see?"
• Use the debugger where possible- teaching students the debugger interface is a worthy diversion
• If console logging, make sure students label what each console log is.
  • Good: console.log('x inside transformerFunc', x);
  • Bad: console.log(x);

Debugging Emotions

• Students will oftentimes be defensive about their code, even while being frustrated that it's broken. 
• Break this down really obviously. 
  • "Clearly, since this isn't working, there's something in this code that isn't doing what we expect it to. So let's go through and verify all of our assumptions, because obviously one of them is wrong and we're not sure which one yet."
• This removes quite a bit of the defensiveness. 

Socratic/HR Method

• Ask questions
• Guide the students to their own realizations
• Rephrase the current state of their code in a more obvious way that will guide them back to something they know. 
• Reduce the scope of the problem down to a single solvable thing

Single Solvable Thing

• Students normally say something like "our code's broken!", or "we just can't get this to work". 
• Get them to the point where they have a clear and specific puzzle to solve, rather than a vague and poorly understood "code's broken!"

Bumpy Road: Curriculum

• The curriculum is intentionally challenging and bumpy.
• Phillip said that at one point he went through and cleaned up a bunch of the sprints so they were more clear and had fewer bumps. 
• Turns out, that was counterproductive and so it got changed back to it's intentionally bumpy state. 
• Feel free to communicate this to the students if they start complaining about the curriculum, or something in the repo that's not ideal or obvious. 

Bumpy Road

• As an engineer, you're never going to be in a codebase where everything is done perfectly. Things will always be hacky, and not the canonical way of doing that technology.
• It's an incredibly valuable part of our learning here to get used to that feeling, to learn to feel comfortable working with code that's unclear and imperfect. 
• Empathize, but stay firm that getting used to this pain is a very good thing for them as engineers. 

To The Docs!!

• Your first reaction to nearly anything should be "To the docs!"
  • Teaches them self-sufficiency and allows you to show them good patterns for how to peruse docs/search on google
• Students aren't nearly specific enough in their Google searches- change this.
  • This ties back into single solvable thing- if they have a single solvable thing to work on, they should be googling exactly what that thing is, and then getting more vague over time if they can't find a super precise answer first. 

Tactics

• This also prevents you from having to know all the answers
• "I could theorize about this, but the docs will have a more accurate explanation."
• "I could explain this, but it's really worthwhile to see an example in the docs."
• "I could tell you what I know, but the docs will be more thorough."

Logistics

• Read through the Sprint notes
• Read through your own sprint so you remember what you did and what you struggled with
• Give tech mentors feedback whenever possible
• Contribute to the wiki whenever possible
• Night shifts the first night of a sprint are generally busier/more desperate than morning shifts. Just be prepared for this. 

Logistics

• Bookstrap is finnicky. Come back and refresh the page somewhat frequently/make sure you're still signed into the correct floor. 
• If floating, let that be known on the IM channel.
• Always check in with tech mentor! 
• Don't be afraid to escalate to tech mentor.
• Always follow through on your promises. Always. 
  • If you say you'll be back with help, make sure to follow up, even if just to say that you haven't found help yet. 
• You're the front line of gauging students' understanding. Share that with tech mentors and shepherds. 

Imposter Syndrome

• You weren't chosen because you were the best technically.
• You were chosen because you are pretty darn great technically, and we thought you had something more valuable to give to the community here than just technical expertise.

Imposter Syndrome

• You were intentionally selected to be a student of this school (trust me, working in admissions, this is a MUCH higher bar than you understand).
• You were intentionally selected to be an HiR.
• You were intentionally selected to be a Help Desker, by people who know you well and have studied your performance in WAY more depth than you currently know about, for 3 months. 
• You are meant to be here.

Other Effective Patterns

• Relate back to the other goals of the sprint.
  • SQL and raw Node.js are intended in part to teach students that these things are painful and that the abstractions built on top of them (ORMs, Express) are really useful things. 
  • D3- drive home that each thing before a .funcInvocation() is it's own separate piece of that process, and that you can break out of or enter or store that process anywhere along the way. This is a really good way to learn debugging: understand that each step of the process is it's own modular thing that can be tested and investigated and understood, not just the entire chain itself. 

Other effective patterns

• Focus on the non-technicals
  • ​We want students to learn how to pair with each other, discuss complex ideas, develop opinions on different ways of structuring their apps, etc. 
  • Draw students out of the purely technical sometimes to explicitly focus on these non-technicals. 

Other effective patterns

• Teach debugging.
  • Teach them your process.
  • Teach them why you do the things you do.
  • Talk through what you're doing. 
• Teach Git.
  • Especially during the first few weeks, and during thesis project. 

Other effective patterns

• Join learnings back into the larger concepts. Relate things back to key concepts that we're learning with this sprint. Give the answers a context. 
• Relate learnings forwards in the curriculum. Give them a reason to remember something because it's something they'll use again in their thesis project. 

Other effective patterns

• Really hammer home the difference between state and view. This comes into play in D3 for the first time, and then continues throughout the rest of the course. You have your "JS logic", which does a bunch of things way down in the depths of your code. And then separately, you have rules to attach the rendering of that to the dom. 
• These are two separate steps, but oftentimes get confused for being the same thing. 

Other effective patterns

• Take advantage of teachable moments if you have time for "Extra Credit Help Desk".
  • This is a huge value add for both them and for you.
  • This helps build a much stronger connection between the students and you because they see you went out of your way to give them extra content/understanding.
• Call out your teachable moments explicitly. "This is great, you guys are starting to hit on something really important. Let's take a moment and talk about this. As you noticed..."
  

Other Effective Patterns

• Always use group pronouns. "Our code, our assumptions, we can go to the docs to figure this out".
• When the code is terrible, make that about the code not the people. "The way the code is written now..., The way the app is architected at the moment...", rather than "The way you've written it, the way you've architected it."

Other Effective Patterns

• Avoid taking sides. If a pair is having a discussion, acknowledge both thoughts and the validity contained in each.
• Make the discussion about code, not about people.
• If a pair reacts with "See, I knew I was right!", squash that quickly and gently with "Yeah, in this instance, but can you see how in other cases, XYZ could be a better way of doing it for these reasons..."
• You do not want to set a pair up against each other with you being the arbiter. 
  

Other Effective Patterns

• Tell the students why what they're doing is valuable. When the coffeescript compiler script broke, students were annoyed and frustrated. But this was a wonderful opportunity for them to transition their mental models! They could now learn that they could fix versioning, or go find the source code for something and patch it manually. Or do any number of other things they never would have expected to be capable of until we made them do it. Show excitement for what they get to learn, and relate it into larger goals. 
  

Other Effective Patterns

• Allow them to feel empathy for you and their cohortmates. "I know you guys don't have an answer, but do you feel unstuck enough that you have something to work on? Your cohort just opened up a bunch of help requests at the same time and if you have something you can explore, I'd love to go help another group get to the point they have something to work on too." 

Other Effective Patterns

• Put questions back on them. "Tell us the right way to structure our BackBone app." "Let me ask you, what do you think the best way would be? What are the pros and cons of each approach?" 
• Stand back and let them discuss whenever possible. If a student indicates they've had a thought with their body language, shut up nearly immediately and let them share it. "It looks like you thought of something, Erica!" is normally all it takes to get them to share their excitement at the new realization. 
  
  

Other Effective Patterns

• Intentionally leave them without a sense of black and white. Whenever possible, give them the possibility to have a discussion. Give them some pros and cons, or areas to weigh the decision on, and then say "but that's one of the decisions that you two get to make. This will be a worthwhile discussion to have because stuff like this happens all the time when you're working at a company as an engineer."

Other Effective Patterns

• Relate things back to what it's going to be like for them on the job. Don't make it about "We're making you do this thing", make it "Yeah, you'll encounter stuff like this all the time in an engineering position, so we wanted to prepare you for it now."
  

Other Effective Patterns

•  Transitioning Mental model- Don't just lead them to the answer. Give them knowledge. When they're touching on a subject, share things related to that subject. Example: a group was asking about grunt concat, and which file(s) to include in their html files. We used this as a discussion to talk about the different grunt tasks they'd encounter later on, the intention behind why we're doing concat in the first place, how they'll use these things in their thesis project, and a jumping off point for open-ended exploration of how to get packages onto a deployment machine. As I walked away, I heard one remark "That was a really good question to ask".