Menu

About the bootcamp

My wife’s cousin was recently rejected from a tech bootcamp. Out of curiosity, I asked what she was rejected based on, and it turns out the bootcamp actually interviews potential students before they accept them. Looking through the interview, I was surprised to see questions about things like higher-order functions, algorithms, and complex data structures. Wait though, isn’t the whole point of the bootcamp to teach people to program? Something seemed off here.

The more I thought about it the angrier it made me. These are paid bootcamps, and they get their tuition ($20k per student) largely based on the rates they advertise for job placement. Now you might be seeing the problem with these interviews - they are there so that the bootcamps can pre-screen for candidates that are already likely to be hired. That’s going to keep our industry comprised of more of the same.

I wanted to do something to help, and I figured one way to start might be to run my own bootcamp aimed at fixing these problems. Instead of letting everyone in, I thought it would be useful to create a space specifically for people that don’t usually have access to these opportunities. Of course it had to be free too, because charging so much is just another way to build inequality. My wife suggested the name “All Aboard Bootcamp” to capture the idea that we’d be welcoming new people into tech, while also sneaking in a Ruby on Rails reference. So I chose a schedule, wrote a tweet and went to sleep thinking maybe in the morning we’d have 10 signups.

I woke up the next morning to check the form and I realized just how much this problem resonated with people. Overnight just in my small extended network on Twitter, I had received 200 signups. Over the next few days that number went up to 381. I was pretty worried that I had advertised something I wouldn’t be able to deliver, but my wife (thanks again!) did some quick research on the average drop-off rates for online courses. It turns out only about 10% of people that start a course end up completing it. This explains a lot about all those Udemy tabs I have open.
I figured even if a majority of those people showed up on Day 1, we’d have a pretty good thing going and end the course with around 30 people. I thought I could handle the scale, but I still had to figure out exactly how I would pull this off.

Logistics

Working on this bootcamp has given me a tremendous appreciation for the logistics of running a medium to large sized class. I needed some tools to help with problems like:
Putting aside that I still didn’t have a syllabus, I decided to start solving with just what I would need for the first session. Zoom seemed like a natural fit for conferencing since most people have it installed already. So, I went to the pricing page. Most of us have never been to Zoom’s pricing page, but it turns out Zoom is really expensive! All of the features I wanted were wrapped up in the Webinar packages, but in the end I was able to make a few compromises and get things working; along with the bonus that if shared correctly, I could record the videos directly from Zoom with minimal editing.
I figured GitHub would be a great place for people to share their work, ask questions, and get feedback from me. It came with the added benefit that when the program wrapped up, I could transfer their repositories back to them as part of their profile & contributions. I created a free organization, and was able to configure the security settings in such a way that participants would have access to their own repository (and a few central repositories), but not be able to see each other’s. I even asked for access to the beta for GitHub Discussions so we could use GitHub to manage Q&A in a shared repository.
Now I had this Zoom invite and a registration form for the GitHub organization.. how was I going to share it with anyone? Knowing nothing about mass email delivery, the first option I came to was that maybe I could create a giant BCC list. I wrote up my email, hit send and quickly realized a few problems with that approach. First, most of my deliveries were rate-limited or sent to spam. Second, people who did get the email would respond on the chain and all of their emails would end up interspersed. This seems really obvious in reflection, but definitely still haunts me as people continue to reply on that original chain.
I ended up opting for an email marketing service. Originally, I was using Mailchimp until they flagged my account as “against their terms of service” after my first email, but I was able to quickly switch over to ConstantContact and keep rolling. The interface definitely feels less intuitive, but I had zero problems after switching.
I sent out an introduction email with the details for the webinars and how to set up calendar reminders. We were doing this!

Coding

Nearly every programming class I’ve seen avoided local development technical problems in one of three ways:
  1. They provide computers that are pre-configured with what you’ll need
  2. They are courses in JS and the student’s web browser is the runtime environment
  3. They spend a LOT of time dealing with differences with people’s individual computers
We were teaching Ruby virtually, so I knew that we were likely headed towards option 3 and in for a bit of hurt with setup. That isn’t great.. not only because it’s difficult and frustrating to actually do, but also because it’s a really bad introduction to programming. It’s like all those programming books that spend the first chapter telling you how to install the language. When someone is there and ready to learn, the last thing they want is to type in a bunch of stuff they don’t understand before they can even write a single line.
I came up with the idea to ask GitHub if they would let me try running the class on top of Codespaces, and thankfully they said yes. With Codespaces we’d be able to use the existing GitHub logins and get people into a consistent environment that also looked just like what they used during class. This way, when they saw me do something, they could be confident that they could do the same and expect similar results. Set up for a code space took <1 minute in most cases from clicking to create it, to be able to run Ruby code.
Realistically, I think Codespaces present an unparalleled opportunity in programming education. It’s a chance to skip past all of the confusing parts, give everyone the same resources, and focus on learning.
The Codespaces that people would be doing their work in were connected directly to GitHub repositories, which provided a natural space to review people’s work as we went. Students would develop in Codespaces and push their code into GitHub, where I could check out their branch (in Codespaces even) and give them direct help and feedback. Pretty cool!

First class

I spent a lot of the time between registration and the first class working on a presentation to go over the motivations for the course. This ended up being the only scripted part of the course, but I thought it was important to make people feel welcome and let them know I was there for them. In this session, I wanted to lay out how the course would be structured and what our expectations should be of each other.
The course would consist of 16 total sessions spread over 4 weeks. In that time, we’d learn Ruby, Rails, HTML, CSS, and a bit of JS. The goal wasn’t to be the most exhaustive course, but rather to learn in a way I’ve always found to be most effective - learning enough to make something, and guiding people towards the resources to expand out from there.
Each session would also be paired with an assignment covering what was taught that day. The assignments would push the candidates a bit out of their comfort zone, in an effort to really cement the things we had learned. Additionally, in order to keep people from falling too far behind, I’d start each class with a Q&A and then a review of the assignment from the previous day.
Nervously, I logged into the first webinar and watched as the Zoom filled up. We had 178 participants join the first session representing 18 different countries. People from all over the world had found the course, and that day we made a commitment to each other. For some people, that commitment brought them to class every day at 3AM their time, for others it meant working on assignments between multiple jobs.
These were hard-working, talented, dedicated people spending their time in search of joining our industry. I was heartened to see them immediately forming their own community for support, filling in the gaps in the tooling I had thrown together. By the end of the first day, the students had set up a Slack and created their own forms to organize student-run study hours. I was able to write to Slack support who graciously extended us a 90 day membership to maintain message history. This was going to work!

Syllabus

When trying to define a syllabus, I wanted to make sure I didn’t just teach a crash-course, but rather a course that built on itself each lesson without feeling overwhelming. Programming, especially for the web, is such a complex and intertwined topic it can often feel like a series of chicken-and-egg problems. Which and how many things do you need to know to really understand what a Class is?
To make my syllabus, I googled about 10 different course outlines from college courses looking to teach the technologies that I was aiming to teach. I deduplicated the lists to make one giant overwhelming list of everything involved. Then, I went through the list and crossed out a lot of it. I crossed out:
I was left with a relatively sane list of things, but the order still felt overwhelming. In order to make a more natural flowing course, I made a list for each topic of what other things I would need in order to teach that topic. Flattening that graph gave me what I consider to be the most straightforward and least daunting way to teach these topics.
And then… I stopped. Not because something was wrong but because I wanted to avoid a problem I’ve seen with previous courses. Laying out an entire day-by-day syllabus up front means that the course can’t be paced in accordance with how the class is responding. Instead, before each session I would draw a line with a reasonable amount of content for that day, and spend a few hours creating a more detailed list of how I would teach, what order, points I needed to make sure not to miss, and the details of that day’s assignment.
More stress? Sure, but the content every day was tailored to how the class responded. Some topics went faster than I would have thought, some took more time, and that worked perfectly fine with how I was writing the content.

Special presenters

Every Tuesday and Thursday we had what we called “Talkie Days”. These were sections of class where I invited people from the industry in to speak. I am lucky to have an amazing group of friends and coworkers, and I asked 7 of them who happen to also be from under-represented backgrounds themselves to come speak with the students and share their own experiences. I tried to get a good distribution of different types of programming-related jobs. We were fortunate to be able to talk with:
In addition to being outstanding people who are each fantastic at their jobs, these sessions were very well received by the students. People in the class looked forward to the talkie days, and that was more than echoed by the thoughtful questions they asked (we always had more questions than time) and the comments they left afterward.

Each course

Every day, I would send out a reminder about an hour before we started with the Zoom link in case people had lost it. We covered the previous homework and then got into the content. About halfway through every session, I would promise not to teach anything new and just spend about 10 minutes answering questions so that people could take a break.
Early on I had been hearing requests for video recording. I figured the recordings would be useful for when people missed an individual class but what I didn’t predict is how much people would refer back to the videos between classes. I soon found that people were passing back and forth timestamped URLs for the videos with topics that others found tricky. What an amazing community. ♥️
At the end of the session, we’d go over the assignment for that day, and I’d continue to answer questions until there were no more. After the session was over, I’d upload the video to YouTube and then send out a recap email describing what we talked that day, linking to the assignment, listing resources and contact details for our special presenters, and linking to the homework for that day.
Before the next class, I personally reviewed every homework submission and sent feedback via Slack where appropriate. This was a lot of work, but I think it really helped people know that I believed in them, and that I was committed to helping them making it through. Sometimes these messages were just words of encouragement, sometimes a technical nudge in the right direction.
As expected, each day we saw less and less people attend. I’m happy we did the research up front, because it meant that I didn’t have to take the departures to heart. Life happens, and it resulted in some drop-off. I am a nerd though, so of course I tracked the drop-off over time:

Final project

For the final project, I decided I wanted to do something a bit different from most bootcamps. Instead of just sending students off on their own with a large project, I wanted to be able to guide people as they went. It was important to keep people from getting lost or discouraged, but also to set the right level of expectations for people as they went and to make sure they were properly challenging themselves.
I would act as a sort of “project manager” for a project and area that they would choose. Students had to write a project proposal which was approved by me, and then a series of 3 check-ins, each of which included code, an update on their progress, and instructions for running their app.
I put together a long document on how the project would work. It went over what the expectations were, our schedule, some guidelines to guide people to work on something they cared about, and advice on how to push themselves in new directions to expand their knowledge.
We saw some really amazing projects! Here too we saw fall-off each week, but were able to finish out the course with 36 strong final projects which we presented on a 3 hour long call. It was a nice celebration of how far we had come. We spent nearly 3 more hours that night just talking and reflecting.

RailsConf

Throughout this course, I got a lot of messages from participants and others offering to support me financially for my time. I really like money but it didn’t feel right to take it, so instead I started thinking of how I might be able to take the money and contribute something back to the students.
I had the idea to ask people willing to support me to instead purchase tickets to RailsConf for the students. Through the generosity of a bunch of really kind people, and in coordination with Ruby Central, we were able to buy 15 full-price tickets to RailsConf. In most cases where they were both open to it, I was even able to connect the student with their ticket sponsor. We created some new connections, and the students really helped share the love by describing their experiences, opportunities, and favorite sessions.

Phew!

In reading all of this you might get the impression that this was a lot of work, and that’s definitely true. I spent multiple hours each day even outside of the course preparing and giving feedback. Hell, I probably spent an hour a day just answering emails! Every bit of that time was worth it.
I could not have asked for a kinder, more dedicated group of people to work with on this bootcamp. I’ve created relationships that will last, and I’m already hearing back from people nearly weekly about the interviews and jobs they are taking.
This website represents our results. I’ve published here the entire set of videos, all of the assignments, videos of each of the final projects, as well as pages where you can contact and follow up with each of the students who decided to have themselves represented here on the site. I hope you’ll take some time to look through our content, and consider passing on some names to your recruiting department. I can tell you first hand, the people in this course have put in the time and effort involved in learning, and are ready to be a significant part of your organization.
My other hope with publishing this content is that this write-up, the sessions, and the details on what went into making this course might inspire others to run their own version of the bootcamp (a few of you have already reached out, thank you!). I’m more than happy to talk to anyone willing to do that. It’s a lot of work, but diversity is important to the future of our industry. Additionally, it’s just the right thing to do. Providing opportunities for everyone helps to level the playing field in tech, but it also makes sure that we can built products with a broader set of people represented.
Thank you one last time to everyone that supported the course, supported the students, shared the posts, helped with logistics, gave us tooling, designed this website, helped give students help via chat, sent encouraging messages, or believed in themselves enough to give this class a shot. I appreciate you.

Need to get in touch? Contact

[email protected] or @seejohnrun.