While in London I've been lucky enough to attend 20 or so codebar events - over two summer internships. codebar is a weekly mentoring initiative with the goal of improving diversity in technology - for those who didn't know. They've got a website that you can check out here.
Last year I tutored for HTML, CSS and Ruby - this year I've been tutoring with students working on their own Rails projects. During my time as a coach I've learned a lot about what I don't know, ways to phrase some common sticking points, and more - here are some suggestions for getting the most out of being a codebar coach.
###Getting In The first step to being a coach is to qualify as an attendee - host offices have limited space and there's only so much pizza to go round! Sign up to receive invitation emails for the meet up nearest you. Invitations are normally sent out mid-afternoon on a Friday and it's a first come first served process.
Normally the event is full in a few hours for coaches - I've heard it can be an even shorter period for students. There is a waiting list but the only time I moved up the list enough to attend on a tube strike day!
###What to Coach Students attending say what they're working on when signing up for the event, some work on codebar tutorials but more and more people are working on their own projects. When all the pizza's gone students names and topics are called out and coaches volunteer to be paired up.
I'd recommend trying out tutoring on both the tutorials and projects.
Tutorials are good if you want to review the content beforehand or want to hone your explanations of a certain set of concepts. However, I found doing the same set of tutorials each week to be somewhat repetitive.
I think tutoring projects is much tougher, coming up against a wider range of concepts and problems further from the core issues is the best lesson around in what you don't know. We've all read that working outside your comfort zone is the only way to learn. If this aligns with your thinking then give tutoring projects a go. It's pretty tiring work but you're set to learn about as much as your two students!
###Tips
-
Bring your laptop to type out syntax examples for one student to review while you talk to the other. It's also easier much to write code than explain it verbally. That said, exercise restraint and be deliberately vague where it feels appropriate to make sure you're not just spoon feeding solutions.
-
Encourage students to listen in if the work on the other student's project is relevant - you might be able to save an explanation or two this way.
-
Don't be a afraid to do things the "bad way" but always comment and give a suggestion as to how you might improve the structure given more time. Good students will always at least take notes on this - the best ones will complete the refactor task alone during the week.
-
Using Google is ok, as is making the suggestion that students read a blog post for an explanation instead of listening to you. Give them a pointer as to where to look, it's good practice for them apart from anything else but it also gives you a change to switch over to the other student. Teach 'Googling skills' where appropriate.
-
Start with a clean git diff. Don't change anything before finding out what half implemented features are all in progress.
-
Similarly, only work on one feature at a time. Often students dig really deep before getting the first step even half done. For example, they know that their users need to upload files and start there without implementing users or any of the related tasks. Another common one is creating all the models for the system at once, all with scaffolding (ofc), horrible mess. Know your database reset rake tasks and
rails destroy scaffold .... -
Only fuss over the most basic syntax style. so often, given a syntax error, getting the student to correct their indentation (which can be all over the shop) enables them to spot that missing
endthemselves. Correcting much more only wastes time - sessions really don't last long. -
Pronounce route as rowte, it just makes 'root route' (a particularly common phrase) more easily understood.
-
We're not meant to suggest editors to students. But GitGutter is a plugin I always suggest if the student is working in Sublime (it's in Atom by default but I've never had a student using that). This along with teaching weariness of
git commit -am "All the things"(git add -pto the rescue) goes a long way to making sure the project is in a better state when you come up against it the following week.
###Summing Up
I also tutored Rails for a year at university, I'd say this mind dump is based on around 80-90 hours of tutoring Rails to absolute beginners. I can't recommend it enough - you'll get just as much out of it as your students - just don't forget to bring a loud voice and as much energy as you can find! And, leave some room for pizza!