Lessons from Ruby on Rails Bootcamp

Over January and February, I had the fortune of leading the IRIS Ruby on Rails bootcamp. It has been a rewarding experience for me, both personally and learning more about Rails.

Given my criticism of earlier editions of Bootcamp, it’s only fair to measure my outing with the same metrics. I have written down my lessons from the process and some experiments with the Bootcamp format.

1. Context
2. Demographics
3. Statistics
   1. Sessions Attendance
   2. Assignment Submissions
4. Lessons
   1. Don’t take it personally
   2. Plan out the complete Bootcamp
   3. Don’t break the momentum
   4. Involve more people in the process
   5. Have faith in people
5. Future Experiments
   1. Smaller, more frequent sessions
   2. Web Manager != Good teacher
   3. A Different Course Outline

Context

Before getting down to the statistics, it’s important to note that this year’s Bootcamp was markedly different from earlier editions because:

The first years were admitted to college in decemeber! We had to shift the Bootcamp to January, where it was conducted alongside college classes. They were also less experienced than before - from installing Linux (Linux Installations drives are no longer possible), using Git (Hacktober fest serves as an initiation to Git and Github) and programming constructs (we could no longer rely on C programming course to cover concepts like variables, functions).

Of course, all is not lost - thanks to Announcements module, we had a far greater reach than earlier editions (a total of 515 participants registered for RoR and Flutter Bootcamps). As the Bootcamp was first major “non-academic” event, the first years were eager to learn new things and prove their mettle.

Demographics

Thanks to the Forms module, we have the unique opportunity to dissect the participant demographics. Of course, not everyone who registers for the Bootcamp takes an active role - take this with a grain of salt.

• 398 Participants registered to learn Ruby on Rails.

• Breakdown of participants by year:

Interestingly, I didn’t expect so many participants in their third and final years. I had also hoped for greater participation from second years, but you can’t have everything.

• Breakdown by participants by program type:

Participants are predominately B.Tech, although it’s nice to see some participation from post-graduate courses.

• Breakdown of participants by department (top five):

The fourth most branch has twice the participants in the fifth most branch. We might increase participation dramatically if we reach out to “less interested” branches.

• We asked the participants their preferred methods of learning:

Sad to see “Books and Documentation” is the least preferred way to learn.

• We asked participants to quantify their commitment to Bootcamp (in hours per week):

Between two sessions per week (close to three hours), it might have been hard for participants unwilling to commit more hours to engage with the Bootcamp effectively.

Statistics

Sessions Attendance

Assignment Submissions

The number of submissions for Session 4 is artificially inflated as it was chosen as the qualifying criteria for Bootcamp interviews.

The numbers paint the same picture as any earlier edition of Bootcamp, participation gradually decays away - leaving behind a small core of dedicated learners.

However, I would like to make the case that any assignment submission improved over the earlier Bootcamps. Programming is a skill, and skills require practice - each submission represents some time spent practicing.

Lessons

Don’t take it personally

It’s hard to not the decline in participation personally - after all, it feels many students indepdendently decide you are boring and what you teach is unimportant. However, people often drop out because of mundane, unrelated reasons - it’s sticking with the Bootcamp that’s exceptional.

In any case, I have found it useful to move from uncontrollable variables (number of participants, number of submissions) to controllable variables - time spent preparing the sessions, code reviews and others.

Plan out the complete Bootcamp

While I had the general outline of “MVC, then M, then C and finally V” for the syllabus, I could have better planned out the later sessions of the Bootcamp in greater detail - especially the assignments and content. It was crucial, as the breakneck pace of “two sessions per week” was far too much for me to handle, and later sessions dipped in quality and insight.

Don’t break the momentum

Talking of pace, I had a difficult decision to make after the first session. As some participants were unable to install Rails, I could have delayed the second session and spent the weekend helping them out. Or, I could go ahead with the second session as planned.

In hindsight, I should have gone ahead with the second session - less than five participants bothered to show up for the installation and the week-and-half break, the sessions were far too long to retain participant’s interest.

Involve more people in the process

Between the preparing content, taking sessions, and reviewing submissions - I was spread too thin by the second half of Bootcamp. I could have involved more people in the process, taking their help in the sessions, mainly as I taught too fast and tried to cover too many things.

I rejected and rewrote the second and third sessions’ drafts because they were not in “my style”. “My style” was just one of the ways to approach the topics. I could have spent my time mentoring and molding the drafts instead.

Have faith in people

When there are two groups of people, it’s often implicitly viewed as an adversial relation. It’s open to question whether surprise tests have any value apart from preying on unprepared students.

Likewise, I too started to view the participants through an adversarial lens - if I don’t teach it, they will not learn it. The third session stretched an hour-long, and I still had authorization to cover.

However, my fears were unfounded as the participants have gone beyond the minimum requirements in the fourth session - learning to render PDFs, using toasts and carousels on their own!

Future Experiments

Smaller, more frequent sessions

Halfway across the Bootcamp, I came across RailsCasts - which takes on a small facet of web development on Rails in 20-30 minute screencast. A similar format might work for intermediate topics like authentication, authorization, using Bootstrap, and others.

Web Manager != Good teacher

While web managers have traditionally taught Bootcamp, I see no good reason why it has to be the case. I struggle with explaining complicated topics and am generally not a good public speaker, so why not let someone who is better-suited handle the job.

A Different Course Outline

While MVC is a great framework to organize the sessions conceptually, it’s hard to appreciate their utility as a novice.

Alternatively, we could follow The Odin Project’s lead on the order with approaching routing, controllers and views first followed by models. Participants gain confidence with building something immediately useful and demonstrable.