Developer Boot Camp – Part 2: What I learned & what I built at developer boot camp.
Editor’s Note: In October 2013, Felix Thea had been working at MediaMath for 4.5 years and was ready for a career transition. He informed his manager that he was resigning from his position as Product Manager in order to attend App Academy, where he would train to become a developer. MediaMath wasn’t about to let Felix go without a fight Instead of an outright resignation, MediaMath and Felix agreed that upon successful completion of the course, Felix would interview for a role on the UI & Apps Team. On January 27, 2014, after 12 weeks of intensive study, Felix rejoined MediaMath’s ranks. This time as developer on the Apps Team. This blog post is about his experience in App Academy, a 12-week developer boot camp in New York City.
A version of this post originally appeared on Felix’s personal blog.
Part 1: Why I chose to go to boot camp.
App Academy’s boot camp runs for 12 weeks, from 9am to 6pm each day. The curriculum is broken down like so:
- Weeks 1 and 2 – Ruby
- Week 3 – SQL and Active Record
- Weeks 4 and 5 – Ruby on Rails
- Weeks 8 and 9 – Work on final projects
- Weeks 10, 11 and 12 – Hiring boot camp (resume and github cleanup and interview prep)
I’ve been told that as long as you focus on learning the fundamentals of a language, it’s not that important which language you choose as your first.
I agree with this stance as long as the language does not have such a steep learning curve that a newcomer would become dejected and give up.
That’s why I think Ruby on Rails is a great start if you want to become a web developer. When you’re learning or doing something new the most important thing is to first get momentum. With Ruby on Rails, you can get something up relatively quick, point a domain to it, and show your friends “look what I made,” and, for me, that was extremely motivating and kept me in the game.
DAY TO DAY
Nearly every day involved pair programming. Pair programming is where you are randomly paired up with another student to code together. Partners are to discuss the problem and solution together, and then one partner would dictate and the other would type for 15 minutes at a time. At first we tackled small problems, then eventually worked our way up to full-day and sometimes multi-day projects.
The purpose behind pair programming is to help students learn by teaching. To teach effectively, I had to solidify my own understanding, and I would get instant feedback from my partner on whether I was teaching (thus understanding) effectively Pair programming also forced me to go at a slower, more methodical, pace rather than just diving in and coding blindly, without thinking about the problem and the possible solutions more thoroughly.
Most students, including myself, found pair programming challenging for the first week, because up until then we were mostly coding and learning in isolation. We would often take turns implementing our own solution rather than collaborating. Over time most of us got more comfortable. However, there were still some students that had trouble collaborating even towards the end of the course.
On most days we also had 1 to 1.5 hours of Q&A and a lecture, where the instructors would typically demo how to use some new concept we were learning.
WHAT DID I END UP BUILDING?
We were instructed to build a clone of an existing site for our final project (Facebook and Evernote were my class’ favorites to clone). This capstone project would be used as the example of all the knowledge and skills we learned, and it would be presented in our github for potential employers to evaluate. The reason why we were highly encouraged to create a clone of an existing site is so that a.) We didn’t have to spend precious time explaining to employers the functionality of our clone, and b.) We didn’t have to worry about UX.
I chose to build an Urban Dictionary clone for companies to create internal-only custom dictionaries of jargon for educating new and existing employees: Rampup Ready
My twist on the site is the ability to build curriculums. An employee can use the curriculum builder to search for words and definitions, drag and drop those definitions to include in the curriculum and produce a curriculum they can email to an employee. New employees can learn all the terms to be ramped up before their first day, and longer term employees can learn definitions they aren’t familiar with.
I want to keep on working on the app and begin testing it with startups to see if my web app is solving a real (and painful) problem. I’m still pretty embarrassed by the web app, because it’s not where I want it to be with regards to the features, design/UX, the code isn’t elegant, and there are still bugs. Like Reid Hoffman says: If you are not embarrassed by the first version of your product, you’ve launched too late.
If you own or work at a company, and think Rampup Ready is something your company is missing, I would love to chat with you.
Check back in next week for Part 3: Lessons learned from developer boot camp.