(Often,) You People are Too Smart to Train

August 15, 2012 By Tim OBrien

5 minute read time

Too smart to train?

I don't often teach our training classes in Maven or Nexus, but when I do, I always tend to get interesting classes. I'm halfway through a on site training class today that, so far, has stood out as a unique experience for me as a trainer. Usually you set up your slides, hand out the materials, and start running through the content. It often takes a class and an instructor an hour to find a good cadence for teaching and answering questions. One metric I keep track of is the amount of time spent delivering content from slides vs. the amount of time spent answering questions. I strive for 75/25 - 3/4 of the class is focusing on content, 1/4 of the class is focused on answer student questions.

The first thing I do in my classes is implore (literally plead) with the students to interrupt me. "Ask questions. If you don't this class won't be valuable to you." I do this because all too often I have a class of students that seems reticent to ask question or interrupt. Who knows why, maybe they don't want to ask a dumb question (those don't exist), maybe they are taking the class with a manager and they don't want to look bad? Whatever the case, silence is the worst thing an instructor can get in response to the question: "Are there any questions?..... no?..... anyone? Ok. Anyone want to make a statement?.... no? alright, let's move on..."

The worst classes for an instructor are the classes that sit, silently listening to the slide content. Maybe they nod every once in a while, but it is impossible to read them. 8 out of 10 times you'll get some feedback from some in these classes that the class didn't meet their needs because it didn't focus on X, Y, or Z. (My first response to this is always, "did they ask questions?") In these classes, the instructor doesn't learn anything from the experience, and reading slides for 7-8 hours is torture. I like questions, and I thrive on difficult questions and people that need convincing. The best Maven training classes have at least one or two students that want to talk about some difficult topic like Ant Migration or how to use Gradle.

What I'm trying to say is that I hate "teaching" a training class, I'd much prefer to engage a in back-an-forth because this is what I think training should be I don't go as far as using the Socratic method to elicit participation because there's just too much content to cover, but I want someone to stop me midsentence and ask a question like: "Why? Justify that statement about dependencies. I don't agree with that." Our content is purposefully designed to get a response from the students, and our trainers are trained not to deliver the content but to know everything there is to know about the topic. This is the only way to teach a topic.

On Tuesday I started our training class, as I normally do. I asked every student to introduce themselves and talk about what they wanted to gain from the class. After 10 seconds of this I could tell this wasn't going to be a normal Maven 101 experience.

Me: "Ok, so introduce your self and tell me what you are trying to get from the class?"

Typical response from this class: "We running a Jenkins build with over five thousand builds and we're having specific problems with the -U flag. We need to find a way to write both a custom Nexus plugin and a custom Maven plugin to change the way the CI server works with the respository. Also we've tested Smart Proxy and we have some feedback.......

This continued for about ten students, and this is the moment in time where the instructor stands there, blinking, and wonders why any of them are in a Maven 101 class. While I do think that everyone *can* benefit from a return to the basics, I was teaching a room full of developers that were likely more qualified than some of the people on the Maven committer list to discuss Maven internals.

In these cases, our trainers, myself included, are taught to adapt quickly. I wasn't going to dwell on the 101 content, I was going to run through it, but skip the sections that made no sense for this audience. For example, if everyone in the room has had experience writing a custom Maven plugin, I'm fairly certain they know what an artifact coordinate is, and I'm also sure they understand how to install Maven. Because our training material is modular, our instructors have the ability to mix and match content if they find themselves standing in front of a class that is way too smart to train .

When all your students understand Maven basics and even most advanced Maven topics, the class turns into a seminar on best practices and a discussion. Instead of talking about what a dependency is, you end up getting realtime feedback about how Maven works - "You know it would be much easier if we could change how the updatePolicy worked, how do we do that" or "m2eclipse lifecycle mapping is a real pain in the neck" (an observation I agree with BTW). The class I was about to teach turns into a conversation, and I'm detailing best practices about deployment.

Now this doesn't work for all training classes. Especially our virtual training, on our virtual training it is difficult to change the flow of the class because we do have people who approach us who have never used Maven, and we're usually teaching to multiple companies. This "seminar" approach isn't appropriate if members of your team need to drill into the basic of Maven, it only really works well when everyone in the class has demonstrated a solid baseline.

Generally, I'm noticing this more and more. Nexus and Maven are so widespread and so well regarded that people understand the concepts already. This wasn't the case when we started five years ago. These days I walk into a place and several of the students are already sold on the imperative to run a repository manager. They used our online documentation to bring themselves up to the point where they are often too smart to train.

Tags: Sonatype Says, Training

Written by Tim OBrien

Tim is a Software Architect with experience in all aspects of software development from project inception to developing scaleable production architectures for large-scale systems during critical, high-risk events such as Black Friday. He has helped many organizations ranging from small startups to Fortune 100 companies take a more strategic approach to adopting and evaluating technology and managing the risks associated with change.