Teaching Technology

This week, I am teaching an API programming class from Cambridge, MA to students in Bangalore, India and Atlanta, GA. When teaching an API class, I always find that it's much much easier to set the computers up ahead of time and let the students just dive in. The alternative is that students spend an entire day on install that may or may not work. The students being remote and having a small language barrier, this makes it all the more difficult to solve install and configuration issues.

Technology to the rescue!

I solved the install problem by using virtual Windows XP machines using VM Ware. I just created the VM one time and copied it to each computer, so each student starts out with a fresh install of Windows and our software. I have six computers sitting in a U shape around me, so I can view the screen of each one. I am controlling the class from a WebEx session using teh "Hands-on Lab" feature. I can present my documents, share applications, and when I want the students to work on the machines, I assign each one to his own computer. It seems to be a very effective way of solving the "distance-access" issue. I intend to do this more often.

Teaching Programming

I've always wanted to find a decent way to teach programming concepts to kids. The most uber-l33t programmers I know are people who started before they took Computer Science in college.

In another vein, I have a soft-spot for graphics programming. There is something satisfying about making programs that you can see. Scripting is useful, graphics is fun.

So I found this language called "Processing". It's a language based on Java that comes in the simplest IDE I've ever seen. The really cool thing about processing is how they simplify out a graphical hello-world application into zero lines. From there, you can add more and more complex interactions based on your level of experience and learning. It provides the perfect framework for teaching programming. Because the language is intended to produce graphics, variables are easily represented as big moving circles and squares, a big improvement for a beginner over printing values to the console to keep mental track of state. Because Processing is so simple, you don't teach the language so much as you teach the concepts.

Check out http://processing.org

And check out my presentation May 2 at the Mac Tech Group
http://www.mactechgroup.org

Teaching class this week

I'm teaching class this week. The class that I'm teaching has been taught many times by many people and is very refined. I have a teacher's edition of the book, which is an awesome crutch!

My past classes that I've taught have been a little less refined. The most I had was instructor notes that I inherited from another instructor with my updates.

I'm having to do little prep-work because every page, every exercise, every slide is spelled out to me. Surprisingly, it's given me more freedom. I find myself less concerned about knowing what to say next, and I have more time to devote to the students' questions and class discussion.

Lesson learned: Winging it is easier when you have a solid plan.

Sell your Presentation

We had someone interviewing for a job as a trainer at my company today. He had to give a presentation on a subject that he had little knowledge about. He did not get the job.

He told us that he had done 16 hours of research plus 4 hours putting together the presentation, and I believe him. I was mildly impressed that he had learned the subject on his own. From his screen shots, I could see that he had installed the software and gained a beginners mastery of the subject.

But he didn't sell himself or his presentation. Instead, he treated the presentation like a test. He assumed that everyone in the class had a working knowledge of the subject and he tried to prove that he had learned it to their satisfaction.

If he had attacked the training as if he were the most expert person in the room, he would have sold his presentation much better. There were some other factors as well. He looked at the floor a lot instead of the class, but I believe he would have been much more successful had he just explained everything throughly from the general subject to the details instead of acting like he was on trial.

That's just my 2 cents.

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