Chris Nelson

It’s almost over. My six weeks teaching at Dev Bootcamp in Chicago are coming to a close. It’s an experience that I’m really grateful to have had. In many ways I feel like I’ve learned more than I’ve taught, and I’m okay with that.

My not-so-secret mission all along was to learn how Dev Bootcamp (DBC) works. As I said last post, I was inspired by a Dev Bootcamp graduate to investigate in person how they manage to help people go from not having programmed to web developer in a few intense weeks.

The first thing that’s abundantly clear: It’s not (just) about the instructors. Don’t get me wrong, the staff here are incredibly passionate and care deeply about helping students learn. I’ve been inspired to be here and see how they do it. But the reality is that the time we spend teaching in the traditional sense is a very small part of the day.

What really makes DBC happen is the environment they’ve created. The place is a hive of activity for at least 12 hours a day. There’s an energy in the air that’s impossible to put into words as 60ish people put everything they have into changing their lives. It’s also incredibly stressful — mostly for students, only occasionally for instructors. The amount of learning that people are doing is the educational equivalent of climbing Mount Everest.

Dev Bootcamp goes to great lengths to care for the students as they go through this process. They have a relationship with a counseling service that provides on-site counseling so students can sign up for a session and talk to someone without having to even leave DBC, let alone hassle with health insurance. Yoga is also a mandatory part of the program.

The focus on working together is also what makes DBC so different from a typical computer science curriculum. The Engineering Empathy segment is entirely about working and relating to people on your team as human beings. The segments are really emotionally powerful. I can’t talk details and words wouldn’t do it justice anyway.

I crashed the improv night for Phase 1, and this was one of the most fun things I did at DBC. They have a trained improv actor come and lead us in a series of exercises that build to a segment where we divide into four to five person groups and each do a scene together. The point is not so much the improv itself but teaching us how to get comfortable looking silly in front of one another.

It comes on the heels of the first group project the students do together. The students have just spent most of the weekend working together on some really challenging assignments, and it gets pretty tense. The improv night injects fun when it’s needed most and forces everyone to get comfortable with looking stupid in front of one another. There’s no point in avoiding this, so let’s embrace it. Definitely a lesson I can always stand to relearn.

I’ve taught the same phase, Phase 2, twice now. It’s really interesting teaching again with different instructors and students. The students from my first Phase 2 cohort are now in Phase 3 and graduate today, my last day. In a way I feel like I’m graduating with them. I’m really excited to see the final projects they come up with. The demo day and graduation are one of the absolute highlights of DBC.

The final projects are what the Phase 3 students build during their last eight days at DBC, and generally make extensive use of technologies we don’t teach them anything about at all! The emphasis on learning to learn is super obvious at this point. And really, that’s about the only skill we can give them that we can guarantee won’t become obsolete — the frameworks and languages we use now won’t be the ones we use in a few years. Having spent nearly 20 years at this now, I can tell you this from experience. Heck, back in my day we had to walk 5 miles in the snow to even get to program computers. And it was uphill both ways.

Doug Alcorn

Concurrency is all the rage. When you have tons of data being shoved down your throat, you need all the help you can get. All the cool kids are turning to alternatives to try and keep up: node.js, clojure, erlang, elixir, Go. Popular thinking is that Ruby is too slow and won’t scale. But our favorite friend can support it very well.

In my talk at the 2014 Burlington Ruby Conference, I took a look at the actor pattern in Ruby with Celluloid and compared it to similar solutions in other languages.

Doug Alcorn - How to Consume Lots of Data - Burlington Ruby Conference 2014 from Burlington Ruby on Vimeo.

Guest Author

Today’s guest post is by Joshua Rose, one of the students in our first Introduction to Ruby on Rails training class:

There are things that we can’t change about ourselves. I was born a geek, always have been, always will be.

I hacked on BASIC as a kid, studied computer science for a few years at Miami University then landed my first programming job around 10 years ago doing visual basic. My career in the corporate world advanced from software developer to architect.

However, I was terribly unhappy with the state of my career. I felt like my work was more about meetings and politics than actually building great things.

I had heard about Ruby on Rails, but being a career long .NET programmer, my initial attempts to explore it had been filled with command lines and text editor wars.

I came to Gaslight’s Cincinnati Rails Day and met some amazing people. There is a welcoming atmosphere and energy in the local Ruby community. Being a career corporate programmer, I had never experienced such a community of passionate people before.

I didn’t know if I wanted to be a Rails programmer, but I knew I wanted to spend more time around these people. I was skeptical if enrolling in the Introduction to Ruby on Rails class would have any value for someone like me.

But I decided to sign up to spend 12 Saturdays with instructors Jim Anders and Ben Stafford, as well as a group of amazing students ranging from other career long developers to talented artists and manufacturing workers making time for the class around their 60 hour work weeks.

The course at Gaslight involved lectures from two very talented real world Rails developers, question and answer time, and pairing up with another student.

I can’t stress how valuable the course material was; learning computer science at the university level unfortunately doesn’t necessarily translate into real life. In the course, we all built an application together and were given the opportunity to build a passion project.

During the course, I learned not only techniques that could only be learned from Rails veterans, but I also learned the joy of helping out fellow classmates. Perhaps in the future I’ll be able to give back by teaching a round of courses.

Because of my time in the class, I had the opportunity to interview for a position at ChoreMonster, and now I work with instructor Ben Stafford every day. Gone are the days of sitting in meetings and dreading going to work. I work with some of the most creative people in the city and look forward to going to work every morning to build great things.