For someone who wasn’t overly active on social media at the time, I am still amazed by how I stumbled across this tweet, which is how it all started:
Fast forward to the time of writing, it has already been over two years since I’ve become a Code First: Girls (CF:G) instructor for their Python course in Sheffield!
A quick intro for those who haven’t heard of CF:G before: they are a not-for-profit social enterprise (in the UK and Ireland) which aims to encourage more women to pursue a career in tech and aiming to narrow the gender gap in the field overall. Currently, they have an ongoing goal of educating 20,000 women to code by 2020, and have just surpassed half of their goal at the time of writing!
For those who know me well in person, they know how much I love talking about my involvement with CF:G, and so this is really an overdue piece that I needed to write! As we approach the halfway point of 2019, it feels like a good time for me to reflect and share five things I learnt since becoming an instructor.
1. Instant feedback is important
Have you ever attended any courses where they ask for constructive feedback once you have completed it? Whilst end of course feedback is still extremely valuable for improving the course the next time it is being run, those improvements won’t be beneficial for those taking the course!
To ensure the students on the course can get the best experience out of the course, our instructor team took a more proactive approach to get feedback. At the start of each session, we hand out red and green post-it notes to everyone. Throughout the session, the students can then stick a red post-it at the back of their laptop to indicate they need help with the content just covered, or a green post-it to say that they are happy with everything so far.
This worked really well as it gave us clear, visual feedback on exactly who needs help, as well as a general indication as to whether we are going through things at the right pace.
At the end of the session, we then asked the students to leave one thing they enjoyed and/or thought we did well during the session on the green post-it, and one thing we could have done better on the red post-it. By doing this, we were essentially getting a mini end of course feedback, and so could promptly improve on things we did not do well in the next session. This meant both the current students and future cohorts get to benefit from the improvements, so it was a double-win!
2. Teach with a beginner’s mindset
As a developer myself, I have to admit that often we tend to talk about things in some language bubble that we automatically assume everyone else will understand.
Breaking down an explanation of technical concepts full of jargons to something lower level is an essential skill to ensure the course content is accessible to everyone. For me, it has certainly not been an easy process, but by doing so, it has helped consolidate my own understanding of coding fundamentals that I thought I knew well at first. After all, if I could not explain them in layman’s terms, I probably did not understand the concept well enough.
Let me give you an example. Suppose that a student had the following piece of (highly contrived) Python code, and asked: “why is it not printing anything in the command line?”
def print_message(message):
print(message)
print_message
One potential explanation we could give would be: “Oh, that’s because you aren’t invoking the function. You’ll have to do that with a string argument before you can see anything!”
Beginner me:
Although that makes enough sense to me, having been a developer for a while, I can guarantee that to some beginners, that sounded like a lot of gibberish.
A good way I found to break down an explanation is to take a step back and look at how many technical words I’d be using in my first explanation attempt. Then, go through each of these words, and think about the following:
- Are there simpler alternatives that roughly means the same thing? Replace it with that and repeat the process two to three times.
- Is the explanation full of acronyms? Spell them out in full, and explain what they are!
- Is this word really needed for the explanation in the first place? Remove it if not.
For the last point above - in written explanations, words like “obvious”, “simple” and “trivial” are rarely needed and should be removed. I find them patronising and off-putting for beginners. It achieves nothing apart from making some students feel stupid for not getting it the first time around, which is not the atmosphere we want to promote.
P.S. If you are interested in my beginner-friendly explanation for the given example, let me know in the comments!
3. Talk with the students in class
In sessions where I was not delivering content at the front, I found it helpful going around and talking with the students to gauge how well everyone is understanding the content.
Talking with the students also ensures those who are shy to speak up gets help too! You may be surprised to hear that, almost every time, when I asked the students if they need help, they will have a question about what we are doing. It was particularly effective in sessions when we were covering trickier topics, since some students were so far behind that they were too focused on fixing their current problem and forgot we were around to help. Talking with them in this case really helped them catch up with the class.
In cases where they really don’t have any questions, it’s a good opportunity to connect with them and strike up a conversation anyway, which can be a nice ice-breaker away from the strict instructor-student relationship. I think this is important so they feel comfortable talking with us as a mentor or a friend, rather than the thought of talking to another awkward and scary lecturer they most likely had experienced with at university.
4. Start with the why’s before the how’s
To help the students build a deep understanding on how things work, from experience and past feedback, I found that it is much more intuitive to start with why we do certain things before jumping straight in on how to do something.
Since we only had realistically six weeks in the Python course, for beginners, at times it can feel like a big mishmash of topics being taught! In particular, since the course is aimed at those from non-technical backgrounds, the topics taught will take time for them to sink in. During that sinking in process, it is easy for them to forget things taught in previous sessions.
By starting with the why’s when introducing a new concept, and using the explanation to link back to concepts taught in previous sessions, it will help the students see the bigger picture and build a better mental model on how everything taught so far work together. This will then help them retain the concepts and apply them more effectively to their course project.
5. Follow up after the session
No matter how good our delivery was in class, from experience, not everyone would have understood everything at the time, especially when the topics covered start to move away from the basics. Sometimes, perhaps the explanations I gave could have been better, and that’s where following up after a session can help to clarify.
At other times, the topics covered were just too much for some to click straight away in the session, since we all learn at a different pace. The students hit the they-don’t-know-what-they-don’t-know phase to ask you any questions in the session. In those cases, based on past feedback, the students have found that following up with a mini, brain-teaser exercise halfway between two sessions have helped them understand what was taught better.
Personally, due to the limited time we have in class, I also like to slip in small things they may not have seen in class before in these brain-teasers, so they get to learn new ways of doing things too.
Do you have any other tips on teaching others how to code? If becoming a CF:G instructor sounds interesting to you after reading this post, and/or if there is anything else that I’ve learnt after being an instructor you’d like to know, let me know in the comments!
Top comments (0)