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.
- Future Experiments
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.
398 Participants registered to learn Ruby on Rails.
Breakdown of participants by year:
|Batch||Number of Participants|
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:
|Programme||Number of Participants|
Participants are predominately B.Tech, although it’s nice to see some participation from post-graduate courses.
- Breakdown of participants by department (top five):
|Department||Number of Participants|
|Computer Science and Engineering||80|
|Electronics and Communication Engineering||69|
|Mechanical Engineering Engineering||58|
|Electrical and Electronics Engineering||29|
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:
|Type||Number of Participants who prefer this type|
|Assignments and Projects||294|
|Books and Documentation||233|
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):
|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.
|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|
|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!
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.