7 things I learned from throwing a Rails Bootcamp

16 Jan 2013

Last week I threw an Intro to Ruby + Rails Bootcamp (event info). I specifically wanted it to be a “no programming experience required” event that would explain the essential Ruby + Rails basics in 7 hours. Here’s what I learned.

1. Doing a “no programming experience required” event is hard. I struggled to use terms that were not Object Oriented idioms. I would have been severely helped if I would have chosen key terms to use before I started speaking to rather than choosing vocab on the spot and defaulting to CSci lingo. (See #4 for more on this).

2. Next time, teach Frontend to Backened. I thought it would be good to cover Ruby objects and then explain how Rails provides a way to save and render Ruby objects. This was not a good idea. I recommend explaining Rails Views first, and then describing Rails Controllers and Models for a “no programming” experience required Rails intro course. I think Rails Views are easier to understand for the average beginner since ERB views are similar to HTML (which most people know of) and there’s a lot of learning inertia to overcome with controller and model concepts (ORM, HTTP requrest/response, Ruby class inheritance, etc). And generally, people want to quickly feel like their learning is helping them create a real world web app.

3. Not installing Rails on everyone’s machine was a good thing. The event did not try to help people setup a Rails env on their own machines. This simplified the event greatly compared to what would have been 4 hours of machine specific trouble shooting. IMO, it was better to invest in teaching Ruby and Rails basics rather than fighting windows and teaching Linux shell commands. Downside, people didn’t have a place to go practice Rails dev.

4. Hire an event coordinator. I hired 2 people to help with the event, a friend to critique my content and an event coordinator. It may sound like over kill, but it was totally worth it. I hosted the event because I want to be a world class communicator. The extra help freed me to focus on preparing up my talks and interacting with the people, not tedious event logistics (greeting at the door, chipotle run, where’s the bathroom?, etc).

5. Slides take a really LONG time to make. I planned for 12 hours of slide prep and it took 25 hours. I learned I am 3-4x times more productive if I physically write out my slide deck with code examples and then create slides. Definitely one of the one most valuable lessons from the experience.

6. Prepare connected events. 30 people showed up, and 20 stayed for the full 7 hours. People asked when the next event was and I didn’t have anything for them. Next time, have dates/times for following bootcamps. Better to do 3 events rather than 1 huge event.

7. Success = organize info + execute on details. Hosting the event was chaining together a hundred little baby steps from different contexts. Overall, I tried to keep event details in systems and not in my head so I could easily knock out small tasks.

The following tools helped, – email = communicate with people about details – google docs = schedule + confirmed event details – trello = helped me brainstorm content – pen and paper = helped me create slides – jekyll_and_hyde = how I did event slides – EventBrite = event registration