Oliver Francescatti’s Blog

A little background.  This 9 week class prepared us to build web applications with Ruby on Rails.  Ruby on Rails is a web application framework that runs on the Ruby programming language.  Ruby on Rails utilizes a software pattern called MVC (Model - View - Controller) that divides an application into 3 distinct components.  The Model, which represents the data, business rules, logic, and functions.  The View which represents the output of information.  And the Controller, which is what accepts the input and converts it into commands for the Model and View.  

The course is divided into 3 Phases, Phase one: Modeling, Phase 2: The Web(View/Controller), Phase 3: Ruby on Rails. Each phase took 3 weeks with a pass/fail assessment the third Thursday of each Phase.  We had weekend projects that were done in groups starting in Phase 2 and built a final project at the end of the course.  Each phase was further broken down into weeks where our focus was trained on a different aspect of web development.

In order to not give too much away about the program, I am going to give a 60,000 foot view of each of the weeks in Phase One  

To start, I love this quote by Martin Fowler.  

“Any fool can write code that a computer can understand, Good programmers write code that humans can understand.”

Week One - The Ruby Programming Language

Going in, I thought I was pretty well prepared for this.  I had been studying ruby for a few months and had worked through the books “Learn to Program”, “The Ruby Way” and “The Well Grounded Rubyist” prior to attending. Unfortunately, unless you are actually coding and working through complex challenges that really interest you, working through books can only take you so far.  I learned a lot but “Learn to Program” was probably the best for rudimentary knowledge due to the fact that part of the book is completing problems the author has laid out and explained.

Regardless, no matter what any of us in the program did to prepare (aside from having a computer science degree), not many of us were prepared for what we faced on a daily basis.  We had between 3 and 6 coding challenges for us every day that stretched our knowledge and built upon what we had learned the previous day.  Most of our challenges during this week revolved around logic and algorithms.

On top of all of those difficult challenges, there was another challenge to accept and embrace, “Pair Programming”.  I wasn’t prepared for this aspect at all.  I had been working by myself for the last 10 months gearing up for DBC.  It was a shock to the system to say the least. In the beginning, I had a hard time listening to the suggestions from other people, their critiques, and having my pair challenge my thought process.  I think it is an invaluable tool now, but It was difficult for the first couple of weeks.  There is also the interesting dynamic of explaining to your pair what you intend to do before you attempt to do it.  For some reason I found it to be much more difficult than it sounds

What I got out of this week.  A great appreciation for the ability to be able to break any challenge down into smaller, manageable pieces and build the solution up, thoughtfully and progressively, to completion.

Week Two - Object Oriented Design in Ruby

In the first week, all of our code was written as procedural programs.  A procedural program is where the computer reads your code like a page in a book.  It starts from the top of the ‘page’ and executes your code sequentially down the ‘page’ to the end of the program.  Starting Week 2 and throughout the rest of DBC we focused on Object Oriented Programming.  I am going to do my best to describe this, but just know that there are books that are hundreds of pages long dedicated to teaching this concept and that people have worked years to learn and hone these skills.  

Object Oriented Design requires the programmer to model their programs as a series of messages that are passed between objects.  Each object that is built controls specific data,  and behavior is built onto each of these objects in order to give other objects access to that data.  These behaviors contain messages (data) that are sent between objects.  A program can have any number of objects, and some objects will collaborate while others may be stand-alone.  The goal is to make all of these objects have as little dependency on each other as possible, so as to remain easily changeable and flexible, while still producing the required output.  

The challenges during this week were particularly difficult since the remainder of this course revolved on the fact that we grasped this concept.

What I got out of this week.  The week before I learned how to break a problem into smaller pieces.  This week I learned how to make pieces from different objects work together while making sure those pieces were portable and easy to adapt.

Week 3 - SQL and Database Relationships

SQL is a database language.  We learned SQL because virtually every application contains data.  This data is stored on database tables and depending on how much data you need or want in your application, you may have 1 table or 20.  Inputting data, storing data types, and managing the data is done with the SQL language.  Accessing that data is done through the SQL language and the relationships that have been put into place between the tables.  

Relationships are of 3 types, one-to-many, many-to-one, and many-to many.  Setting up the relationships between the tables and then accessing that data efficiently through those relationships is what we focused on.  Each day we were given new data in different formats. The object of our challenges were to build the tables, build the relationships to access the data on those tables, and then access that data in an efficient and logical manner.  We were also introduced to ActiveRecord, which is a query interface that works in conjunction with the SQL language.

What I got out of this week.  The data your application uses and gathers is incredibly important.  If your tables and relationships are not set up correctly from the start, it is not an easy task to modify those tables after the fact without risking the loss of data.  Planning is key.  My grandfather used to say, “Measure twice, cut once.”

The Assessment

I found this assessment very difficult.  It was broken into 2 parts.  The first part was the actual assessment and the second part was a code review by an instructor.   We had 4 or 5 challenges that were vaguely worded, meaning that there was a lot of room for interpretation.  I must admit, after reading through the assessment, I kind of freaked out a little.  On top of the fact that the questions were hard, I was wearing noise canceling headphones while listening to a Sigur Ros Pandora station hoping it would calm me down and help me concentrate.  Not a good move.  The silence combined with the music was unnerving.  I was in my own little world.  Strangely, I found out that it is possible to be too focused.  I had no idea that other people were asking questions and having trouble like I was.  I took the headphones out as soon as I figured out what I was doing to myself and I was much better.  Apparently I did pretty well on the assessment.  

The code review.  This is the very first time I had had someone with a critical eye look over my code and openly challenge my thought process and assumptions. Ego check.  It is structured so that the instructor would ask you about your code and why you wrote it in the way that you did.  They asked some pretty difficult questions and expected concise, intelligent answers.

So I have been asked quite a bit “how was that ‘thing’ you went to?”.  I figured this would be a great place to let everyone know

First of all, that ‘thing’ was Dev Bootcamp.  Im going to use DBC going forward.

While sitting out front of the office with the rest of my cohort (strangers at that point) the very first morning waiting to be let in, I remember thinking to myself and reflecting, “How hard could this possibly be?  I have worked and or subjected myself to some pretty challenging and pressure filled environments”.  I was thinking of 3 examples in particular.

I worked as an arb clerk at the Chicago Board of Trade for 3 years.  Have you seen videos of the trading pits where those guys are flashing crazy hand signals to each other at an incredible rate of speed?  That was me.  And those hand signals are usually for orders worth millions of dollars.  If I misinterpreted one of those signals I would lose my job instantaneously.

I did the GoRuck Challenge.  I remembered being in Millennium Park at 11:45 pm on March 16th.  Standing in front of a backpack full of 40 pounds of bricks that I would not be able to put down for 12 hours, while hiking 16+ miles, and having a military special forces member screw with us.  One challenge in particular stood out.  Carrying a 1500 pound, slippery, soaking wet log with my team from the intersection of Clark and Diversey to Fullerton and the Lake (approximately 1.5 miles).  Only one way to get it done.  Teamwork.

The first few months at my last job.  For 3 months, I was on call 24/7 coordinating and testing hardware and software installations remotely through a third party contractor.

I thought I was prepared.  haha.  Hindsight is 20/20

Suffice it to say, DBC was like nothing I have ever done before.  It was a combination of all 3 of those experiences and then some.  I am going to do my best to give you a run-down of what it is about, some of the important things we did, and what I got out of it.

Our first day we were thrown in the deep end and were provided the 2 central tenets of DBC

The 2 components to this education / experience are - Technical Knowledge and Self-Awareness / Empathy

The Technical Knowledge

This was eloquently put to us in the form of a lecture by Mike, one of the greatest teachers I have ever had.  He drew the picture below.

The comfort zone, is where most of us operate on a daily basis.  Its the location of the skills and abilities familiar to us, that we have proficiency in, and are comfortable doing.

The panic zone is where we don't want to be.  These are activities that are so difficult and so far out of our reach that we get anxious and don’t even know where to start.  Over the 9 weeks at DBC, we learned techniques to back ourselves out of the panic zone if and when we got there.

The learning zone is where the skills and abilities are just out of our reach.  They are neither so far away that we panic and are frozen, nor so close that they are easy.

Mike explained to us that we wanted to be in the learning zone but since things came at us so fast we would probably be on the edge of the learning and panic zone. I found myself on the border of the learning / panic zone most of the time.  I slowly got comfortable being there and became confident that I was able to absorb and apply the material.

Curriculum on the technical side -

We had daily coding challenges, individual and group projects, and assessments.

We were exposed to technologies and methodologies that would usually take months to learn and years to master.  We were expected to learn them in a day or so and show proficiency in a couple of days.  They say “DBC makes world class beginners” and they are not kidding.  I am by no means an expert in any of these but am confident in my ability to learn them and other concepts quickly and thoroughly.

Empathy and Self Awareness

This is the ability to communicate clearly and effectively, provide feedback, empathize, and be able to see the views of other engineers, clients, and customers.  

Curriculum on the emotional side

We had sessions called Engineering Empathy, Check In Groups, and were constantly giving and receiving feedback.  All of this amounted to a sort of sensitivity training on steroids.  From day one we were encouraged to “drink the Kool-Aid” and not to fight the process but to trust it and let it happen.  I accepted the fact that we were going to get crushed both physically and mentally, I had no idea I was in for this too. These sessions and experiences gave us a safe places to blow off some steam and were greatly needed and appreciated since we were all on high alert from the first day.  I liken it to one of those wind up sirens, like the tornado sirens that wind up to a crescendo and after you stop winding them they have to dissipate their energy for a while before they go silent again.  Well, day one we were wound up to full throttle and kept wound up like that for 9 weeks.  The energy is still dissipating and it has almost been a month.  haha

Now this all may sound kind of far fetched and I was a little apprehensive myself.  I am a little ‘rough around the edges’, I was NEVER vulnerable and I always thought a man should never show his emotions or talk about anything that was bothering him.  I considered it weak and wanted nothing to do with it.  I would not have been able to surrender to the process and own my part in it so adeptly had it not been for a defining moment in my life.

Earlier in the summer I was fortunate enough to watch a TED talk called "The Power of Vulnerability" by a woman named Brene Brown.  The talk was compelling and I decided to read 2 of her books, “The Gifts of Imperfection” and “Daring Greatly”.  These 2 books have changed my life.  By reading these books I realized that it wasn’t weak to show your emotions, it was empowering.  In order to live life fully you have to put yourself out there.  Show your pain, show your happiness, show your weaknesses.  I embraced the fact that I needed to change and more importantly, I wanted to change and become a better man.  This wound up being a pivotal moment in my life and turned out to be an important component to my experience at DBC and I am incredibly grateful that I read them.

I had intended for this post to be more about the technical challenges we all faced but I think it would be better to explain the day to day pressures, expectations, and personal growth.  I will post about the technical challenges later.  

For now I will explain a normal day at DBC.

Our days were very structured - hence the “bootcamp’ in the name.

The gong (yes, there is a gong) is rung at 8 am sharp and we are given 5 minutes of general updates about the space, any visitors or speakers for the day, and announcements from fellow boots.

The first day we were told that phones and laptops are to be put away so as not to be distracted.  That needed to be said exactly once, because as soon as we were thrown into the deep end 5 minutes later, we all understood what was expected of us and that there was no question that there wasn’t going to be any time for e-mail or texting.

Tuesday / Thursday we had Yoga from 8-9 am.  We were only required to do this for the first 3 weeks but could continue throughout our time at DBC if we wanted.  I dropped out as soon as I was able because I felt my time was better spent starting the new daily challenges or working on something from the previous day I had not been able to finish.

Wednesdays we had Engineering Empathy 8-9 am.  This was taught to help us learn empathy and recognize our Id, Ego, and Superego.  Very interesting stuff.  These seminars were only for the first 3 weeks.  I wish they would have continued for the duration of our stay.  Dave Hoover (one of the founders of DBC) set the tone our first ‘EE’ session opening up to us with some incredibly powerful insights and admissions.  That was the moment I decided to “drink the Kool-Aid”.  It helped that Dave reminded me a ton of my brother.  He is quiet, introverted, introspective, incredibly smart, and sensitive.  I admire both of them a great deal.  Now, I wasn’t any good at expressing these feelings, although I don’t think that was the point, I thought the important part was that I was trying and putting myself out there.  Talking about my vulnerabilities and insecurities was incredibly unnerving but I felt better being able to talk about them and started to appreciate how it helped me. These sessions really glued the cohort together so that these type of conversations just kind of happened going forward.  I was going through some issues while at DBC and this really helped me feel comfortable opening up and talking to my fellow classmates.  Its kind of weird thinking back and knowing I would normally have held all of this in.  This blog is a direct result of this experience.  

Friday we had ‘Check In Groups’ from 8-9 am.  These were done in groups of around 15 students from other cohorts and teachers.  We had the same group every week.  We had 2 minutes to open up and tell everyone how we felt and what was going on with us, anything goes.  I really enjoyed these.  These sessions were pretty much the only time we had contact with people from the other cohorts, unless they were helping us out.  That sounds weird considering we were all jammed into that small space but we were just so busy all the time there was really no time for screwing around.  

Assessment Days - 3rd Thursday of each phase.  At the end of the first and second phase we had assessments.  These were the gatekeeper to the next phase.  These were VERY difficult and VERY stressful.  They are done individually.  They were designed for 2 reasons - to simulate a job interview coding challenge and to stretch your knowledge and test that you had grasped what had been taught the previous 2.5 weeks and could continue to the next phase.  We had 3 hours, from 8:15 am until 11:15 am to complete them.  The space was normally very loud with either a lecture going on and or the drone of all of the pairs talking amongst themselves but on assessment days it was like a funeral parlor.  Thinking about it always brings me back to that scene in “Walk the Line” when someone says to Johnny about his clothes, “and what’s with the black, its depressing.  It looks like you’re going to a funeral.” and Johnny retorts “Well maybe I am”.  haha.  That was the feeling those days, and I know i wasn't alone.  I know I sound dramatic but each of those days could have been your last.  Normally you would be able to repeat with the cohort behind you. That wasn't an option with us.  We were the last cohort of the year and if we failed the assessment would have to wait until January to repeat.  More stress.  After the assessment, we were assigned a teacher and a time after lunch that day.  During this time, we had to go over our code with the instructor and explain to them why we had done things the way we did and answer any questions they may have.

We would then normally have a lecture for about an hour in the morning covering what we had done the prior day.

After the lecture, it was then time to take care of business.  The daily coding challenges.  These were always difficult.  Some days we would have 2, and some days we would have 6.  We would pair up and log into the DBC website where our challenges for the day were located.

Before you knew it the lunch gong would be rung at 11:30.  I went to the gym for what I say was 20 minutes but was probably more like a half hour and picked up my lunch, went back to DBC and continued to work while I ate.  This was supposed to be a time to decompress but I found I was constantly wound up.   Lunch time turned into free time to research how you could do something better or how to complete something you were working on.

The end of lunch gong was rung at 1 pm.  We normally had 5 minutes of announcements and updates

Then off to another lecture for an hour or so.

After the lecture we got back to working on our challenges with our pairs.

The end of day gong was rung at 5 pm.  Most of the teachers and staff would go home.  The rest of us continued to work.  I would usually either eat leftovers from lunch or run downstairs to grab something quick to eat from subway, I know, its disgusting and I am embarrassed. Depending on where we were in our core challenges and how confident I was feeling about the material we had covered that day, I either continued to pair or “broke up” to work on something myself.

I left every day at around 9pm.

Final Observations and Words of Wisdom

If you are a caveman like I used to be, buy or rent "The Gifts of Imperfection" and "Daring Greatly" by Brene Brown, and actually read them.  I came in so much better prepared with that knowledge under my belt.

This program is no joke.  Seriously.  There is a disclaimer on the F.A.Q. page of their website stating “Don't even think about committing to anything else. If you have a job, quit or take time off. If you're in a relationship, send them a variation of our personal apology letter - Dear boss/friends/family, I'm training at Dev Bootcamp for the next 9 weeks, learning to be like Neo. See you on the other side. I love you and I'm sorry.”  Every word of this is true.

You will find out who really cares about you and who really has your best interests at heart.  These people will be the ones that believe in you and make sure you have the time, space and support to do what you have to do to get through this.  These people will understand that time with you during these 9 weeks will be very limited and precious, and as a result, treat it as such.  These people will enjoy the time you are able to spend with them and will not ask you to sacrifice any part of your schooling for them.  Trust your gut, and cut people out if they are becoming a problem.

Remember, these 9 weeks are about you.  There is nothing selfish about it.  You will not have any bandwidth left over to handle anything else.  Trust me.

This environment is a pressure cooker.  Just try to relax and enjoy the ride. 

You will never have enough time to complete everything.  Don't worry about it.  Make sure you grasp the big concepts and move on.  Do NOT go down the ‘Rabbit Hole’.  Time boxing is key.

You will wind up working on things even when you are not there. Sometimes its a good thing, sometimes it isn’t.  It is unavoidable.  You will find yourself thinking about code, working on code, and refactoring code in your head in the weirdest places.  On the walk to school or on the way home, on the train, in bed, in the shower, at the gym.  It was summed up perfectly by someone in my very first check-in group session.  They were in Phase 3 and said that they had started to dream about code.  I thought that was a little crazy, kinda cool and pretty funny.  It wound up happening to me too.  haha

Believe in yourself.  I had a pretty bad case of impostor syndrome and didn't feel like I was in a position to help anyone, yet when I asked an instructor he told me that I was one of the better positioned students.  Helping people helps you as much as it helps them.  Everyone can help someone.  Do it.

I hope this post helps future boots or gives my friends and family that I neglected during the time I spent at DBC an idea about why I disappeared and what I was doing.  If you feel that someone may benefit from reading this post, please forward it to them.  If you have any questions, feel free to email me.

So, this is the first time I have ever posted anything (aside from an Amazon review, haha) on line.  This is a pretty weird feeling but I'm gonna go with it.  I have never been a user of "the facebook" or "the twitter" and the only reason that I have either of those is because we needed them for Dev Bootcamp.  

I plan on posting about things I am studying, interested in, and working on but I figured I should give anyone that reads this an idea of who I am and how I got here.

I am also going to say here that I am setting a goal for myself to post at least 1 time per week.  Accountability, right?

I have spent the better part of the last 5 years working in the tech field.  I knew I loved technology but didn't know what exactly I wanted to do.  One of my favorite sayings is "If you don't step forward, you will always be in the same place".   So I decided to step forward in the "general direction" in which I knew I was going.   I was thinking that by trying different things, I could at least figure out what I didn't want to do and hopefully find what I was looking for in the process.  

I started out with hardware/software support, getting certified as a Dell Certified System Expert in the process on a LOT of hardware.  I figured out that I hate driving.

I found what I thought was a dream job, working for a start-up.  I have always been incredibly dedicated, loyal, and focused and thought my ability to put in crazy hours and "prove myself" on a daily basis were the perfect combination for success.  I was wrong.  I wound up supporting a system that was in dire need of an overhaul.

I learned a couple of VERY valuable lessons here.  

1.  I really enjoy programming.

2.  I want to write well crafted, tested, simple, and maintainable code.

3.  Where you work and who you work for are actually important.  Huh, go figure.  All of the lunches and fancy offices don't mean a thing unless you are working with people you enjoy.  Another favorite quote of mine, "putting whipped-cream on horse-shit doesn't make it any good" said by one of the guys I caddied for when I was 12.   

4.  I want to work on projects that are engaging, inspiring, and meaningful.  

5.  I want to work for a company that promotes learning, cooperation and camaraderie while providing guidance and support. 

In late 2012 the web started to grab my attention.  Websites were starting to do some really cool things, but I had no idea how to start learning about them.

I read an article about Dev Bootcamp in Wired (http://www.wired.com/wiredenterprise/2013/01/lawyer-turned-coder/ ) and knew that was my calling.  I was a General Contractor prior to all of this and have always been drawn toward building things.

I applied and was told I needed to be more knowledgeable about the various technologies before I would be considered a good candidate.  I was pissed and I wanted to go ASAP but realized that it wasn't going to be as easy as just wanting to go.  

Challenge accepted.   

Time to dig in again, but this time with a single minded focus.  I felt there was light at the end of the tunnel and I had finally figured out what I was meant to do.  There were a lot of things I needed to learn before I could be successful and I committed myself to learning them.  I searched the web for an outline of the technologies needed and possible order in which to learn them.  One day I came across a similar program called The Flatiron School and stumbled onto their pre-work website (http://prework.flatironschool.com/web-development/ ).  As soon as I saw this page, I knew that was the plan.  

Needless to say, there was a lot to do.  I started knocking items off that list, slowly but surely, every evening after work and most weekend days.  I started to get it and it was exciting.  When I got about 3/4 of the way through it was mid June and I contacted Dev Bootcamp again to re-apply.  This time I got in and I decided to go to the final cohort of the year, Oct - December.

Crunch time.  I realized that I had 3 months to complete the Advanced HTML/CSS course I was taking at "The Starter League", the Flatiron pre-work, the Dev Bootcamp pre-work, and some self guided goals of working through "The Ruby Way" and "The Well Grounded Rubyist". Haha.  I know what you're thinking and yea, I'm kind of ambitious.  This was a lot of work but I knew I was capable of it and wound up getting a little help.  

The start-up I was working for had been imploding slowly for about a year and I wound up getting laid off at the beginning of August.  It was perfect timing.  I was able to dedicate 10-12 hours a day to studying and preparing myself for the experience that was going to shape the rest of my life.   These 2 months were by no means easy but they laid the groundwork for having to work 12-14 hours a day at Dev Bootcamp.  

Side note - Our final project at Dev Bootcamp was the epitome of all 5 of the valuable lessons I learned above.

It's a crazy world.  I realize now that if I had been admitted and gone in January, I would've washed out of Dev Bootcamp for sure.  I am thinking my next post is going to be about the Dev Bootcamp experience.  Hope you enjoyed this one, if you did, let me know.