Originally published on crunchingnumbers.live

On Saturday, I presented Ember Octane to Austin Code Mentorship. I had been hesitant about organizing the workshop (what if no one shows up?). Thankfully, 6 people joined for the whole session, while some more stopped by. In one hour, we prototyped an e-commerce app where a user can view products before making a purchase decision.

This post primarily serves as a retro doc for myself, but also welcomes two audiences. If you are new to Ember and can follow a tutorial without guidance, you can skip to the end. There, you will find instructions and links to the base and finished projects. If you want to run a workshop or onboard a developer, what follows next is for you.

1. Before the Workshop

a. Target Your Audience

Before you form a workshop, I think it's good to decide what your goals are and what your target audience's goals may be. I was looking to demonstrate that Octane is easy to learn and use. I sought developers who want to build an app quickly—perhaps to build their resume or compete in a hackathon.

Austin Code Mentorship brings together a group of diverse people. Many are making a transition in career and seek advice and networking. There are also people who came to mentor, people who work in fields other than web development, people who just moved to Austin, and so on.

Interestingly, the people who joined my workshop already had experience with web development, quite likely more than I. I was able to get across the key ideas (routes, components, and API endpoints) easily and even briefly mention decorators, which I had meant to skip.

These people made a great audience and I was thankful to have them. Still, I would have liked a few bootcamp students join so that I could gauge how they find Octane and how I can better introduce Octane next time.

b. Make a Lesson Plan

In school, I didn't like lectures and seminars that had been put together without care. What probably made sense to a presenter in their mind because they had worked on the topic for some time didn't to me learning it for the first time. I suppose, as a result, I'm obsessed with planning and finding the simplest way to explain things.

Once I set my target audience and workshop time (1 hour, plus 30-minute buffer time), I wrote a list of concrete learning outcomes.

• Use Ember CLI to create your app
• Commit your code on GitHub
• See what Ember recommends for project structure
• Create routes and components
• Use Sass + Ember CSS Modules to localize a component's styles
• Use Ember Data + Mirage + Faker to mock API and manage data
• Use QUnit DOM + Ember Test Selectors + Mirage to write application tests
• Publish your app on Heroku

These outcomes helped me decide what app to build. Then, building the app ahead of time (rehearsing not just once, but a few times) helped me figure out what material to cut and how to simplify steps to stay on time.

c. Create Base Project

I had planned the first 10 minutes of the workshop for showing how to create an Ember app and install addons. Thanks to my coworker Sean's advice, I realized that this would make a terrible mistake.

A workshop is like a cooking show. No one's interested in learning how the ingredients had been prepared and the time that it will add to cooking. People want to see the food and know that they can make it in an hour too.

It's not just psychology. The time for several people to download packages on a shared network is greater than that for you alone at home. List all packages that you will use in package.json so that people can run npm install just once.

In addition, include all assets in the base project so that you don't break the flow during the workshop. For example, I snuck a file into the project so that I could give the illusion that one can easily build a factory with one-line attributes.

// File: /mirage/factories/product.js

import { Factory } from 'ember-cli-mirage';
import faker from 'faker';
import { generateBaseModel, randomInteger } from '../helpers/product';

export default Factory.extend({
    baseModel() {
        return generateBaseModel();
    },

    name() {
        return `${faker.commerce.productMaterial()} ${this.baseModel.name}`;
    },

    price() {
        return randomInteger(1, 100);
    },

    description() {
        return faker.lorem.sentences();
    },

    imageUrl() {
        return this.baseModel.imageUrl;
    },

    rating() {
        return 0.5 * randomInteger(1, 10);
    },

    seller() {
        return faker.company.companyName(0);
    }
});

2. During the Workshop

a. Meet Your Audience

In the beginning, while installations were going on, I surveyed the audience. Who are they? Why did they join my workshop? Have they used Ember before?

Asking these questions makes a good ice breaker and helps you show that you are interested in teaching and learning from your audience. You also get to see how you can adjust your lesson plan to better meet their needs.

b. Motivate the Problem

When introducing a new idea, I like to explain why it matters. Why do we use Mirage, Sass, and CSS Modules? Why do we make routes, models, and components? If we don't do this, what error will we see?

I prepare answers ahead of time so that they are easy to follow and get to the point.

c. Reinforce Learning

Active learning is one of the benefits of attending a workshop. Not only do participants get to listen to you talk, they also get to exercise their minds and work with their hands. Have steps that can be repeated: you take a step first and show how it's done, then ask participants to take it again and make their own examples.

3. After the Workshop

a. Summarize

This is something that I neglected to do. In one hour, the participants had been thrown many ideas. Leave a long-lasting impression by summarizing what they learned. This is also a good time to provide a few references if they want to learn more.

b. Hold Q&A

The participants likely have questions that your workshop didn't cover. Give them the chance to ask and answer with openness and authenticity.

I was asked, if I were to start over with another framework, which I would choose. I gave a warm chuckle, then responded I didn't have enough experience to decide on my own. Based on developers that I knew, I was interested in Vue due to similarity in templates and Svelte for having inspired Octane. I concluded by saying I wanted to learn more frameworks so that I could communicate better with developers who don't use Ember. I think my answer satisfied everyone.

c. Ask for Feedback

Before they leave, ask your participants for written, anonymous feedback so that you can improve your workshop and teaching skills.

I asked three questions and allowed space for a paragraph:

• What did you like about the workshop?
• What could have the presenter done better?
• What did you think of Ember Octane?

When I read reviews that confirmed my strengths, suggested giving more compare-and-contrasts with other frameworks (what makes Ember unique?), and expressed wanting to explore more before deciding what to think of Octane, I felt like what I did over the past week was worth it. 💞

4. Notes

Special thanks to my coworkers for letting me work on a lesson plan. To Sean Massa, in particular, for sharing his experiences with workshops.

Here are the instructions (the suggested time for a step is a lower bound, i.e. expect to take more time in the workshop), the base project (which lets you skip steps 1 and 2 in the instructions), and the completed project (in case the instructions aren't clear). Feel free to use them for learning and teaching Octane.

• Workshop Instructions (pdf)
• Base Project (GitHub)
• Completed Project (GitHub)