Top 3 Virtual Trainer Mistakes

Top 3 Virtual Trainer mistakes and how to fix them

#1. You train your students to not answer your questions.

How do you do it?

Simply ask a question, wait a fraction of a second (or much longer) then answer the question. Do it once and your students may think they didn’t act fast enough to answer your question, or you didn’t give them enough time to collect their thoughts. Do it twice and they think twice. Do it three times and they get the message: I’m not supposed to answer these questions; my instructor will both ask and answer.

How do you fix it?

Tell your students at the beginning of the class, in no uncertain terms, that you will be asking questions and expecting responses. For virtual training it is imperative to tell them how to answer your questions (chat window, unmute, etc.). After asking the question, pause long enough to allow the students to reflect on the question and formulate their answer. Remember this material is new to them. Still no response? Ask for one! Still no response? Call someone by name. After this scenario plays out at least 3 times, they will get the message: instructor will ask a question and class resumes when someone answers. No one answering? I should be prepared to be called upon for an answer.

#2. You consistently overlook learning opportunities.

How do you do it?

a.??When a single student asks a question (unmuted or via chat), you answer the question directly to the student (implicitly allowing everyone else to check out).

b.??A student shares a failed exercise (code error, missing code, or some demonstration of a lack of understanding) and you fix the error.

c.??You begin a new topic by lecturing, live-coding, or some other demonstrational technique.

How do you fix it?

a.??When a single student asks a question (unmuted or via chat), repeat or re-read the question for everyone to hear. Ask other students to answer the question. You have now involved everyone in a learning experience. It’s often cited that students remember 20% of what we instructors say but as high as 80% of what they say. Remind them of that fact and don’t deprive them of the opportunity to make learning stick!

b.??Ask the student to describe the error (while screen sharing it). Let the other students know it is their job to locate and describe the error. It is a group project now! Everyone is thinking, not just the learner who asked the question. This is a great time to remind everyone to use their annotation tools!

c.???Before a new topic begins ask some exploratory questions. “Is anyone familiar with…” “Does anyone know the meaning of…” These questions are imperative with adult learners who come to class with a vast array of prior experience. Acknowledging this is not only respectful but it helps us trainers adjust pace and not lecture on topics the group is either already well versed in or can relate to from other programming languages and concepts. In the early part of my career it took me awhile to realize that I was losing students?not because they didn’t understand the material but because they already knew it. Don’t waste students time. Find out what they know about every topic before you teach it from the ground up. It’s especially difficult when teaching virtually to “see” students checking out making this point very important indeed.

#3 You lecture (or live code) for 15+ minutes about a concept when a simple graphic would be more impactful.

How do you do it?

You are introducing a new concept (scope, cyclometric complexity; dependency injection, call stack, promises, etc.) and your goal is to focus on the high-level concept. You immediately lecture (with or without live code) and move quickly away from the overall concept and into the details of the code. This can cause ?many learners to miss the concept as well as how they might apply it in a variety of coding contexts.

How to fix it

One solution is to use a simple graphic to explain the concept from a high level. Only after you are certain that the concept is understood (through questioning your learners ) should you follow-up with concrete coding examples. The challenge is most trainers are pressed for time and would argue that they do not have either the time or the skills to generate graphics. Admittedly a “simple” graphic is anything but simply to create. My graphics are time consuming to create and often revised and edited much like text. The result however is the effective (and quick) transfer of knowledge. My students almost unanimously ask for my slide deck specifically because the images are that compelling.

Effective graphics have the following characteristics:

1.??????They are animated. By slowly revealing the concepts one at a time you decrease the cognitive load on your learners and can more quickly and easily confirm their understanding.

2.??????They make an impact on the learner that increases the likelihood of retention. No boring canned concept maps, flow charts, and so on that consist of simple shapes as these are easily forgotten. Use wild memorable images!

3.??????They are demonstrated quickly. Just because they have animation doesn’t mean they have to be slow to display. Move quickly and let the images do the talking!

4.??????They load fast. No fumbling back and forth between your IDE, browser and any other screens you need to share. This is distracting to the student and difficult to follow. Simply load the graphic and begin. When demonstrating a common topic (such as how to find my repo and clone it), I use a animated GIF that is already loaded into my slide deck. ?I use ScreenToGif for this.

Learning will stick if you follow-up by asking your students how this concept may be implemented in their projects. Using thoughtful graphics also provides a useful side effect. They load quickly and show professionalism as opposed to jumping from screen to screen combined with lag time inherit in virtual training; and it tells the learners you are well prepared and have considered the material from their?