Helping your fellow students learn is absolutely worth your time. It will help you gain a deeper understanding of the topic, build a strong relationship with other learners and gain the vital "peer pairing" skills that will help you excel as an engineer. So, when one of our subscribers asked for some techniques for helping other students learn, we asked Antoin Campbell, a bootcamp grad, former teacher, and current engineer at Street Easy, to share his ideas.
Karyme Virginia is a studious web developer living in the San Francisco Bay Area with her fiancé and their cat. When she's not coding, she loves to read and write, create music, and think about coding some more. Learn more about her and what she's working on here.
How can we, as students of programming, help teach others also learning to program (who are often just right behind us)? I'm a student at Flatiron School and while I want to bond with and support my peers, I want to work with them in a way that is helpful for both of us, and I don't just want to give away the answer when I know it! What are some techniques to helping each other learn? –– Karyme Grumbine, programming student
Antoin is a boot camp grad, former teacher and current engineer at Street East. In his free time he likes to learn more about design patterns, attend concerts and beat Sophie at Mario party.*
* editors note: this never happened.
First of all, let me just say––what a fabulous question! Not only does helping your classmates help you learn and make learning more fun, but it helps you develop real communication skills that you'll need as a professional developer.
I think there are four techniques that will help you help your classmates:
- Be honest about what you don't know. It's okay not to know the exact answer for your classmate's question. In fact, it might even be more helpful if you don't! Being honest about what you don't know helps build the confidence of the person asking the question. On top of that, it allows you and your classmate to solve the problem together. This strengthens your problem-solving skills and helps you both develop the "pair programming" skills you'll need on the job.
- Walk through the problem and ask your fellow student to articulate what it is they are struggling with. Try drilling down and formulating one specific question together. This will allow you to spot where they might be struggling, and decrease the amount of topics or paths to solving the problem. It can be hard to figure out where to begin when solving a general problem. Narrowing your focus to one specific question helps you and your classmate pick a place to start.
- Ask questions. It might seems counter-intuitive. Why should you ask questions to the person who came to you with a question in the first place? Well, your goal isn't to just hand someone the answer. It's to help them develop the tools to solve the problem. Instead of telling them exactly what to do, try providing a hint, idea or specific starting place and then asking them what they think will happen next, or how they expect the code you have so far to work. This helps your classmate think through the problem themselves and helps them to break down the issue into smaller, solvable parts.
- Be excited about solving problems! In my experience as both a bootcamp student and teacher at the Flatiron School, the students that receive the most questions are the ones who welcome a challenge with positivity. Solving problems is a programmer's job, so get used to embracing exactly these kinds of challenges.
Real-Life Example: Questioning the Questioner
Hi, it's Sophie again :)
Karyme, The same subscriber that asked this question shared the following experience of trying to help a fellow-learner:
My fiancé and I were attempting Harvard’s CS50x on edX. I had done the first couple weeks of assignments before, but he was coming in as a new student. CS50x assignments are big on problem solving, and he was struggling with an assignment. I tried to help him, and the experience was frustrating for both of us — I could see the solution but I didn’t just want to tell him what to do, and so I would hesitate over my words and how to guide him. He could tell that I knew what needed to happen next, and he was irritated with me for withholding the answers.
You don't want someone to be irritated with you for "withholding answers"! So, what happens when you give them the answers they're looking for? Karyme shared another anecdote describing what happened when students helped a classmate by providing her with the "right" code to finish the given assignment:
There is one student in the cohort who was especially struggling with her first project. Another student was hosting informal study groups...and she was getting suggestions from all sides, perhaps even from students who didn’t really understand the trouble she was having. I think my heart broke when I heard her say (paraphrased): “I’ve patched in so many suggestions from so many people that I no longer know what my code is doing.” I can imagine how frustrated and incompetent she must have felt at that moment.
Karyme's first instinct to "withhold" the right answers was correct. And this story really highlights what happens when we "help" our classmates by providing them with the "right" answers, right off the bat. It's not super helpful to tell someone exactly what to do to solve a problem. Instead, we want to help them figure it out on their own. This empowers them to tackle the next challenge, and the one after that.
So, how can you solve problems together, instead of just handing out "the right answer"?
Antoin's third point, "ask questions", is the technique to use here, and his advice reminded me of something I saw occur between two of my students a few weeks ago.
It was a big project, and one of the first times my students built an app from scratch--no starter code included. Understandably, many students weren't really sure where to start. One student, George (not his real name), expressed his frustration to another, Janelle (not her real name). George didn't know where to start, or what part of the app to tackle first. Janelle works as a product manager and has a serious knack for asking good questions and breaking down big problems into smaller ones.
She didn't tell George what to do. Instead, she asked him a question.
What do our users need to have in order to play this game?
Well, they need an area on the page to input their guess and they need a button to press to submit their guess
If a user clicks the "submit guess" button, what do we expect to happen?
The game should play--they should see if their guess matches the number our game generates, and they should see if they won or lost.
This still leaves a lot of starting points! Should they start by writing some code to generate a random number between 1 and 10, by writing some code to check the users guess, or by writing the code to display whether or not someone won or lost? So, Janelle picked this moment to make a suggestion:
All of these suggestions are things that happen when the user clicks the "submit guess" button. So, before we write any specific code for the game logic, let's write some code that will "do something simple", like raise an alert, when the user submits their guess. Let's add an event listener to that submit button!
Then, instead of writing that event listener code herself, Janelle asked another question of George:
How can we add an event listener to the "submit guess" button?
This specific question allowed George to jump right in and do something that he knew how to do: write the event listener code. George went from feeling confused and a little frustrated with the task at hand, to exercising the skills he's learned so far. And Janelle's questions for George helped them to work together to build a roadmap for their project. Her questions gave them a clear plan and a concrete starting point.