Developing foundation level security training for the beginners and the advanced
I’m torn when it comes to developing and deploying “foundation” level training. I completely understand (and agree with!) the necessity of bringing everyone in a group up to a common proficiency level through the teaching of basic key terms and concepts. I get it. This is important if people and functional groups are expected to interoperate.
The problem I have with “foundation” level training is that the most critical concepts in a technical topic often have to be simplified past the point of usefulness for beginners. Sometimes, simplified to where the lesson being taught is expressing the opposite of what people will need to know when they start putting the skill into practice. Why? Because newcomers to a field often lack the context and nuance needed to put key concepts into perspective until they’ve digested incorrect mental models.
I’ve been sketching a dialogic to make this make sense. Please ignore the ridiculous premise:
Imagine a baby and his father sitting at a table, eating their respective dinners. The father is enjoying a steak, carefully cutting off each bite. The baby, watching closely, is shovelling strained carrots into his maw with his fingers. After a few minutes of this, the baby considers his father’s dinner, and speaks:
“Father, I would like to eat what you’re eating.”
The father considers his child’s argument and wisely replies “I’m sorry, son. You cannot eat what I am eating.”
“But why not, father?” The impossibly articulate baby says. “We are both eating food. Why can your food not also be my food?”
“You are not ready for this food,” the father says. “Not yet.”
“Not ready?” the baby says, indignantly. “See here, father! I have eaten the red mush, the orange mush, and the green mush without difficulty. I have eaten all of the foods. Therefore, I believe I am ready to eat your food as well.”
“Ah!” says the father in sympathy. “Yes, you have eaten all of the mush-type foods. That is true. This, however, is a solid food. More specifically, this is an advanced solid food. If I were to let you eat this, you would likely choke on it and die.”
“That is preposterous,” says the baby. “Why would I choke on this ‘solid food’ of yours. I have never choked on food before.”
“But you have choked on your mush, before” the father says. “When you were younger and still learning how to transition from consuming only milk to eating mush. You have since mastered mush. Soon, we will start you eating simple solids. As you master the basic version of each new type of food, we will introduce you to new and more complicated variations of those foods.”
“Father! I find your position to be condescending and demeaning,” the baby says. “You insult me to assume that I lack the ability to tackle solid food. I want to be treated like a person, with dignity. You can accomplish this by sharing your steak. Why do you infantilize me?”
“I’m very sorry that you feel that way,” the father says. “I have no doubts as to the strength of your will or the purity of your intent. The fundamental obstacle to offering you advanced solid foods right now is that you lack teeth.”
The baby ponders this revelation for some time, then asks “What are teeth?”
Yes, it’s a silly conversation. That said, consider it from each speaker’s unique point of view: the “baby” character sees others engaging in an activity and wishes to be treated as an equal. By refusing to allow him to participate, he (rightfully) feels condescended to and, possibly, discriminated against. This is frustrating; being left out of activities or discussions – especially high-prestige activities or discussions – is tantamount to being ostracised. The “father” character, meanwhile, does not intend any of those things. Instead, the more experienced father realises that the optimal way to transition his child from milk to steak involves intermediate steps; mastery of cereal must happen be assured long he orders a T-bone for his toddler. He’s not being cruel, only pragmatic.
Does this come across as patronising? Of course it does! Every time we trainers deploy a course that must resonate with the least-proficient members of our user population, we know we’ll be roasted by angry students for “talking down to them.” Often, the angry “feedback” we receive is demoralizing. The thing is, we know from painful experience that every time we deploy advanced training on a population that isn’t ready for it – to appease the more technically-astute students – we’re condemning the least-technical students to unnecessary stress, frustration, and (inevitably) high failure rates. That’s the norm for basic technical training … it gets worse when we’re asked to teach skills that require mastery of esoteric and seemingly contradictory concepts as a prerequisite.
As a poignant example (that won’t embarrass anyone else), I tried to learn basic programming when I started working in IT. I’d taken ‘Introduction to BASIC on the Apple IIe” in high school. All of my technical friends in uni had mastered modern programming languages. I assumed that I could pick enough vocabulary and general concepts to at least follow along when my devs started yakking about their work.
I found a high-school textbook and started reading about “Programming in C.” In the first chapter, the writer introduced the concept of “recursion.” Paraphrasing from what I remember, the author said that you had to master this idea before you could write a single line of code. Here’s how it works:
“Your computer doesn’t know the answer to a problem. Therefore, it must ask something that knows the answer. So, it asks itself. But since it doesn’t know the answer, it can’t provide itself the answer. Now, having asked and still not knowing the answer, it asks itself again. It repeats this process until it gives itself the answer that it doesn’t have, and then it has the answer. Simple!”
That book went straight into the bin as hard as I could fling it.
I related this story to a developer friend. He was horrified. “That’s lunacy!” he said. “You don’t start teaching programming with bloody recursion; that’s an advanced concept that everyone has difficulty wrapping their heads around. It only makes sense once you know how computers treat your code.”
He was right. This long-forgotten textbook author skipped over the pablum-level foundations training needed to get comfortable with the essentials of programming (in general) and of how to code in C (specifically). I can only assume that the author intended this to be an “introduction” for an already-proficient, upper-class computer science major; it was an utter failure as an introduction to anything for a non-programmer.
I think back on that example every time I write a new “foundations” course. I remember how infuriating, condescending, and impenetrable that author’s approach was and vow to never inflict that sort of unnecessary (and counterproductive!) stress on my users. Sure, some of the advanced students will be bored; I can’t help that. We can’t serve everyone at the table steak (so to speak) if they don’t all have the teeth to chew it.