This is a post in our anniversary series 500 in 5. Check out our other posts in this series.

IS THE REST OF THE COUNTRY CATCHING UP TO NASHVILLE?

So why, from the very beginning in 2012, did NSS make a contrarian decision to have a six-month full-time bootcamp? When all the schools in all the cool, tech hot spot cities were launching with 9, and 10, and 12 week programs, were we just out of the loop down here in Nashville, or did we know/believe something they didn’t? And why today do we continue, along with a handful of other programs across the country, to feature a significantly longer full-time residential program than the majority of bootcamps?

Even more curious, why are the bootcamps in the rest of the country moving in our direction? Course Report released their 2017 Coding Bootcamp Market Size Study yesterday. One of their key findings is that the length of bootcamp programs is trending longer. They found that the average bootcamp program is now 14.1 weeks long against an average length last year of 12.9 weeks.

Back in late 2011 and early 2012, we asked ourselves and researched several questions as we were trying to design a sustainable business model for NSS and, in parallel, a curriculum for our proposed bootcamp program:

• How long does it take to train a career-ready software developer given students that start with no prior experience or training?
• What do employers want in junior developer candidates?
• What are the other emerging software bootcamps doing? Can we see things they are doing that we can borrow in Nashville?
• How much practical experience does a new software developer need to be productive in a work environment without a long internal training period or excessive hand-holding by more experienced developers?

To answer these questions, we relied on our personal experiences of learning to be developers, of managing engineering teams of various sizes and of hiring (and firing) dozens of software developers. More importantly we went to our market and asked the target customers of our startup, local employers, what their problem was and what it might take to solve it. Would appropriately trained junior developers meet any of their needs and what did “appropriately trained” mean to them.

We eventually boiled what we learned down to four major points. These learnings drove our decisions about both business model and program/curriculum design. Those four points are:

1. As Experienced Developers We Didn’t Believe 12 Weeks Was Enough

I have to admit that we started with a bias against programs as short as 10 to 12 weeks. This wasn’t a bias against learn-by-doing, immersive learning or against a vocationally-focused program. Quite the contrary. I personally had learned to become a professional software developer strictly through on-the-job training, mentoring and project work. Many of the crew that were supporting the investigation and design of a local coding program also were not academically trained computer scientists but developers that had learned through self-study and/or on the job.

If anything, we had a bias in favor of a vocational, hands-on, immersive program vs. the academic model. But we were still skeptical of the ability to push students with no prior coding training or experience from zero to hireable in 12 weeks or less. We were interested to see what the early programs were doing with the design of their programs, but we weren’t sure that such a short program would get the students we anticipated having in Nashville, students without prior coding experience, to the level that Nashville employers would find them hirable.

Given all of our questions, we decided that rather than design around solely our beliefs and biases, we’d better check with those who we would be asking to hire our students and see what they thought.

2. It’s What Employers Said They Wanted

During the second half of 2011 and early 2012 we talked to a lot of developers and hiring managers at a wide range of companies in Nashville. One focus of those conversations was around the knowledge/skills/experience that organizations would want to see in viable candidates for junior developer positions. We knew from other research and conversations that many organizations in Nashville were not regularly hiring junior developers at that time.

We hypothesized that in order to change hiring behaviors in favor of junior developers it would help to design our curriculum around what local employers felt they wanted to see in candidates. At least two curriculum options we envisioned didn’t really feel viable: a) a generic computer science focused curriculum or b) a bootcamp curriculum designed in startup heavy, tech industry hot spots. We hypothesized that if employers found generic compsci knowledge sufficient, there would already be more local hiring of juniors from local compsci programs and we weren’t really seeing that. And I believed from my own experience running software companies and/or engineering teams in tech/startup hot spots like California and Boston that the willingness in those markets to hire people from three month programs was not guaranteed to translate into a willingness to hire in a very different job and tech market like Nashville.

Our interviewing strongly confirmed our belief that a different type of bootcamp was needed for Nashville. We found strong agreement in the requirements we got from our interviews with the companies and hiring managers that had indicated an interest in, or at least a willingness to consider, interviewing and hiring junior software developers. We heard consistent feedback that in the local market hiring managers wanted candidates that had good exposure to “full stack” software development.

What did they mean by full stack software development?

In drilling deeper into what was meant by “full stack”, we found a desire for candidates with good depth of exposure to front-end web development, including HTML, CSS, real JavaScript depth plus libraries like jQuery, source code control/version control, testing/debugging, etc. In addition, “full stack” meant strong server-side knowledge, including one server-side language and its associated framework(s) and libraries plus native SQL, more source code control/version control, even more testing and test automation, object-oriented programming including patterns, etc.

The details varied from organization to organization but the overall picture was pretty clear: local employers were not particularly interested in the more limited topic coverage we were seeing in curricula from other early bootcamp programs. Nashville employers were also interested in very different skills and knowledge than would be developed in a compsci-focused program. We needed a curriculum suited to a job market not dominated by tech startups, but with a broader employer base including agencies, consulting companies, tech startups, more mature tech companies, and enterprise IT shops. And it would need to be longer than 10 to 12 weeks - the responses we got when we showed local hiring managers a couple of the 12 week program course outlines were very clear regarding skepticism about candidates from such programs.

Now, nobody said that six months is the correct length. But when we laid out various ways to try to satisfy as many as possible of the requirements we heard, it was pretty clear that six months was going to be the best compromise between length, depth, and affordability.

3. We Didn’t Believe you Could Compensate for Fewer Days with Longer Days

When we dug into how the early 10 to 12 week bootcamp programs were run, we realized that most of them seemed to be modeled on the startup accelerator model of very intensive, long weeks. Most startup accelerators back then lasted 12 to 14 weeks and assumed that the startup teams worked 70+ hour weeks. It seemed that early bootcamps were using the accelerator model to train developers to work in the startups coming out of the accelerators.

We didn’t believe that an immersive coding bootcamp was at all similar to a startup accelerator. Yes, both were intensive. But startup accelerators are not primarily learning environments where students are trying to master a cognitively challenging new craft. They are more like massively intensive “death march” project environments. You can load up on extra hours and work longer days in a project environment. But does that work for a learning environment?

We did not believe that from what we knew of cognitive science, learning, and mastering coding that 12 hour days would produce 100% more learning than an intensive/immersive six hour day. We believed, and still do, that there is a point of diminishing returns in learning after six or seven hours of immersive practice. Even experienced software engineers tend to see rapidly diminishing productivity after four to seven hours of continuous effort - and these are people who already know how to code. Why would we think that newbies, who are still trying to understand the how and why of coding, could maintain productivity while learning, which is generally cognitively more challenging than practicing an already understood craft?

4. It’s All About the Repetitions

Closely related to a couple of the points above is something we now understand much better than we did back in 2012. And that is the importance of staged repetition in learning, especially learning technical/math/science subjects such as software development. Intuitively we understood the idea, and it informed some of our thinking on topics like the two immediately above, but we didn’t have the language to explain why we believed what we believed. But we did believe that students learning to develop software need multiple iterations of coding exercises and multiple projects in order to start to develop sufficient mastery of the foundational skills of web development to be productive in a work environment.

Since 2012 we have done much more reading and study on the cognitive science associated with learning, in particular learning by adults and learning of technical subjects. We now have a better understanding of staged repetition as a critical learning strategy and the importance of building many opportunities for staged repetition into the design of courses. This is a fundamental concept of our curriculum design. There are only so many repetitions possible in 9 or 10 or 12 weeks. Our students simply have many more opportunities to practice with the concepts and tools we teach and each repetition helps deepen and strengthen their skills.

After five years of working with our students to help them go from raw noobs when it comes to coding to job-ready junior software developers, we’re clear on the value of having a longer immersive learning experience for our students. While we certainly acknowledge the great variability in natural aptitude between students, and recognize that some students need less time to reach job ready status than others, we think our students benefit from the extra time they get to work on more projects, practice on more exercises, and get exposed to a great breadth of topics and technologies. We’re confident that the six months that students give us (or 12 months for our part-time students) provides them with many more opportunities to apply the concepts and tools and skills we teach and gives them a combination of depth and breadth that better prepares them to become productive quickly in a work environment.