One-On-One Teaching Techniques
So you want to help someone learn to be a software developer. What exactly do you do to help them succeed? Many people have built great careers without formal study but even more have washed out. (Check out this talk from Jeff Cohen at RubyConf 2016 about it.) How can you focus your efforts to maximize your mentee’s chance for success?
A great way to teach is to help them incrementally improve their skills. You need to develop a system and schedule of action steps to help meet the challenge. Choose value deliberately, measure things you might consider a problem and address the areas, based on evidence, that need improvement first. Focus on bigger rewards first and fit in fundamentals they need to know as they need them (dessert first). Discuss both concepts (i.e. languages, frameworks, design patterns) and dimensions of skill (readability, functionality, efficiency).
Cognitive biases like imposter syndrome and the ambiguity effect may interfere. However, a great way to overcome them is to just try a little bit every day. Don’t worry if the list is huge. That’s actually a positive sign, indicating a bright and curious mind.
Now that we’ve got all that info, and it might be quite a lot, it’s time to get organized! First, group them topically and combine any duplicates. Next, sort them into three categories based on the amount of time required: most time, some time, and no time (which are often just distractions).
The mentee takes charge on when they can commit and how much. Once you start working together they will be able to see exactly how much progress they can make which often motivates them to devote additional time to learning. Their schedule might look like this: Saturday mornings watch class videos (if taking LC101, CS50x or something of that nature), large block of code practice Sunday, meet with other students Tuesday, meet with you Thursday after work. In addition to “fitting it in where you’re able,” make it a routine. Arrange your schedule so you can both really focus on teaching and learning and not be distracted.
Order any books you need; make sure your mentee has a working laptop, and order a subscription to any service they will need such as Code School, Team Treehouse, Pluralsight, etc.
Don’t be afraid to pull in additional help. Your mentee can learn about a topic from someone else and reinforce their learning, explaining it to you via rubber duck style. They get so excited and you find out what they have learned. Also, they will learn the material better if they hear it from multiple voices. Introducing them to the community at your local meet up is a great way to support this.
Meet regularly to assess progress, re-prioritize goals, energize and motivate. The goal is just to become slightly better, especially at the beginning. You can improve and optimize your learning speed as you go along. Your mentee will make intuitive leaps which are so exciting but you can’t plan those. They need to make the choices and feel personally responsible, challenged, and confident. “I need to do this — if I work hard I can meet the challenge.”
The mentee’s own learning techniques will work best for them. Make your system flexible enough to accommodate their techniques and help them find new techniques to overcome specific challenges they experience.
Serve as a guide
It’s the mentee’s journey. Guide them with context and framing they might not know about yet. Warn them of the worst pitfalls, and help them recover from their mistakes through stories of what has happened to you in the past. Don’t tell them what to think, don’t lecture, ask questions to prompt them making discoveries themselves.
Don’t wait for your mentee to have a question to ask you, use open-ended questions to prompt discussion and critical thinking.
Let’s imagine a scenario in which you aren’t sure how much they are understanding a concept in some code they are practicing. If you say nothing, time is wasted. You could ask them, “Do you know how that works?” but that could elicit a defensive reaction and embarrassment to respond if they do not know. If they do know, you still don’t know what they think you meant by asking. Instead, ask an open-ended question that cannot be answered with “Yes” or “No” alone. Start with a general topic and see what they talk about, i.e. “What have you learned about strong params so far?”.
You can guide the conversation with increasingly specific questions as you go on, “Will that return a symbol or a string? How could we find out? How is that difference significant? This will help you have a better idea of what they know so you can accurately plan their learning plan.
One great way to track your mentee’s work is to utilize a learning plan. It’s an easy to re-prioritize checklist of small items they work through in conjunction with weekly check-ins with you. I go into this in greater depth at my RubyConf talk along with many of these topics. The example learning plans are based my experiences as a mentee and mentor, including: creating traditional lesson plans, teaching music lessons, reading Mike’s study and participating in the LaunchCode Tech Team’s practice of agile principles.
When selecting materials to utilize, consider what your mentee should be able to do upon completion. What concepts should they understand? How will I assess whether I got value out of reading a blog or completing an online course?
Here are some things to think about when considering resources.
Topic: What topic does it cover? Is it accurate? Is it dated? Does it explain “why”? Is it thorough?
Author: Who is the author? Are they reputable? What was their motivation to create this resource?
Difficulty: What level of difficulty is the material? Compare to your mentee’s current output and understanding.
Reliability: Does it cite/link other resources? (Lead you on a journey? Oversell itself? Is it hand-wavey?)
Format: What formats are available? Capacity varies by method of transmission, after a 9 hour day on screen a paper book may be more successful for learning. How long will it take them to complete? Is it engaging?
“I have two kinds of problems: the urgent and the important. The urgent are not important, and the important are never urgent.”
— Dwight D. Eisenhower.
Feeling overwhelmed? You’re not alone. “I have two kinds of problems: the urgent and the important. The urgent are not important, and the important are never urgent.” — Dwight D. Eisenhower. This concept was popularized in Seven Habits book and is a prevalent idea in scrum. Focus resources and time on most important items, maximize the undone, as beautifully explained in this post on Agile Methodology. Split high learning cost & high importance subjects among multiple weeks.
Code & Learn
Topics for each week should include something from each of those “most time”, highest importance topics. Mix in some things you need most urgently, easy to grab one and “get it done” thing.
Have your mentee pair as much as possible, both with you and with other teammates. Take equal turns driving and try different styles of pairing. Trial by fire! Go for what matters. Build their feelings of responsibility for the codebase and products, try to get some code live very early. It doesn’t need to be “perfect” to have value.
This is a great feedback mechanism to measure how successful their learning is (no quizzes or tests required!). Make sure all criticism is actionable (useful, truthful, kind). Sandwich criticism between compliments. Provide context for code choices — show lots of examples and discuss why decisions may have been made and the subjectivity of “bad code”. Many resources online on how to improve code reviews — it’s a great topic to study.
While working toward big goals it can sometimes feel impossible! Put your nose to the grindstone and ignore that negative voice. Periodically check back for real evidence of change, i.e. look back at code from a month ago. Day to day change is difficult to see but you’ll definitely see your improvement from back then!
A technique sometimes called “successive approximation” that is used in many fields to adjust behavior. Just like writing software, it is breaking down behaviors into their smallest components, only it is human behaviors instead of machine behavior. Then recognize/acknowledge any movement in the correct direction with positive reinforcement. As a behavior is repeated, intermittently reduce the reward and reward newer behaviors more strongly. Dimensions of reward “strength” include frequency, duration, magnitude, and latency.
How can we apply this in software?
It can be as simple as complimenting in code review, don’t just point out flaws. Any behaviors or specializations they should focus on, recognize work in that direction. i.e. at morning stand up tell other developers how impressed you are that your mentee finished that book already while your mentee is present.
Directly tie a symbol of success to completion of large group of goals.
I have a few resources in my slide deck — seriously, I didn’t make this up — it’s based on my own experiences being both a mentee and mentor, as well as research. These resources can serve as a springboard to further learning and are not intended to be comprehensive. This link to the sample learning plan from my RubyConf talk may be helpful in creating your own learning plan.
If you’ve made it this far, congratulations (you deserve a treat)!
Experiment and keep trying. The most important thing is to not give up! What problems are you experiencing? What steps did you use? Leave your struggles and successes in the comments.
By Cheryl M. G. Schaefer
Cheryl is a software engineer at LaunchCode. With the support of Tech Director Mike Menne, she recently mentored her first apprentice only a year-and-a-half after completing her own apprenticeship. With just two formal computer science classes under her belt, she is otherwise self-taught in the field, including completing Harvard’s CS50 on edX. She works primarily in full stack Ruby on Rails, with significant components in Elasticsearch, SQL, Ember.js, AWS Cloudformation, and Node.js. LaunchCode is a fast-changing environment using Agile, TDD and frequent pair programming. Cheryl also serves as a volunteer mentor at CoderGirl, which she originally started attending as a learner during it’s first session in summer 2014. She recently gave a talk at RubyConf on helping you improve your mentorship and regularly speaks at St. Louis area meet ups including STL Ruby. She holds a B.M. and M.A. in Music Performance and has 15 years of experience teaching music. Although she is not currently active as a music teacher, she continues to perform solo and with session band Celtica, which recently released Christmas singles.