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.

• I can ground the problems that no-code tools solve in coding language. Or not.
• I can frame the problems no-coders encounter in the words of a model that speaks to them.
• Someone needs to teach HTML and CSS to those who will not use it professionally. Our current courses assume you have 27 different command line-based tools and make it look so difficult. But yet, we provide the “CSS editing box” for those who want to dump in their custom CSS. If you’re going to put CSS in that box, you have to know how to write it. And in some ways, this problem is more difficult than what the professionals face. Have you SEEN the crap that passes for HTML these days? Have you tried to override it?

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?

1. “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)

2. “Y solves the following types of problems…”

3. “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.”

4. “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:

1. Statement of problem encountered; brief, high-level description of solution.

2. Let’s walk through an example together, with every item explained.

3. Now you try it. Here’s a similar issue with a small twist. How would you solve this?

4. 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.