Lessons from Ruby on Rails Bootcamp

Jan 26, 2021 by Abhishek Kumar

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.



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.


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.

Batch Number of Participants
2016 1
2017 30
2018 33
2019 105
2020 229

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.

Programme Number of Participants
B. Tech 337
M. Tech 41
Others 20

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

Department Number of Participants
Computer Science and Engineering 80
Information Technology 71
Electronics and Communication Engineering 69
Mechanical Engineering Engineering 58
Electrical and Electronics Engineering 29
Others 91

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.

Type Number of Participants who prefer this type
Video Tutorials 334
Assignments and Projects 294
Interactive Sessions 235
Books and Documentation 233

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

Number of Hours Number of Participants
< 2 hours 24
2 - 4 hours 158
4 - 6 hours 117
6 - 8 hours 70
> 8 hours 29

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.


Sessions Attendance

Session Number of Live Participants Microsoft Stream Views
Session 1 - Getting Started with Rails 179 121
Session 2 - Models 59 41
Session 3 - Controllers 31 25
Session 4 - Views 14 12

Assignment Submissions

Assignment Submissions
Session 0 - Ruby 10
Session 1 - Getting Started with Rails 27
Session 2 - Models 11
Session 3 - Controllers 8
Session 4 - Views 8
Session 5 - Associations and Validation 3

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.


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.