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.

Specifically, this is a Ruby and Rails curriculum 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. It's likely that some of this applies in other settings/cities and to other courses, but your mileage may vary.

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.

A Few Comments on Immersive Teaching

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 keep the following in mind:

• 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
• Stay on top of accountability
• Tell students what's going on in their own minds
• Record lectures
• Gather student feedback often
• In lab time, 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 Do

Okay, back to it. If you chose 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
• Workshops - definitely 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 cross-class projects. 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

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

How Lecture Goes

Flow

• 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 Orientation

Breaks happen when breaks are needed. I usually don't like to go more than an hour without a break, but if I do, the break is longer.

You'll notice the "In-Class/Live-Coding" column in the spreadsheet...

Secondary Topics

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

What Happens Between Lectures

• Homework feedback
• Student assistance
• Use of TA