DABlog

For me, the most challenging thing about training is accomodating people who come to a class from different backgrounds and with different levels of experience and knowledge. So let’s dive right into that.

How different are different levels? At times, very.

I remember a Rails class whose members included a participant in that year’s “Rails Day” contest (i.e., a very experienced Rails developer), side-by-side with someone who had literally never written a computer program and never seen a command line. The latter person was a front-end designer, and I have every reason to think she was skilled and successful. But she did not belong in that class. (To be fair, the Rails Day guy probably didn’t either—except that he was actually there in part to help some of the other people in the class, who were his co-workers.)

Given a room with that diverse a population, what you can say? I mean that quite literally: what can you say? What sentence can come out of your mouth that’s going to make sense to everyone in the room and hold everyone’s attention? You don’t want to aim too high and confuse the less advanced people. But you don’t want to bore the more advanced students by aiming too low.

Managers sometimes err (quite understandably) on the side of sending more rather than fewer people to fixed-cost, on-site training courses; and even with public courses, self-selection based on advertised course requirements and content doesn’t necessarily serve to keep the group at one level. If you train, you’ll face this issue early and often.

Still, there’s a lot you can do to make the experience rewarding for everybody even in a very mixed-level group. Here are some suggestions—in no particular order except that the first one is the foundation on which all the rest, and indeed all of your training activities, must be built.

A. Deliver what you promised to deliver

This comes absolutely first and foremost. If the course was sold as a beginner’s course, then you have to provide a worthwhile course for beginners. If it’s an advanced course, you have to give the advanced students the best experience you can. Beyond this you can tweak and adjust; but delivering what you promised has to be the starting point.

Occasionally you’ll get a class where everyone is at the same level as each other and it’s not the level you advertised. That doesn’t happen often, but if it does, you can go ahead and recalibrate the whole curriculum. I did that once with a programming team who had much more experience than I’d been led to expect them to have. They were too polite to come out and say that they were too advanced for the curriculum, but it was pretty obvious. So we changed gears on day two and spent the remaining days on more advanced topics and code critique.

That’s a rarity, though. You’ll find the truly mixed-level class to be much more common, and whatever you do to optimize the experience for everyone, you must stay rooted in the curriculum you’ve promised to cover.

B. Make the prerequisites clear in advance

When you’re discussing the course skill-level with the client or prospective participants, show some tough love: be clear and firm about the prerequisites. It’s in everyone’s interest. Don’t try to be all things to all people. Use clear terms like “not suitable” or “too advanced” or “only right for beginners” if those terms apply.

Course prerequisites don’t have to be fine-grained, but they do have to be clear. “Everyone in the course should already be experienced with at least one object-oriented programming language” is an example of a reasonable prerequisite. So is “The participants need to be at least somewhat comfortable in a Unix-like environment.” You don’t need to know whether they know all the command-line options for grep. You just need to establish the basic requirements.

If you’re teaching a dependent technology—meaning, the way learning Rails depends on learning Ruby—address the role of the parent technology. You can teach Rails to people who know Ruby, or to people who don’t; but mixing Rubyists with non-Rubyists in a Rails class is problematic. Make sure you’re in accord with your clients about any assumed parent-technology baselines.

B. Try to control the teacher/student ratio

To the greatest extent that you can, keep the teacher/student ratio at 1/15 or better. Beyond about fifteen, in my experience, you hit critical mass: the amount of help needed by the students expands beyond the confines of the available time for one instructor, so you fall further and further behind.

This is ancient wisdom, of course. Universities like to brag about their tiny class sizes and all of that. And with training classes (as with universities, incidentally), you can’t always control it. But if you’re presented with, say, the prospect of providing hands-on, closely-coached technical training for twenty-five or thirty people, see if you can find another instructor—or at least a lab assistant who can troubleshoot software installation and other matters so that you’re not doing everything.

D. Have extra material in reserve

Try to have some ideas for extra projects up your sleeve, above and beyond any in your stated curriculum, particularly for students who are too advanced for the course. Bring a few books with you, and if someone isn’t feeling challenged enough, point them to a chapter that you think they can learn from. They won’t feel shunned; they’ll feel relieved. The whole problem is that the too-advanced person shouldn’t be there in the first place, so anything you do to help them not be bored is in their interest.

E. Enlist the help of the more advanced students

I’m thinking of situations where, say, one student is clearly over-qualified for the exercises in the workbook, and another student is struggling. It’s possible that the best course of action is for the over-qualified student to pair up with the struggling one and help them out.

This is a tricky strategy, though. It’s your job, not theirs, to do the teaching. The situation has to be really right before you ask students to teach each other.

But it often is really right. For one thing, teaching something helps you consolidate your own knowledge—so everybody wins, including the student-teacher. And some people would rather spend the time engaged in an activity with someone else than go off and work on an application or read a book.

As the teacher, though, you have to make sure that the result is at least as great as the sum of its parts: all parties involved have to understand and accept the plan. You don’t want it to backfire and have either student (or both) think you’re trying to brush them aside. Be circumspect about this option, but keep it in mind for the right situation.

F. Master the art of not answering questions

Don’t get me wrong: in general it’s good to answer questions. But when questions come from students who probably shouldn’t have taken the course in the first place, and are shifting the focus onto material that’s either too simple or too advanced, it’s your job to protect the class.

When I get a too-advanced question, I usually answer it quickly and, if need be, incompletely. I don’t want to digress too far from the curriculum—and above all I don’t want to make the less advanced students feel anxious because they can’t follow what I’m saying. You can always ask the advanced student to talk to you about their question later; but you only have one shot at making the dynamics of the classroom work for everyone. So answer the question quickly; offer to go into it privately later; don’t get into a lot of examples and demos based on the question (that can really make the other students feel abandoned); and move on.

Too-basic questions can be harder to deal with than too-advanced questions. In fact, it may be through such questions that you first discover that some of your students are under-prepared. This may be a good time to consider a temporary ad hoc student-teacher system (see E., above) where someone else in the class helps the person, assuming it’s something that can be communicated relatively quickly (like how to start Ruby from the commandline, creating a MySQL database from scratch, etc.).

G. Make it easy to move around the materials (e.g., staged code shapshots)

For the main do-as-you-go application in my Rails workbook, I’ve got twelve code snapshots. Each one represents the state of the application at a particular point in the book. If a student falls a bit behind, or wants to skip a section they already know about, they can move to a later chapter or section and “fast-forward” by swapping the appropriate code snapshot into their working code directory.

Furthermore, if I need to fast-forward through a topic, I can then pick up from a particular code snapshot and keep going. I might do this with a couple of topics if, say, a client has asked me to deliver a four-day course in three days—or if I’ve just fallen behind a bit and want to get the class back in sync with the courseware. (I don’t make a habit of falling behind but I do try to provide enough material that compressing one or two subtopics won’t be a tragedy.)

Staged code snapshots aren’t the easiest thing in the world to maintain, but they’re a good example of adding an element of independence to the classroom experience for students who want to adjust the pace.

H. Talk to the person in charge

I’m thinking here mainly of private, on-site training engagements (though the principle could be extended to on-going discussions with individual students too). You’ll probably have a discussion at the beginning and/or end of each day with the manager who set up the training. You should definitely bring any issues about class preparedness level to that person’s attention.

When you do, you’ll find that ninety-nine percent of the time the manager will say something like, “Yeah, I was afraid that it would be too easy for Julie” or “Bill said he’d learn Ruby on his own over the weekend but I guess he didn’t.” The manager knows the team. None of what you say is going to be a huge surprise.

Be sympathetic, though. The client didn’t do this to make your life hard. At worst, they just didn’t think it through in terms of preparation and were eager to get the most value out of your skills. Everyone’s acting in good faith.

Sometimes, the manager will take someone out of the training after the first day. I always feel a pang of guilt at this—but I shouldn’t, and you shouldn’t. It’s a correction that will make things easier and more productive for everyone, including the person who shouldn’t have been in the training in the first place. Of course you want to challenge yourself to make the experience accessible to and meaningful for as many people as you can. But don’t be Utopian about it; there really is such a thing as a person for whom a given class at a given time just isn’t right.

Summary

Here’s a summary of the suggestions we’ve just gone over:

• A. Deliver what you promised to deliver
• B. Make the prerequisites clear in advance
• C. Try to control the teacher/student ratio
• D. Have extra material in reserve
• E. Enlist the help of the more advanced students
• F. Master the art of not answering questions
• G. Make it easy to move around the materials (e.g., staged code shapshots)
• H. Talk to the person in charge

Handling the mixed-level classroom successfully is not easy. You need to stay alert and to keep applying energy to the situation to make it as good as it can be for everyone, while delivering what you promised to deliver. A mixed-level group requires agility and adaptability, but with structure.

Some of the training companies I subcontract with do Likert scale evaluations (“Strongly agree, Agree, Neutral…”—that kind of question). One of the questions is often about the pace of the class: much too slow, too slow, perfect, etc. In a mixed-level class, I don’t expect everyone to say the pace was perfect. I aim, though, for the mathematically best result possible: I want the curve to max out at “perfect” and fall away (hopefully not too far) to the sides.

Then I know I’ve done my best.