This is a thorough and honest review of the Destination Dev programming bootcamp. Hopefully it will spare others the negative experience I encountered.
I am a good case study for the ineffectiveness of this bootcamp because I brought 3 qualities which... Read More
a. Strong work ethic and discipline (the camp included 8-12 hour work days)
b. Logical/analytic/mathematical aptitude (I teach and tutor students in higher-level mathematics)
c. A very high level of motivation to learn: I traveled to another continent to attend this bootcamp. An unmotivated person would not spend thousands of dollars, leave the country, and put their entire life on hold for several months to do this. But I did.
I also work in education and have seen many talented educators in action, so I know good instruction when I see it (and I also know when it's severely lacking).
BASIC ASSUMPTIONS ABOUT A BOOTCAMP
I'll start with two very basic, uncontroversial assumptions about what a good coding bootcamp should be:
1. Since the vast majority of people learn a skill more effectively if they begin with someone directly showing them how to correctly practice that skill, a good coding bootcamp should involve quite a bit of direct instruction and guidance. In other words, it would not be realistic or effective to expect students to teach themselves such a highly technical skill as programming.
2. If you're going to charge people a large sum of money in exchange for teaching them a certain skill, you have an obligation to teach them that skill. A good coding bootcamp makes sure that ALL of its paying customers who put in the work leave with skills that put them in a position to get a job.
HOW DESTINATION DEV ACTUALLY OPERATED:
The program directors seemed to have good intentions. But good intentions don't teach someone how to program. The road to poorly designed bootcamps is paved with good intentions. There are 5 main reasons why Destination Dev failed to deliver what a good bootcamp should deliver:
A. Lack of direct guidance and instruction geared towards a bootcamp's main customer: someone who isn't an expert at coding
There's a lot of research in education comparing direct instruction (what we traditionally associate with education: a teacher showing students how to do something, then letting them practice doing it) with "discovery-based learning," which operates on the idea that students should primarily "discover" knowledge for themselves via exploration.
While discovery might have its place in some areas, research shows that it doesn't work best for programming or other detail-oriented, technical skills. In some cases, it can actually be quite dangerous (imagine a driver's ed program allowing students to "discover" the right way to drive, or a medical school having its would-be surgeons "explore" the right way to do surgery).
Yet Destination Dev seemed to rely on this very strategy as its predominant method of instruction.
The format included twice-daily lectures which were often unfocused and rambling, with little context, and a fast pace with an immense volume of information which no true beginner could hope to properly absorb. Often instructors would switch rapidly back and forth between terminals and text editors, adding code without explanation (and I took detailed, meticulous notes whenever I could, which--after the first few weeks--wasn't often, since I usually had no idea where their code was coming from, nor did they clarify with good explanations).
It was not uncommon for code to get messed up, at which point the teachers would waste class time debugging. I sometimes looked around the room to see other students apparently totally tuned out, some trying to Google the information for themselves.
Destination Dev lectures were begun by asking if anyone had questions on the prior day's material. I vividly recall one day that someone did have questions, only to be told that the instructor didn't actually have solutions available! What good does it do to ask for the right path if your tour guide doesn't actually have the map?
A good class focused on technical skills doesn't expect students to do what they've never been taught to do. For example, in a math class, a good math teacher first explains a formula to students and walks them through the problem-solving process with a few examples. Only after this does the teacher expect students to solve the problems themselves.
At Destination Dev, the lectures, which should and could have been devoted to teaching us how to actually code these types of projects, instead often just re-stated basic concepts (like the meaning of Big-O notation) which we were given to read about, but without actually showing us the starting points of how to solve problems.
We were then left for several hours to carry out difficult and often advanced projects (some were so difficult that only a few--and in one case, no one at all--of the whole class, managed to solve them).
We were also told about certain important CS concepts covered in technical job interviews, like sorting algorithms and data tree structures, but--sensing a theme yet?--never given a detailed demonstration for solving these problems. To this day I still don't know how to implement a binary search algorithm (how would I? No one at DestinationDev ever showed us in detail, step-by-step, like a good technical seminar should).
B. Lack of well-thought out remediation and methods for getting "unstuck"
Very early on I saw that this format was going to lead to a disastrous outcome for myself and several others (we did not arrive here with CS degrees or prior knowledge of other languages, as some students did, although even these sometimes struggled to keep pace).
I brought this to the instructor's attention, and the only remediation plan provided to me was to simply redo projects from earlier weeks which I had never been able to do (because we weren't shown how to do them).
Let's use the medical school analogy once more: "Bob, I know you've killed three patients on the operating table this past week, largely because we never showed you how to do the operation properly. What I want you to do is ignore that past failure rate and go jump into another operation. Even though you've filled the hospital's morgue with the results of your bad surgical technique, maybe this time will somehow be different."
Here's a great observation on getting unstuck, from the Firehose Project:
"There is nothing worse than getting stuck on a simple problem and losing all of your momentum. You need to have the ability to get “unstuck” as quickly as possible. It’s on your coding bootcamp to have the infrastructure in place to make sure this happens" (http://blog.thefirehoseproject.com/posts/9-ways-to-know-if-a-coding-bootcamp-worth-it/).
Destination Dev provides no apparent method for someone to get "unstuck" besides re-assigning the same projects you couldn't do the first time. Of course by this time you are now way behind the scheduled pace, and making no progress, which leads to frustration and poor learning outcomes.
I raised this concern, and the directors excused themselves by saying that this was the pilot program, they lacked enough resources to offer such remediation, and that perhaps if I had paid what amounted to an extra $10,000+ in tuition, I might have had a stronger claim to such helps. Imagine an instructor saying this: "We would've done our job to teach properly if you'd paid us more."
C. Disorganization, free-for-all format (including firing a teacher mid-course)
To give a sense of the disorganization, it was announced to us one day, more than halfway through the course, that Destination Dev had fired one of the teachers, since "it wasn't working out."
Not only does this implicitly acknowledge that the quality of instruction was lacking, but it's amazing that it took more than half the course to figure this out! (Incidentally, this fired teacher was the one who had been assigned to help several of us with the remediation plan mentioned above. Destination Dev's remediation plan was to provide us with a teacher who they later judged as unfit to teach).
I asked the program directors the following question, but never got a clear answer: Did you ever actually plan or discuss the proper way to teach people the skill you promised? There's a massive difference between knowing how to program and knowing how to teach other people to program.
D. Not delivering on outcomes
I did quite a bit of research before taking this course, and Destination Dev spoke of 3 specific outcomes which led me to sign up:
a. Although hard work would be necessary for success in this course, prior programming experience was not required for success.
b. One of the course goals was to have students completing functional apps (such as a Rails web application) by the course's end.
c. The ultimate goal of the course was to prepare students, in the founders' own words, for employment at "large technology companies" as well as "small start-ups."
As noted above, for severals students, none of these outcomes were delivered. There is no realistic sense in which the course was tailored to beginners. I was made aware that nearly a third of the class (!!) purchased some type of supplementary programming content while they were attending Destination Dev in order to remediate. Think about how astonishing that is: you travel to another country and pay thousands of dollars for someone to teach you to code, then feel compelled to buy extra stuff to teach yourself when you can't get the proper instruction from your course. This is like having to hire a second doctor to cure you of illnesses your primary physician inflicts on you.
That meant that some of us spent our time here simply trying to teach ourselves from the Internet, which we could have done at home, for free, and without wasting time and money.
As far as building projects for a portfolio, since the "diplomas" offered by Destination Dev are meaningless for your employment search, your projects are the only proof that you really learned something. Obviously if you got hopelessly lost in the first week, as several of us did, there was little chance to learn enough to put a portfolio-worthy app together, which means little change of employment at a reputable tech company.
E. Resistance to feedback and factual criticism
I brought all these concerns to the directors' attention, as they directed us to, and the replies I got were truly bizarre.
I was alternatively accused of lacking the aptitude for programming (meanwhile I still possess an email from a program director suggesting the opposite; apparently you only have aptitude until and unless you factually criticize, and then you can't code your way out of a paper bag ), complaining unreasonably given that this was their pilot program (reply: If you're not ready to offer a high-quality program, why would you start selling it to students?!), and, most incredibly, not putting in enough effort (though myself and other students would regularly stay up until 2 a.m. working on our code). The accusations change several times, but the sense I got was the same: if a student leaves the bootcamp without having learned what they were supposed to learn, it's always the student's fault (even when it isn't).
I can't recall a more obvious unwillingness to objectively and impartially accept criticism, even though Destination Dev directly requested our student feedback on the very first day. (Maybe this meant, "Only feedback that doesn't hurt our feelings"?). The impression given was that the biggest problem with our criticisms was not that they were correct and true (which I believe they were), but that such pointed feedback hurts feelings, and apparently hurt feelings are a far greater evil than wasting enormous amounts of student time and money.
I was genuinely astonished that professionals would behave this way, and almost completely absolve themselves of responsibility in favor of attacking a student's aptitude and work ethic. But that's actually what happened.
Laurence Bradford of LearnToCodeWithMe has a great observation on how a bootcamp should work: "You're giving the school a lot of money for three months worth of work. It's their job to make sure you understand the material" (http://learntocodewith.me/posts/coding-bootcamp-questions/).
Exactly. In my view, Destination Dev did not even come close to doing their job of making sure that we understood the material. For all of these reasons, I strongly advise you to look elsewhere if you want to attend a bootcamp.
Suggested resources (these were a big help to several of us in our efforts to self-teach):
Learn Ruby the Hard Way, by Zed Shaw
Excellent resource which teaches programming as it should be taught: without assuming prior knowledge, breaking it down for beginners, and drilling content through repetition until it is mastered, with each topic building on previously taught skills.
Free Code Camp
The Firehose Project
Another online bootcamp which offers a free prep course followed by the option of enrolling in the paid full course. The prep materials are great and walk students through the basics while allowing opportunity for practice to master the concepts.