Instructor labels –
Green circle = the assignment
Gray circle = what students think is important
Include a section in the assignment that clearly spells out what you DON’T care about for grading. It’s as important as the rubric you use for grading.
At least perfect the right thing. pic.twitter.com/nTtyT5gQuE
— Janis Ozolins (@OzolinsJanis) June 17, 2021
Today I received the best compliment on my #30DaysofHTML course, even before it launches.
I don’t know how you’ve managed it, but you’ve gotten me all excited about HTML.
— ოarῐa ᥨaῃ𝙜әr 🚁😷💉🇺🇸 (@mlanger) April 1, 2021
This gets to the heart of why I started this challenge and my thinking behind it.
HTML is the scaffolding behind a web page. It’s as exciting as framing a house, or playing bass or drums in a rock band. In other words, there’s some artistry, but it’s underappreciated by most. Done right, it’s in the shadow of way more exciting and interesting elements of the project. However, without it, nothing else matters – HTML is foundational to a website.
When developers teach new developers HTML, it’s presented as a necessary evil. As little time as possible is spent on it, because everyone wants to get on to making things pretty and interactive – neither of which is a thing with HTML. Quick quick, here’s a tag, here’s an attribute, open/close things – whew, let’s move on.
As a result, HTML is the mushroom of the web world. It’s kept in the dark, and it eats a lot of crap by people who see nothing to love.
The purpose of the Hypertext Markup Language is to identify the parts of the web page: paragraphs, lists, headings, links, addresses, quotations, and so much more. How many times have I said this sentence in 20 years of teaching?
But finally, I made a connection: HTML is intimately tied to the story of the website.
Everyone wants to be heard and understood. Everyone wants their story heard. Great HTML is the way to communicate your story to the world.
When I was 14 months old and hungry, I would pull on my mother’s pant leg, point to the counter looming over my head, and grunt, “Cookie.” (Or so my mother says. I do not remember.) She would respond by giving me fruit, crackers, a bowl of dry Cheerios, or whatever else a 14 month old eats. Not a cookie, no matter hard I tried. Or she’d tell me it was almost dinner time and go away and leave her to finish it.
Consider that your crappy HTML is telling this same story. If your website is nothing but one < div > after another, you’re just saying COOKIE COOKIE COOKIE. You’re 14 months old, with a limited grasp of vocabulary.
So. How do you convince developers, who just love everything pretty and interactive, that their framing sucks and doesn’t work? Their code that sits on top of it works just fine. Framing is SO BORING.
Well, accessibility, of course! It’s absolutely critical. Accessibility should start at the beginning. It should always be incorporated in the site. Good accessibility starts with meaningful HTML.
But – what the accessibility advocates are doing is not effective to get developer attention. They are, unfortunately, ignored for the most part.
We’ve (maybe) gotten (some) busy developers to feel guilty about their bad HTML. But changing it takes effort. Learning what HTML elements are available takes time and research. Time that could be spent learning the latest JavaScript framework.
Time for a new story with new framing.
If we focus on HTML’s syntax, that’s not interesting. What’s interesting is the meaning conveyed behind the elements. Why choose one element over another? How does that element contribute to the website’s story?
30DaysofHTML incorporates the following concepts:
Focus on the meaning behind the elements. When should something be used or not used?
Don’t overwhelm with all of the edge cases and complexity. Provide just enough information to feel like you know a little bit, and provide links to everything else.
Identify any misconceptions about the element. HTML looks like English. The < address > element, for example, looks like it’s for a postal address. However, it can be used for any contact information associated with an article or website author, including phone numbers, email address, social media links, or even geographic coordinates. Who knew that? That’s interesting and fun and different.
Remove the pretty and interactive, so learners are forced to focus on the scaffolding. We aren’t concerned with cross-device presentation or UX or anything else. It’s black text on a white page. There’s nothing else to do here… by design.
Encourage application, reflection, and discussion. Not only should there be a little reading, but there should be some examples and problems to try too. Maybe the occasional quiz. Encourage readers to share their work and comment on each other’s markup and approaches. Put the discussion on the meaning we’re trying to convey.
And finally, make it fun. Make some fun graphics, throw in a few emojis, use all of the web writing techniques to break up content with headings and lists. Write in a fun and informal style.
Draw the reader in. Make them curious. Conflict is interesting. The lure of something that perhaps you don’t know is intriguing.
I also sent out a “Night Before” email, explaining what to expect and how it will all work. This sets anxious learners at ease, and it sets expectations and generates interest. It also sets metrics for what success looks like.
The “X Days” format is popular at this moment. People talk about #100DaysofCode and #100DaysofNoCode and such. Why not #30DaysofHTML? Fortunately, it explains everything you need to know in the hashtag. 30 days, talking about HTML.
Email is the format for delivery. It’s simple, easy, and everyone has it. Using Substack, I also create a website, and it has interesting discussion features for sharing work.
In Silicon Valley speak, “reduce friction.” The email goes in your inbox. You read it when you’re ready. Another appears tomorrow. You’re getting 30 emails in 30 days. What’s not to love?
This is the start of my 30 day journey. I hope to learn more about HTML, but mostly, I hope to learn more about offering instruction in this format. What works and what falls flat? What is the response? What would I do differently next time?
I’ll write more about this in May.
Remember paint-by-number as a kid? There was a black and white drawing of something, sprinkled with numbers. The numbers correspond to the paint colors. Match the paint color to the numbers in the drawing, and presto, instant masterpiece.
This is the mental model of many people creating websites, flyers for the bake sale, and other digital communications. Find the template you need, drop in your own information, and presto, instant masterpiece.
Only in both cases, it’s not really a masterpiece.
With paint-by-number, painters get the joy of doing the painting without doing the work of visualizing something and mastering painting technique to produce the thing.
With a Microsoft Word template, there may be a match to what the user wants to convey. An event flyer to hang in a coffee shop or library contains all of the same information: event title, time/date/location/cost, brief description of what happens and what will be experienced, contact information for questions, and an eye-catching graphic. Of course, the flyer looks similar to other fliers on the bulletin board, because everyone is using similar templates. But it may accomplish its goal.
With websites, templates provide a way for many to structure their content. They don’t quite know what to say, or how to say it, but they need a website. They pick a template, fill in the information to the best of their ability, and hope it works well enough to accomplish their goal(s).
Creating a method(s) to guide someone through the thinking process about a problem at hand is incredibly difficult. We get distracted by the “edge cases,” the 20% of cases when the process doesn’t work, rather than the 80% of cases where it does.
Refining the method to a fill-in-the-blank document, workbook, or template is another layer of abstraction where another 20% of cases are lost along the way.
Structured thinking about a problem is really difficult. If you can refine your methods for approaching a problem into a paint-by-number solution, people will pay lots of money for it, even if it’s not perfect.
I’ve created “courses” at LinkedIn Learning since 2008, when the company was called Lynda.com. Lynda.com was one of the earliest, if not the first, video training companies out there.
Their course format is a series of short videos. One video segment may lead into another, but fundamentally, each segment stands alone as a unit. After (theoretically) watching the videos, you receive a certificate of completion which you may attached to your LinkedIn profile.
Theoretically, because you can get this certificate simply by streaming the videos in the background, on mute.
Theoretically, because there’s no transference of skills happening to one’s own projects or situation, no reflection on the learning process, nor is there a meaningful evaluation of learning for either the learner or the instructor. LinkedIn Learning is aware of this issue and they continue to work on ways to solve it.
However, the genie is out of the bottle, so to speak. The LinkedIn Learning/Lynda.com “course” has become a misnomer that others try to emulate.
Photo by Karolina Grabowska from Pexels
In the explosion of online courses offered all over the internet, a “course” is now a series of videos hidden behind a login. Pay your money and get a handful of overproduced videos that cover your area of interest.
Then the creators wonder why students aren’t learning the material, or wondering why sales have dropped. Currently, creators turn to more bells and whistles in the videos, more animation, more attempts to make “edutainment” rather than solid education.
Even if your course is an asynchronous, instructor-absent course, where students move through it at their own pace, you need more than video to truly make a course.
Videos are awesome for demonstrating something. However, they’re terrible for transferring knowledge to a new environment. They’re not good for measuring what you’ve learned. Consider how often you watched someone do something and you think, “that doesn’t look so hard.” Then you try it, and you quickly discover that you have no idea what you’re doing.
Yes, have videos in your course. No, videos aren’t the whole course. You need more to round out the learning experience. Here’s some suggestions.
Add self-graded quizzes to evaluate student’s assimilation of the video. These don’t have to be standard-issue multiple choice. Consider matching games, categorization games, and formats that involve photos, not just words. This type of evaluation is best for terminology or other behaviorist “you just gotta know this” material.
In your video, demonstrate how to do the thing you’re teaching. Ideally, students are following along with you, doing the same thing.
Now provide your students with the assets they need to do the same type of thing on their own. You provide the structure to think about the problem, the goal they’re trying to achieve, and any boundaries and guidelines for where they should focus their attention. Follow this up with a video explaining how you solved the problem. Bonus: have a discussion thread where students may post photos or links to their work, along with a brief reflection – what went well? Where did they get stuck? What do they still not understand? What would they do differently next time?
Finally, invite the students to do the thing on their own. Provide a separate discussion thread where they can show off their work. Again, encourage reflection, not just “this is my thing.”
The middle step is the most important, because this is when transference happens. By giving them a small project with everything they need to succeed, this is where students gain confidence or realize they need more help in a certain area. They get a sense of what’s required to do the thing on their own.
Incidentally, the middle step is the piece that’s missing in almost every course out there. It’s definitely missing in every software course. And it’s super critical for understanding how to program.
When students learn something new, they’re not only learning the buttons to click, or the syntax, or the structure. They are also learning the organizational tools and thinking processes that go with the thing they’re learning.
This is one of the most overlooked aspects of teaching. Students of all abilities and intelligence have an issue with this. My Harvard students had as difficult a time knowing where to start a project as students did at any other university where I’ve taught.
Give people a structure for thinking about the problem at hand. If it’s a 5-step process, the workbook contains those 5 steps written out, along with whatever questions they should address and a space to write. Include reflection questions. Include suggestions for making the activity more challenging or less challenging.
Surprisingly, even in our digital age, people do not mind printing a workbook and writing all over it. In fact, many prefer this methodology, because they feel like they have a tangible asset after class is done.
Hopefully some or all of these tips help you raise your online video series to a full course.
If I had to describe my T-shaped skills, I’d say my depth is in HTML/CSS and user interface design. Across the top, you’d find planning websites and UX, teaching skills, instructional design skills, marketing, and general technology skills – the ability to look at new software, figure it out, and apply it to a problem.
As I move into the no-code world, I’m watching a new group of people relearn the issues we already learned and understand well in the professional website world, the marketing world, and in the world of UX.
Today I watched someone define a target audience as “non-developers.”
Cool. We’ve left out the 0.3% of the population who are coders. That leaves 99.7% of the world left as a target audience. This is too broad.
Defining and targeting an audience for products is something already well-known to the world of marketing and user experience. However, the no-code world doesn’t know this work exists and has no idea how to apply it to what they do.
We see this in the coding world. People complain about how tired they are about coding solutions to their problems, maintaining those solutions, and so forth.
However, if you mention “no-code” to the coding world, they have no idea what you mean. They may also dismiss this out of hand as too trivial for their attention.
For those who are looking at new emerging sectors, see if you can identify what that sector currently struggles with knowing and mastering.
The no-code space current worries with user experience, marketing concepts, and project management. “Agile methodology for no-code” is a no-brainer for this space. No-coders need to know project management, but everything is currently framed with coding in mind.
User experience is framed with code in mind too, even though UX is a no-code world! What happens if you plan a product and hand it off to no-coders to implement? Nothing. It’s the same process you’d use for coding. But when you’re not using the language your audience speaks, then it feels like your concepts are inaccessible and unintuitive.
Speaking to your target audience is everything. When knowledge is locked up in the jargon of a specific discipline, it’s not transferable to others.
How can you make your work accessible to adjacent disciplines? How can you codify what you know into a framework that applies to cousins of your areas of interest?
Honestly, the last thing we need are the 24-year olds who discovered no-code during the pandemic to teach people how to build no-code products. They don’t have the background to do it well.
I was speaking with an English professor the other day. She was discussing how online teaching has changed her approach to class.
Previously, she’d have individual conversations with students about improving their writing. Now she has those conversations publicly, with all students in attendance on Zoom. She was particularly concerned about constructive critique and not embarrassing students.
I said, “Sounds like a music master class. Only you’re doing it with writing.”
In a music master class, a form that has been part of classical music teaching for centuries, a well-known and well-respected audience teaches a lesson from the stage. There are a handful of performers, playing a piece they’ve worked on for some time. The artist works with the student for a period of time, often 15-20 minutes. Typically, the artist focuses on one aspect of the student’s playing; often it’s the artistry that gets attention rather than the mechanics of notes and rhythms.
The audience gets enormous benefit from this:
They learn how a master performer thinks about and approaches a given piece of music.
They see teaching techniques on display, including how the student responds and improves to suggestions.
The audience may take some of the lessons back to their own playing in a moment of transferance.
The audience also listens critically, comparing their own performance of the same piece to the student’s and the artist’s work. Is there anything the audience member might take to improve their own work?
The audience also gets moments of critical thinking – do they agree with the artist’s analysis of the student? Many critiques are art, so there is no “correct” answer.
In an academic environment, the English department would rarely (never?) overlap with the music department. Indeed, academics who attempt to be “cross-discipline” often are penalized in promotions and tenure decisions. However, her husband is a musician, and she understood the parallel to the master class having attended a few with him.
Imagine how English class might change if they took more teaching tips from the music department.
Below is a recent thread about what makes a good online course. Click through to read the whole thing.
In the last 2 years, I’ve gone through 8 online courses but completed only two: WoP by @David_perell and BASB by @fortelabs. What makes them different and what can other course creators learn? Here are 11 components for creating a next-level online learning experience:
— Julia Saxena 🚀🚢 (@julia_saxena) August 8, 2020
Main points the author hits include:
Measurement of progress
Collaborative learning and feedback
Proper use of technology (like breakout rooms)
But her first item was this:
1. Onboarding: Before the course starts, let students reflect on their intention and goals. Measure their current state to show them where they are now. Then measure again at the end to show progress.
— Julia Saxena 🚀🚢 (@julia_saxena) August 8, 2020
This is the definition of humanistic learning theory. The learner should have their own goals and grades are irrelevant. Measuring their own learning is important.
This can be implemented by giving the same quiz at the beginning and end of the course, so students can measure learning in a firm way. Or it can be mushier – asking students to reflect on what they’ve learned is one way of doing this.
From the recent interview with Lynda Weinman, founder of Lynda.com:
To be a good artist, you must be critical. You don't have to save it all.
Here she was referring to her new 3D printed pottery work. However, she did go on to say this advice can apply to careers and career focus.
As she explained, sometimes you make a mistake, or you make something that’s not terribly awesome. Learn from what happened and let it go. Move on.
Many people let mistakes keep them from moving forward in their field. They obsess over the thing they did wrong, rather than figuring out the lessons in what to avoid or improve next time.
You don’t have to save it all. It’s ok to throw it out and move on.
Recently, I attended an excellent interview with Lynda Weinman, founder of Lynda.com. She sold Lynda.com to LinkedIn in 2015 for $1.5 billion.
Today, Lynda is creating 3D printed pottery. It combines tactile art with plenty of programming.
There were two reflection points she made that I thought were outstanding and transferable. This post involves reflecting on mistakes.
One of the great qualities of a teacher is an ability to reflect on mistakes made. The process sounds so simple, but it’s very difficult to do in practice. Lynda is a master at this and includes a section on mistakes in her blog.
Identify the mistake made in a very specific way. Detail exactly what lead to the undesired outcome.
Identify exactly what you’ll do to avoid this mistake in the future. Sometimes this is built into the above statement.
Optional: detail what you can do to make a more positive outcome when this type of mistake occurs.
An example that follows this formula from this recent blog post:
Mistake #4: Do not trim the base when the clay is too wet. Wait a day or two for it to become a lot more stiff, but not leather hard. Lesson learned: When the vase falls over and becomes lopsided, squish it so it looks like that was your intent.
My students have always loved moments when it looks like I’m struggling, when I make a mistake in coding, or make other mistakes in class. It’s always an excellent teachable moment. Learning how to identify those mistakes and fix them is really important, but it’s rarely something covered in the curriculum. Instructors think they look “stupid” for making mistakes when teaching. This isn’t true. It’s encouraging to students to know that the teacher doesn’t have superpowers. Everyone struggles sometimes. The difference is the teacher struggles less than the student.
Donald Miller of Storybrand: How to Strategically Lay Out an Effective Home Page
Great advice on how to lay out a home page, but so many people get hung up on the design details.
In about 30 minutes, I built out a template based on his description in his article: https://storybrand.softr.io/
And it’s a breeze to jump in and make changes with Softr, even if you don’t know the software.
This is an example of transferrance, one of the largest challenges in teaching technology. Miller wrote an amazing article with text descriptions of what the website should include. Softr has a great tool that reflects all of those descriptions. But putting these two things together is a bit more difficult for many people. By providing an example like this, the concepts become more tangible to learners.
Two approaches to teaching tech:
a. Teach the button-clicking in the tool
b. Teach problem-solving across tools
You need both to do well.
Obviously A is where the technology product thrives – these are the help files. This is also where lots of YouTube videos and commercial video (like LinkedIn Learning) tends to thrive. Teach me how to use this software, rather than teach me how to solve this problem.
A is also the technology bootcamps. Yes, they might teach JavaScript, but they’re really teaching copy/paste concepts. They are not thinking about big hairy problems and how to attack them.
B is much more difficult because it involves critical thinking, and sometimes your favorite tool isn’t the answer. This is of little interest to software manufacturers, because it’s rare that the software addresses a problem completely. (When it does, sometimes you’ll see this technique used.)
B tends to be where higher ed thrives. Without the economic necessity of talking about specific software packages, higher ed can talk about problems instead: how to think about problems, frameworks for addressing problems, identifying and evaluating potential solutions. Implementing those solutions tends to be assumed that you’ll learn on your own, at least at the graduate level. Some button-clicking courses happen at the undergrad level.
There’s very little B happening in the tech bootcamps. Bootcamps are more concerned that students know how to copy/paste JavaScript and debug. They aren’t concerned that students can think through a problem, identify a solution, and craft JavaScript to address it.
Some careers specialize in A, some in B. But you need both sides of this teaching to do well and to advance in your career.
Button-clicking help files vs. frameworks for thinking about problems that need solving. Transferrance here is difficult. It’s never self-evident.
Button-clicking is behaviorism, while frameworks are more constructivist or cognitivist
The right medium for presented material
Reverse classroom as a model for commercial courses (testing to enforce live segments)
Breaking materials into short chunks, along with practice problems
Encouraging help among students via discussion/comments
Sharing completed work and giving feedback using LBNT
Imposter Syndrome is an extreme form of underconfidence. Your life is one big error! If they found out how little you know, you wouldn’t be where you are now.
I have no training in psychology, but if I had to pick an opposite for Imposter Syndrome, I’d choose narcissism. You’re the best! You’re amazing! The world should recognize your brilliance!
In the tech world, Imposter Syndrome seems to infect younger women and older men. Younger women believe they know nothing because they just started their careers. Older men started to realize how little they knew when they just started their careers, and they believe they still know nothing now.
It seems to happen to conference speakers and workshop instructors. Why was I picked to teach this topic? What do I know? If I’m not comprehensive in this area, then clearly I know nothing.
But here’s the thing to know: no one has your life experience. You have a unique perspective on a topic and a unique way of presenting it.
The best way to overcome Imposter Syndrome when teaching is to stop thinking about your 4th grade teacher. (S)he was the teacher, a “sage on the stage.” You were the student, expected to absorb. Knowledge transfer went one-way only.
Instead, think of yourself as a coach, leading and guiding the group. You have some ideas that are important. However, you don’t have a lock on the perfect way to teach the topic for everyone. There’s value in having other people explain your material to each other. Some of your students have interesting perspective, ideas, and life connections to bring to your material. It’s all an important part of an excellent class.
How much does Imposter Syndrome affect you? Take the quiz.
Jakob Nielsen defines mental models from a UX perspective: “A mental model is what the user believes about the system at hand.”
James Clear, in a fantastic story about mental models, brings it back to its essence: “If all you have is a hammer, everything looks like a nail… When a certain worldview dominates your thinking, you’ll try to explain every problem you face through that worldview.”
When we look at web technologies, they are dominated by all kinds of mental models.
The new JavaScript programmers, those who came to the web in the last 5 years or so, believe that the web is JavaScript-first, with HTML and CSS as annoyances that never “work” correctly. Those who have been in the web field for over 10 years know you start with semantic HTML, layer on the CSS for styling, and use JavaScript sparingly. However, when we’ve taught the JavaScript-first model, we wind up with the modern day messes we see dominating the world of custom development.
One of the big advantages I bring to the technology space is a breadth of knowledge in many areas. I started with Dreamweaver and HTML, later bolting on CSS. I moved on to pushing content management systems to their limits. I learned in a time when we didn’t have a zillion command-line tools for managing files. I started working with CSS when there were no browser developer tools. All I had was the HTML and CSS from “view source.” I had to figure out what was broken on my own.
Now as I make the switch from teaching code to teaching no-code, there is so much I bring to this new world.
In non-pandemic times, I speak at a lot of conferences. While there, I attend talks.
There are two ways to look at every talk at a conference.
a. It is adding on to a topic or area that you already know well. As a CSS expert, any CSS talks usually fall in this category for me.
b. You know nothing about the topic, but you’ve heard about it peripherally and have some curiosity in this area. I’m not a JavaScript expert. However, I’m curious about what problems the latest JavaScript framework addresses. What are the advantages of React over Vue? Vue over React? Why do we need all of these frameworks anyway?
In the first 3-5 minutes of your talk, you can satisfy both of these audiences quickly and easily by grounding the audience in the technology you’re presenting.
Amazing! How do you do it?
“The technology I’m talking about today is Y. Y is {type of technology} that addresses ABC problems. It’s put out by JKL Corporation/open source project/whatever, under a DEF license. It requires GHI technologies to configure and run.” (describe dependencies, technology stack, or server configurations here)
“Y solves the following types of problems…”
“You may wonder why we need Y, when we already have X, which addresses the same problems. X and Y are indeed similar, so let’s compare their strengths and weaknesses.”
“Now let’s get into the meat of Y.” (Time to go geeky wild!!!)
This formula conveys all kinds of background information about your technology very quickly. In 5 minutes, as a geeky person fluent in web technologies, I’ve got all of the high-level details I need to decide if Y is any interest to me at all. That is an excellent talk already. Five stars!
What if you already know X? Well, in 5 minutes, you may still pick up a nugget you didn’t know before, or make a connection you hadn’t previously made. For example, when you look at strengths and weaknesses of various technologies, you may not have been able to articulate why you’re so excited about Y to your boss. Now you have the argument to do it.
By the way, the true experts in technology never mind these high level discussions or think less of you for giving them. Everyone must learn sometime. If you can explain a technology in 5 minutes, that’s mastery in action.
The next time you give a talk, internally at your company or externally at a conference, keep these points in mind.
You don’t have to be comprehensive in your presentation. You need to be memorable.
And being comprehensive means you’re not memorable.
Present so the audience learns and remembers, not like a specification. We can always look up the specification later.
Here it is, in four easy steps:
Statement of problem encountered; brief, high-level description of solution.
Let’s walk through an example together, with every item explained.
Now you try it. Here’s a similar issue with a small twist. How would you solve this?
Let’s walk through how I thought about this problem. Your answer may be slightly different, and that’s OK.
{while there are more problems, repeat the loop until all problems are addressed}
This can be molded into a conference variation, a video variation, or a classroom variation. The fundamental steps are the same.
I teach because I want to make the web a better place.
I want everyone to have a voice.
I don’t want anyone kept out by gatekeepers.
When I started in this industry, the gatekeepers were understanding files and folders, FTP, and syntax errors.
Those gatekeepers are still around, but there’s much more now: command lines; configuring the computer with more complicated technology to get around files, folders, and FTP; new kinds of syntax errors. Tech bros. Smugness. Dismissiveness of anyone not white, male, and no more than 33 years old. A belief that technology must be complicated and hurt to work.
Also: “Really? You’ve never heard of XYZ technology?” Deliver this line with a slight air of smugness and superiority. Follow that with, “I’d be happy to sit down with you and walk you through it,” again delivered in a very slightly condescending way, implying that you cannot figure out this information on your own and thank goodness there’s someone to help you.
So, time for the guide to help the other guides. Let’s build a list of teaching tips.
(As always, my world is front-end web development. These are observations made after watching conference speakers and attending workshops in my field.)
The motivation for teaching is often to get attention or get famous, show off their personal skills, gain fortune, or to try to be an early dominator in some obscure technology or another.
Notice how not one of those reasons is to help other people.
In other words, these prospective teachers want to be the hero, not a guide.
A hero is Batman. A guide is Alfred.
Where would Batman be without Alfred? Luke without Yoda? Cinderella without her fairy godmother?
The hero is the student. The student is slaying the demon of ignorance.
Your role is to help them by providing them the sword. They will take the skills you teach and wield them on a chaotic universe.