Lessons From Accelerated Developer Education
Six weeks ago, our coding bootcamp welcomed its first class of sixteen budding Javascript developers. Since then, we've been teaching them full-stack web development at the fastest pace we can physically manage. It's been a wild ride, and we're writing to share our most interesting takeaways. We would love to hear more from members of the tech education community about their reactions to similar challenges or about challenges that they have run into that we can learn from.
(If this is the first you've heard of Hack Reactor, nice to meet you! if you're studying programming on your own, you should definitely apply. If you're interested in teaching programming to very driven and intelligent students, we're hiring for part and full-time positions. Email me directly at shawn@hackreactor.com.)
Breadth is harder than depth. Developers find it easier to tackle conceptually deep lessons (eg functional programming) than detail-rich frameworks (eg Backbone).
Hosted breakfasts are crucial. None of our other community-oriented efforts has done half as much to engender a sense of family.
The biggest threat to our students' success is self-doubt. It's not surprising that it sucks for a developer to feel like they're falling behind, or to wonder why they don't get something. It's completely shocking how devastating that mindset is to pragmatic tasks, like resolving bugs. In this state, a student's response to a bug shifts from "I wonder why that happened?" to "I wonder why I don't get this?" and big delays pile up.
An accidental experience with managing complexity became a pillar of our course. On days three and four, students built a simplified version of Twitter using a mess of jQuery, and it turns out that holding that much spaghetti code in your head causes physical pain. During our code review the next morning (when an instructor refactors student code on the projector), we discovered that our students had acquired an innate understanding of why they needed to make their code as simple as possible. This experience became a touchstone that we return to every week, and students spend about 25% of their time refactoring old code.
Burnout: not as big a deal as we thought. Given our coding boot camp's very intensive schedule (six days a week, 9a-8p), we closely monitored our developers for signs of impending burnout. This has proven totally unnecessary so far. They are challenged, but one-on-ones indicate that they're coming into class refreshed and happy, and some go so far as to gather for hack sessions on their lone day off.
Outlines. Our biggest challenge in building both lessons and projects has been to produce a coherent, complete outline that correctly anticipates the concepts that will need in-depth explanations or revisiting.
Our biggest win: real-world tools. We made an early decision to conduct nearly all classroom activities using real-world tools, which was an area of concern for us. When we discussed having students begin their first project by forking a git repo, or introducing testing in the first JS lesson, we were worried that it would hamper students' immediate progress. Ultimately, the decision pushed a lot of groundwork into our pre-course curriculum, and we had to set aggressive expectations and track student progress closely.
This paid off in spades. The standard developer workflow is part of our students' daily routine, and not the awkward afterthought that we're accustomed to seeing in newbie programmers.
We faced the same question when it came to lecturing. Although we've experimented with a variety of styles, we now prefer live coding in the console. Tailoring student questions into syntactically valid console statements invariably clarifies concepts better than the slideshows that we invested dozens of hours into.
In writing this post, we only found time to summarize our findings very briefly. We may expand on individual topics in upcoming posts, so be sure to let us know what you'd like to see discussed in greater depth.