Node.js® Enterprise Support
New comprehensive plans availableLearn More
Thank you for contacting us. We will get back to you shortly.
May 06, 2013 - by Mr. Max Bruning
Talking with Brendan Gregg and Deirdré Straughan of Joyent last Friday, we thought it would be a good idea to blog about training that Joyent offers, and a bit about how we do training differently from what a lot of people have come to expect from corporate training.
Over the years, I have heard the following from many students:
This gives corporate training a bad reputation, which is a shame because people miss out on good opportunities to learn new skills and to develop their own career.
In this blog, I'll start off by discussing what makes for a good instructor. Then, I'll dive into what makes for good course material and labs. Finally, I'll conclude with a description of what we are doing with respect to training at Joyent.
My view has always been that the instructor makes or breaks the course. A good instructor can make up for shortcomings in the material presented, and can either answer questions, or show students how to find out answers for themselves. Great material cannot make up for a poor instructor. Basically, if the material is good and the instructor is not good, students would be better off reading the materials and skipping the class time. The best situation is to have both a good instructor and good material.
I tell my students that if they want me to read the course materials, they can read them on their own, I'll take a few days off, and we'll get together at the end of the class for Q&A.
So, what makes a good instructor? A good instructor should:
Have real experience: Instructors should have real-world work experience doing the things they are teaching. So, for instance, if someone is teaching how to administer a database, they should have actual experience administering a database. This helps course delivery in many ways, including being able to emphasize course material that’s most relevant for the real world, and to fill in any gaps. It also helps to tell "war stories," but only if they are applicable to the subject being taught. Years ago, I was asked to teach Java. I said "Give me 6 months or so to implement something real." I was told that I should be able to teach just from going over the course materials and reading some books. For me, this is not enough – I didn’t believe I’d be a credible Java instructor. I still do not teach Java. I have heard of someone who was an experienced Java programmer teaching a course about device drivers. (For those who are unaware, drivers, at least on Linux and SmartOS, are written in C.)
Be a subject matter expert: Have both depth-wise and breadth-wise knowledge of the subject being taught. The instructor may not know absolutely everything about the subject, but should know enough to figure out any specific question. There’s usually always more to learn about a subject anyway, which can keep the class interesting for both the students and instructor.
Have insider knowledge: When delivering a product-related course, a good instructor needs insider knowledge: either they currently work for the company that develops the product, or have in the past and stay up to date. This means they will be familiar with:
Demonstrate: Show as many live demos as possible. This is useful for a couple of reasons:
Answer questions: Either by knowing the answer, or by showing the student how to find out the answer. I have had many students who tell me they learned as much from watching me figure out the answer to a question as they did from the material itself. Of course, the instructor (and the class) must decide if the question is within the scope of the material that is being taught.
Ask questions: Students tend to learn better when they are challenged. I ask questions to try to get students to think, but I also ask questions to try to gauge their experience level.
Challenge: Be able to determine which students have the most experience in the subject, and aim high. Better to have the best students involved than to bore them. At the same time, the instructor needs to try to "pull up" those with less experience. With good students actively involved, they are often willing to help with students who have less experience.
Be resourceful: Make use of all available materials. This includes course materials, demos, labs, ad-hoc demos, the knowledge of the students themselves, and material available on the Internet. It also includes any subject matter experts who are available. For instance, at Joyent we have very knowledgeable engineers working on different aspects of the products that Joyent sells and uses. As an instructor with Joyent, I can make use of these subject matter experts when needed.
Have patience: I know some people who are extremely knowledgeable about various topics, and are excellent speakers. But in a classroom setting, they are not necessarily good instructors, largely because they don't have patience with the people who can't keep up or understand.
Customize: Adapt the course to fit the audience. This can include covering some topics in more or less detail, as well as adding/subtracting topics. In some sense, every course should be "customized," depending on the students attending.
Mentor: Go over any lab work that the class is especially interested in, or which students had problems completing.
Manage the classroom: This includes being able to handle "problem" students. This can range from someone who believes they can teach the subject better, or who believes they know the subject better, to students who just plain don't "get it." Students who actually know the subject better can be useful as tools for teaching the class. Sometimes I have a student who thinks something I have said is incorrect. When this happens, if I realize I am incorrect, I'll say so. If I think I am right, I'll try to come up with a way (along with the student) to test what I (or they) are saying. Often, we find out that we are both correct, but we were saying the same thing in different ways. For students who don't "get it," taking them aside (during lab time, for instance), and simplifying the topic or the lab work can often be helpful. Another type of "problem" student is the "asshole." Fortunately, I never have assholes in my classes...
Be timely: Show up on time, and be willing to stay late if needed.
Have a clear goal: Explain what is to be taught and why before starting on the material, and explain again afterwards. My goal is not to simply get through the material – it’s to give students skills they can use afterwards, which is the real objective of the course.
Know the curriculum: Know what courses are offered by the company/educational institution for which he/she is teaching. This doesn't mean that an instructor needs to be able to teach every course being offered by a company, but they should know, at a high level, what topics are covered.
Be respectful: Treat students with respect.
Avoid controversial topics: This doesn't mean you can't have a discussion about the relative merits of, say, emacs versus any other piece of junk editor. I usually at some point tell students that discussions on politics, guns, religion, etc., are not welcome in the class. This gives us little else to talk about than the topic at hand (or sports and the weather).
Know cultural differences: I have taught classes all over the world. Some cultures are less likely to ask or answer questions. Generally, puns don't port (though telling people they can tune a file system, but cannot tuna fish typically gets a few laughs). If you are traveling to a country which you have not visited before, try to learn a little bit about local customs before you show up. It's so much more polite.
Be motivating: Apart from everything else, it helps if the instructor is also interesting and entertaining. That can help students maintain attention during long courses. The instructor should be a motivator. And, instructors should be interested in the topics they are teaching – their interest can be contagious.
As for course materials...I prefer to use documentation whenever possible in lieu of formal course notes. This documentation is usually online, as manuals or a wiki. If the documentation is good, there should be no need for course notes, aside from labs. This documentation is also updated, and stays relevant, long after a printed courseware manual would become out of date.
At least one place I did training had a whole team to do documentation (which was quite good), and typically used contractors to write courseware. The courseware always lagged behind documentation, and was never as complete or accurate. (I was told it was done this way because people couldn't teach from the documentation, but I think that if you can't teach from the documentation, either the documentation is not good, or you can't teach). Of course, if there is no documentation, or the documentation is not complete, you need course notes.
Good labs are much more useful than lecture notes. These should be as hands-on as possible, and should clearly demonstrate specific skills or concepts being taught. Lab work should not only reinforce the subject being taught, it should also extend student’s knowledge. Labs should be non-trivial, but should doable within the time frame of the course.
Different people learn in different ways. Some people want to listen, some want to read, some like diagrams, some like code. In general, the best way to learn is to do, (see Tacit_knowledge). This is why good labs are so important. During labs, students start to find out what they did not know. One of the best classes I taught was when I was sick, so gave the students extra lab work instead of spending as much time lecturing.
I like diagrams. They show the different components of some piece of the systems, as well as interrelationships between them. I generally like to have the finished diagram in the material, but build the diagram from scratch on a white board, explaining each piece as I draw. For code, I like to show pseudo-code, but will dive into the actual code for specific questions.
Good course materials tend to be organic. That is, they change over time. Each instructor will typically have their own approach to teaching the material. The important thing is that the students learn the objectives that should be specified at the beginning of the class.
Currently, we are developing a set of approximately 28 different courses as part of a full certification program. Some of these courses have already been written and taught (see here for a list). I'll write more about Joyent certification in a future blog post. Students who have already attended Joyent courses will get credit towards certification. One of the goals for certification is to produce people whom companies like Joyent and others would want to hire.
With our certification program, we want to train students in all aspects of the cloud (not limited to Joyent). Training and certification is a means to further your career, and it’s a good idea to have taking at least one training course every year. Don't take it lightly.
If you are a manager, allocating at least one training class per person a year keeps your staff current. This can be cost effective means to grow top talent. Not training them (eg, at risk they would then leave for higher paid jobs) can be worse:
“Zig Ziglar once said that there was only one thing worse than training (or growing) your staff and having them leave, and that is not training or developing them and having them stay.” (via Alaister Low)
If you’d like to take courses at Joyent, check whether your company has a training or staff development budget. Most larger companies do, and it’s generally "use it or lose it", so they’ll be looking to spend it. Smaller and newer companies may not be accustomed to the idea of paying (and you taking time out of the office) for training, but, if your company is using the cloud at all (and, soon if not now, it likely will be), there’s a good case to be made for training.
Instructors at Joyent are very experienced trainers, and they have also done and continue to do engineering work on products that Joyent sells and/or uses. We have very good rapport with the engineers in the company, and have extensive experience doing development, support, debugging/troubleshooting, performance analysis, and training. We do extensive demos, and spend a lot of time with course labs. Basically, Joyent does not use instructors who do not fit the model of what makes a good instructor which I described above.
Next week, I'll probably return to more technical stuff. As usual, I welcome any comments, questions, or suggestions.