Know what you will need to know, don't worry about what you don't know.

I have recently taken a new position as a Technical Course Developer and Trainer. Things are gearing up fast to learn the current material well enough to teach it. This is the first time I have had to teach and develop material where I didn’t already have a lot of hands-on experience with the product. This of course has made me think about some interesting challenges to my work and opportunities to improve my skills.

The biggest challenge in teaching technology is for the instructor to know the material well enough. There are two big reasons for this. The first is that your students get valuable instruction. You aren’t ripping them off, teaching them nonsense, are you? The other reason for really knowing the material is so your students will buy into your abilities. Often when teaching technical folks, the students may assume they are smarter and more skilled than you as an instructor. They may even try to show you that they know so much more than you that you have nothing to offer them. This is the l33t effect, the guys who sit in the front row of class and try to show you they know more than you. These people are usually sent to training classes against their will by their companies. Do not worry about that. With proper preparation in the specific area that you are instructing on, you will always have plenty to offer the class, and you will sell your abilities to the students in no time.

You can safely assume that you will never know everything about your subject. If ten people spent a year writing code in PHP, by definition, there will be 10 years worth (minus developer-surfing-the-net-time) of full-time PHP work and knowledge in the ether. It would probably take you 10 years to really absorb it all. Multiply that by however many hundreds or thousands of people working with a given technology you are teaching and you can see that no matter what, you will never know it all.

If you can’t know it all, then what qualifies you to teach? As an instructor, you will need to bring specific knowledge to the table. What you really want to do is know a lot about the specific areas that your students will need to know. Create a clear curriculum with specific objectives. Make sure you can accomplish all of the goals of the curriculum yourself before the class by following the same instructions you will give the students. Make sure to know each exercise from start to finish and attempt to anticipate problems before the class so troubleshooting will not be a problem.

Simply being in charge of the material you are teaching will make you a much more successful instructor. You will be more confident, won’t stutter, and will maintain the respect of your students. Don’t worry about the things near your subject that you don’t have detailed knowledge of. Just be well versed in the specifics of your class and follow your teaching plan. In no time at all, you will have sold yourself and your knowledge to the students. Even if the students know 10 times more than you, if you leave them with new knowledge and skills, they will be thrilled to come back to get more.

Finishing up the Ruby on Rails Course

I've spent all weekend tweaking and polishing (and adding and editing) the Ruby on Rails course material (and exercises) for my upcoming Ruby on Rails Bootcamp at the Big Nerd Ranch. This course is sure to be a hit, as it is a) taught by moi, b) practical and down to earth, and c) mixed in with some real-live honest-to-goodness examples from in the trenches.

Often times, course work or examples will use the occasional "foo" or "bar" variables, a sort-of inside joke among programmers, that, to be honest, I never quite got. Yes, yes, I know, FUBAR is the acronym for Messed Up Beyond All Repair, but I just don't get it. That's why I'm on a mission to remove this from the hacker repetoire, and only provide real examples with at least a semblance of real-word-ality. Well, I actually do enjoy a good Lindsey Lohan reference or two and my course is chock full of 'em:

@user = User.find :first,
  :conditions => [‘age < ?’, 21] @user.first_name # => “Lindsey”
@user.age        # => 21

I'm getting geared up and ready with my tricked out Keynote slides, movie demonstrations, and plenty of real-world project code that's a QuickSilver shortcut away.

Spray Down the Monkeys

Start with a cage containing five monkeys. Inside the cage, hang a banana on a string and place a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, spray all of the other monkeys with cold water. After a while, another monkey makes an attempt with the same result, and all the other monkeys are sprayed with cold water. Pretty soon the monkeys will try to prevent it.

Now, put away the cold water. Remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all of the other monkeys attack him. After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.

Next, remove another of the original five monkeys and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then the fifth.

Every time the newest monkey takes to the stairs, he is attacked. Most of the monkeys that are beating him have no idea why they were not permitted to climb the stairs or why they are participating in the beating of the newest monkey. After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water. Nevertheless, no monkey ever again approaches the stairs to try for the banana. Why not? Because as far as they know that's the way it's always been done around here.

-- Unknown Attribution