Home

Welcome! If you're reading this, let's assume that you're interested in teaching aspiring software developers. This wiki offers advice and structure on this topic, and it assumes that the material is being taught to adults in an immersive code school environment.

Although the lessons learned and approach to lecture are useful for teaching any technology, the specific topics and assignments are for Ruby/Ruby on Rails. This curriculum is being taught over 9 weeks of lecture at the Iron Yard campus in Durham, NC, and was developed by Mason F. Matthews. Lectures are assumed to last between 3 and 3.5 hours (including break time) and to occur 4 days per week.

Overview

From the widest point of view, here is the curriculum by week:

1. Ruby
2. OOP and Testing
3. Databases and Rails Models
4. APIs and Rails Controllers
5. HTML and Rails Views
6. Rails Features
7. JavaScript
8. Web App Patterns
9. Web App Patterns

However, this overview hides many layers of complexity. To dig one level deeper and see broad daily topics (plus the reasoning behind some of the ordering decisions, plus the assignments, challenges, and exercises for each day), read the detailed curriculum outline.

For an extreme level of detail, you have two options. If you prefer to read through the content linearly, explore the weekly course web pages. If you would rather see the curriculum in a matrix, take a look at the curriculum spreadsheet.

Lessons Learned

You're no doubt wondering what the heck all those columns and colors meant on the spreadsheet. Hold on to that question for a moment. Before we go over that, let's talk about a few teaching principles. There is, of course, much to say about teaching in general, teaching code, and how we learn as humans (we go into that on a different page). I leave baseline teaching concepts to other sources, though, and just want to hit on a few techniques and concepts that are critical in this setting (and which may not be immediately obvious).

When teaching adults in an immersive environment, please try to do the following:

• Use pre-work to your advantage
• Describe the future in advance
• Set clear objectives for student work (at least at first)
• Keep a board of lists
• Give students runway
• Assign pairs yourself
• Keep up with accountability
• Tell students what's going on in their own minds
• Record your lectures
• Gather student feedback often
• Be rigorous about one-on-ones
• Outside of lecture, make students ask questions in pairs

Of course, WAY more can be said than what I've outlined here. Just wanted to get us started.

What Students Have To Do

Okay, back to it. If you decided to look at the curriculum spreadsheet, you noticed that I ask the students to do many different activities. I break these down into the following categories:

• Challenges
• Exercises/Problems-of-the-day
• Assignments
• Projects
• Readings - mostly optional

This repository contains write-ups for all of these activities. They take a variety of forms, from discussion challenges to typical interview questions to test-heavy assignments to legacy re-writes to open-ended projets to cross-class undertakings. As mentioned above, a full list of these (tied with specific days of the curriculum) can be found here.

It's worth noting that many of the evening assignments and weekend projects have secondary purposes. I want students to get experience with real-world development practices, and the curriculum spreadsheet tracks these secondary purposes in the colored columns. The following development practices match with the corresponding colors:

• Pair Programming - (grey)
• Testing and TDD - (pink)
• Estimation - (orange)
• Data and Workflow Diagramming - (yellow)
• Working with Legacy Code - (green)
• Deployment to Heroku - (blue)

The Parts of a Lecture

The 3-3.5 hours of lecture are usually broken down as follows:

• 30-45 min - Homework Review
• 15-20 min - Challenge (during weeks 3-9)
• 15-40 min - Problem-of-the-Day (during weeks 1-5)
• 60-120 min - Instructor Lecture
• 5-10 min - Homework Kickoff

Breaks happen when breaks are needed. I don't like for the class to be "on" for more than 75 minutes without a break, but if it is, the eventual break is longer.

You'll also notice the "In-Class/Live-Coding" column in the spreadsheet. This is a set of reminders for good motivating problems. When teaching a new concept, it's ALWAYS best to start the class with a real problem to solve, and then to work through that problem as the motivation for the new technique. Sometimes it works out to be the same as the problem of the day, but sometimes it's a parallel problem in a different industry/domain. Regardless, thinking "oh, I'm going to teach about X today" without having a practical reason can reeeeeeally drag.

In addition to the coding curriculum topics, I work in at least one secondary topic per day. They are very diverse (and usually involve some degree of psychology), but the three basic categories are:

• Human Learning Principles
• Agile Practices
• git and GitHub Practices

My favorites were in the first category, and I think they really helped to streamline the course and enable students. Click on the link for more details.

TAs

I request that my TAs take on three daily documentation tasks:

• I ask them to gather student comfort-to-panic scores from every student every day.
• I ask them to write down any concepts or terms that I use while lecturing. I look back at this list after each lecture, and this helps me detect whether I've breezed over something unintentionally, or whether a serendipitous discussion that went over well should be intentionally included at that point in future curriculum.
• I ask them to take photos of the whiteboard when I have written a useful diagram or list that I'm about to erase. Videos of my screen while lecturing are great, but having the whiteboard diagrams as well makes a big difference. Someday we may have dual cameras like Confreaks, but for now...

The first two are recorded by the TA in a shared Google Spreadsheet. The photos are typically handed over by e-mail or Slack.

Grading

Finally, assignment review. I do look at every submission for every student every day, and I grade each one. I like to have students sit next to me as I grade so that they can hear all of my thoughts, and I end up sitting with each student about once every two days.

I also provide written comments on each submission, and make the generally useful comments available anonymously to all students on homework feedback pages.

My grading scale is in flux, but I expect that it will crystalize on the following options:

• 0 - didn't turn it in
• 1 - incomplete
• 2 - complete
• 3 - above expectations

I previously used a six point scale to grade student assignments, but this led to too much variation in grading between students and across time (typically because I had different moods at different times!).

I track homework grades in a homegrown system, but I do not currently give students access to their grades (because the inconsistency of my six-point scale made me nervous). This may change in the future. I use the grades, plus concept-to-lecture and concept-to-assignment maps to determine which concepts I have taught well and which I have not.

A video demo of this homegrown system can be found here, although the functionality of this system is also in flux.