How 201 Created Teaches Ember.js

In the first half of 2017 I spent a lot of time preparing training materials for introductory and intermediate Ember.js courses. Now that 201 Created has given those training courses a few times I’d like to share how we approach teaching software in general and Ember.js in particular.

Our team at 201 Created is composed of Ember contributors and community leaders. I’m also happy to say it’s composed of individuals with varied background and experiences teaching and learning in different environments. Members of our team have taught programming to middle school kids, college students, and adult professionals.

Together we had run several small workshops, but working together to assemble the materials for a multi-day training has been a new experience for us. We created two courses: A course for beginners with some JavaScript but no Ember experience and an intermediate course for developers already familiar with Ember.

Methodology & Course Structure

We kept in mind several best practices from educators during our preparation.

The Dreyfus model of skill acquisition. The Dreyfus model proposes that learners move through distinct stages of learning. For example a novice relies heavily on “rigid adherence to taught rules or plans” while a proficient learner leans on maxims but adapts them to a given situation. As a learner advances through different stages of learning, the teaching methodology for a topic must change with them.

Learning styles of individuals vary. Everyone learns in a different way. In a class of 5-20 developers, we feel the best approach to reach everyone is to present information a number of ways. Repetition is important for retaining knowledge, so lessons shared in multiple styles remain valuable.

Peak-end rule. How people remember an event (positive/negative, value of the event) tends to be over-colored by their memory of the last thing they did. Every day of a training we make an effort to end on a high point. Especially with beginners, we want to build confidence as much as we want to grow skills.

Introducing Ember to Beginners

In our estimation, developers just learning a complex stack like Ember can be characterized by these four points:

• Rule oriented: They require basic and firm rules before they can build any of their own mental models. They are more focused on “how” to do something than “why”.
• Lacking context: Beginning developers regard everything as being equally important. They have little context for what everyday development in an Ember app is like.
• Task oriented: Learners are not yet prepared to plan their own solutions. Instead they focus on small, incremental tasks that occur in isolation. They don’t yet have a grasp of what is possible to base their planning on.
• Varied learning styles: Every developer learns differently, and a classroom will represent a mix of needs.

With that audience in mind, we introduce lessons from four perspectives:

• Topics are introduced in a traditional lecture format. Especially for topics like hook execution order, we lean on animation to teach visually.
• Lectures are interspersed with exercises. Before the group does an exercise, the instructor live-codes through it. In this segment our goal is to have the learners interact with the coding process. They suggest approaches for small challenges, get quizzed on syntax and usage, and guess what happens in hypothetical situations before seeing practical code. For these sessions to succeed, we constantly need to remind the more eager developers not to try and keep up on their own computers. Engaging learners in the live-coding process helps with that.
• To complete an exercise section, each developer completes the task on their own computer. To ensure everyone can keep up attendees are provided a document for each exercise with links to external resources, high-level goals, and detailed step-by-step instructions. For the developers who complete an exercise before anyone else (and there is always someone fast), a few advanced self-study questions and tasks are usually included.
• Finally most of the details we cover regarding API and syntax are provided in cheatsheets. These we make sure are printed out so people can look at something physical in addition to the exercise documents (which are digital) and the code on their computer.

The start and end of each day covers review in an interactive manner. At the beginning of the course we spend a fair amount of time reviewing (and introducing) modern JavaScript. JavaScript has changed so quickly in the past few years that many features existing in evergreen browsers are completely new to otherwise experienced developers.

Ember is known for its large API surface, and covering as much of that API surface as possible while still providing lessons that are synthesized is a challenge. Our approach is to teach the primitives of application architecture starting with routing and outlet hierarchy, moving to state and UI, and finally covering addons and Ember-Data. In parallel we introduce testing from the top down, starting with acceptance tests then component testing then unit testing.

We want the basic training to deliver on a feeling of success and creation, so each exercise builds on the same application. For each feature they must implement, learners are exposed to a challenge that requires use of a new Ember concept.

An example: For much of the course the route model hook is implemented by calling a utility function which generates stub content. Only once data can be edited in the application do we bring up persisting state between routes and introduce services. Building a bespoke data service is a good stepping stone to Ember-Data, and to learning the store as a synchronous identity map. Using Ember-Data to fetch data over XHR is brought in after learners have internalized what the store part of Ember-Data does in isolation.

We work to drive home the characteristics of Ember or SPA development that become problematic for beginners later on. We teach Ember controllers instead of preaching their avoidance, but also teach the concept of singleton controller state and its practical impact.

Our hunch is that providing a blend of resources (lecture, example, solo experimentation, documentation) helps learners with different styles each get what they need to grasp a concept. One measure of success is that thus far we’ve had zero learners go off the rails and need to reset their local codebase to proceed forward.

Building Intermediate Skills

Our expectations of an intermediate developer are a bit different. In the basic training, we expend a lot of effort protecting the ego of learners. We want them to pick up lessons and avoid discouragement. To attend an intermediate course, a developer should be ready for a challenge. Our goal is to push them outside their comfort zone (where they are probably already productive!) and evolve their knowledge instead of simply adding to it.

In the first part of this course we maintain the “build an app” structure of basic training, but with the alteration of it being more “complete the last 20% of an app”. Exercises come with less documentation than in basic training, and developers are expected to refresh some of their existing skills in a new context.

For the second half, we break the “build an app” mold. Instead of continuing to add features to the same application, we examine it for common flaws. These flaws become the basis for refactoring exercises and deeper dives into a topic. We cover: Testing and Mirage, build pipelines, promises and ember-concurrency, and component state encapsulation. Some of these lessons also break from live-coding followed by self-directed coding and instead become group problem solving. We encourage discussion about the upside and downside of a given solution or suggestion. At this level of learning the goal is to move from rules to maxims, and memorizing a solution is less valuable than understanding the context and problem space.

Softer Skills

Not all the lessons we’ve learned running these classes are related to teaching methodology or Ember. In fact several of the most important take-aways are pretty universal:

• Be respectful of your audience. Don’t call a room of people “guys”. We’ve had some incredibly diverse classrooms so far, and we find that incredibly inspiring.
• Respect the time of course attendees. Provide them a specific timeline of the day and make clear which parts of the schedule are fuzzy (like coffee breaks) and which ones are firm (like lunch or the end of the day). The structure will help everyone (you included) focus and better manage their time.
• Be sure to state what you expect from attendees, and also what you don’t expect. For example we like to remind attendees of the skills we anticipate them already bringing with them, and of the skills we don’t think they have yet. This is also a good time to share non-technical expectations: That people are there to learn and ask questions. We like to remind them of the mantras “You must try, then you must ask!” and “All questions are good questions”.
• We’ve found beginning learners are usually uncomfortable with their editor. Ideally for you, all attendees use the same editor so you can suggest workflow improvements and hotkeys throughout the course. We review editor basics as much as we review JavaScript basics.
• Highlight success with something physical. We bring a number of small things like stickers to our in-person trainings. Handing them out after tackling a hard exercise, a long day, or a correct answer always lights up faces in the room.

In the Twitter-driven echo chamber of JavaScript, its easy to let blinders fall over your eyes. A lot of the people we’ve taught Ember to this year don’t know much about other frameworks. They don’t follow the personalities arguing behind X-vs-Y or star repos on Github. They aren’t engineers from Lake Wobegon, and the don’t think of themselves that way.

…that’s the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children developers are above average.

- Lake Wobegon Web Development

The truth is that you don’t need to be above average to build great software. Everyone can challenge themselves to learn something new. And Ember, even modern JavaScript, remains very new.

The web and single-page app architecture remains cutting edge. It remains so over five years after Ember started its own approach on the challenge of writing web software. Most of the developers we’ve been introducing Ember to aren’t part of the bubble our company thrives in. They are ambitious developers who want a better, more productive way to create great experiences for their colleagues and customers.

We think they’re on the right track using Ember, and we’re happy to work hard to help them succeed.

Interested in learning more about our training courses? Visit 201-created.com/#training or email hello@201-created.com to contact our team. Thanks to Cory Forsyth and Jonathan Jackson for their feedback on this post.