Ruby > Ruby mentoring >

This is a bunch of rough-ish thoughts on the mistakes I’ve either avoided or have made and learned from. These ideas may or may not apply to you, so use your judgement.

---

Allow interruption ∞

Make it clear that interruptions by the mentee, especially for questions, is acceptable and even encouraged. I have issues keeping my train of thought so I usually need to take notes when we have a break so I can remember to bring up important topics later. But I won’t let my train of thought issues stop the wild topic changes.

Maybe we’d be working on some piece of code and something else comes up. I’d note what we were working on and then we’re free to explore something else for a while. You both may have one goal in mind when you begin, and you’ve followed a completely different path through all sorts of unexpected topics.

Don’t be discouraged by the notion of not following a lesson plan. Students are far too used to thinking of learning as a path that they take one step at a time. They take a few steps and they can look back and see their accomplishments easily.

However, an environment that encourages wild topic changes can tend to feel scattered and without accomplishment. It’s very important to take notes while you’re talking. I find that one long text file with the various programming snippets you’ve been working on will be a great help in avoiding this issues of a lack of accomplishment. At the end of the session, skim through those notes together and mention each of the things that was talked about.

A free-form learning environment will cover a lot of stuff – and more importantly – a lot of interesting stuff. It becomes obvious when you read through those notes!

Multiple ways to do something ∞

Always present one solution to every problem. Presenting multiple ways makes it more difficult to remember any of them.

Explaining why there are multiple ways, or even worse trying to explain which one is better, is a serious drain. Avoid.

When the time comes, and the familiar solution doesn’t feel right any more, then present the alternate. That’s the moment that explains why there are multiple ways and which one is best.

A perfect example is if-then-else versus case

This sort of structure will be taught early on:

if a == 1 then
  puts "one"
elsif a == 2 then
  puts "two"
else
  puts "neither one nor two"
end

This is also perfectly valid:

case a
when 1
  puts "one"
when 2
  puts "two"
else
  puts "neither one nor two"
end

Revealing the second method while the first is fresh in their mind is a bad idea. Avoid it! Try to avoid it until the last possible moment.

Explanations and Theory ∞

Never explain anything that isn’t directly related to what you’re working on. It’s distracting. Take notes and bring it up at some more appropriate time, like the beginning of a session.

Maybe you’ll have all sorts of theory or ideas that you want to talk about and you may want to open a session with that stuff. It’s tempting to balance programming time with theory time. It’s an excellent notion. I think of this as spending as much quality time learning to be a programmer (“the artist”) as learning to program (“the mechanic”).

However, any sort of explanation is unnecessary and confusing. Work on the code together, and when something directly related to that code comes up then explain just enough and no more.

Research ahead of time ∞

We went through quite a lot of hell dealing with multimedia libraries. It was vastly more challenging that could be imagined. If there’s a topic which is probably going to come up, be sure to have a rough idea of what’s in store.

When something is legitimately unknown to you both, just touch on it. If you get the feeling that it’ll take some time then make a conscious choice to set it aside and work on something else. That complex task should be the job of the mentor to figure out (or ask for help).

Solid time ∞

It’s important to have a sense of immersion. Even if the schedule varies wildly, being able to commit to a decent length of time is pretty important.

Also, ending on a high note is a very good idea. Even if you spent a half an hour together and did something awesome, that may be a good place to stop. This sort of thing is very helpful early on.

Later on it may be a good idea to stop in the middle of things. Try hard to not end it when things are unsolved or when something is half-finished. Instead, whenever all the various immediate issues have been hammered out, and you can commit your thoughts/to do list into various comments, then there is a moment when you can choose to stop.

Stopping on a high note or when a project is complete is good for morale, but stopping “in the middle” of something gives some material to think about until next session. It also helps pull people back to the project for the next session.

• Stopping when everything is done makes the downtime feel like a vacation. It can be a restful break, but very bad since “getting back into programming” will be more difficult.
• Stopping when a bug isn’t fixed creates this sort of looming worry and makes returning to the project intimidating.

• Stopping between features when things are not buggy but not done gives just the right kind of balance.

The proper environment ∞

Breaks should be infrequent. Background noise should be minimal.

However, if there is some specific environment that works for either (or hopefully both) of you, then pursue that instead. For example, some people work well with background noise (e.g. a TV is on but not watched).

If either person’s environment is distracting to one or both people, it’s better to pause or even stop for the day rather than fight through those distractions.

Tutorials are inappropriate for mentoring ∞

My initial introduction to Ruby was with Chris Pine’s Learn to Program and _why’s various works. I did things the traditional way, I read and I experimented and I asked questions when I couldn’t find an answer. I figured I’d start the two of us down this path together.

Tutorials force the student down a specific path. Its author makes all sorts of guesses at how to arrange their work. In traditional learning, a set curriculum is an excellent way to imprint a student.

It turns out that a student freed from such traditional constraints thinks so completely differently from a tutorial author as to render tutorials largely worthless.

There were a number of things which were surprisingly urgent concerns for my mentee. They were revealed because I allowed and encouraged questions. I followed him down any rabbithole that he ran at. So while we read a little bit of Learn to Program, we ended up skimming through huge sections because we covered so much just by conversation and experimentation.

At one point we completely abandoned the notion of using tutorials. Perhaps we’ll return to tutorials later when we have specific issues we need help to figure out.