On Code Schools and the Plight of the Junior Developer

14 March 2016 · Estimated reading time: 8 minutes

Code schools and programming boot camps (sometimes derisively called “hack schools” or, more optimistically, “career accelerators”) seem to be proliferating like bunnies.

There are at least 4 that I’m aware of operating here in Portland, Oregon (there were 5, until Portland Code School abruptly shut down last October), and dozens more across the United States and around the world.

Note: I originally published this post on Medium.

They promise to take you from zero to developer in anywhere from a few weeks to a year. Most of these schools cost upwards of $1000/week for programs lasting usually between 4 and 12 weeks. A notable exception is Seattle’s Ada Developers Academy, which lasts a full year and is free if you make it through a rigorous application process.

Unlike a university degree program, which can take 2 to 4 years and cost 10s or even 100s of 1000s of dollars, a code school can seem like a good deal. Many of them even offer assistance finding internships and full-time jobs.

This all makes sense from an economics standpoint. Projections point to 1.4M tech jobs by 2020, but only 400,000 computer science graduates. Some see this gap as a $500B “opportunity,” one that code schools are rushing to fill.

But, like so many things, all is not sunshine and daisies. Many recent (and not so recent) graduates of code schools are having a tough time finding work in the industry or are finding themselves stuck in jobs where their talents are undervalued or environments where they are not given the necessary structure and opportunities to improve.

To be clear, this is not a “considered harmful” post. Far from it, I’m a supporter of code schools. I’ve spoken at and volunteered for Ada, Black Girls Code, PDX Code Guild, and Code Fellows.

Many graduates successfully make the transition from whatever previous job they were in to careers in programming. And, for those who don’t, there can be a variety of factors in play beyond what I address below.

What I want to explore is the effect on the industry of this sudden flood of less experienced programmers. Are there things we could and should be doing to better assimilate junior developers into our organizations?

Note: I use “junior developer” here, rather than something more specific such as “boot camp grad” because my points apply to anyone new to the industry. Yes, there has been pushback on the term, but it’s the best shorthand I’m aware of for someone in this position. Feel free to suggest a better shorthand. [I have since come to prefer the term “early career” over “junior” for a variety of reasons. –Andrew]

Winning now versus being competitive long term

To use a sportsball analogy, in professional (American) football, there are 2 approaches to building a competitive team. You can build through the draft or build through free agency.

Stick with me here because I think the comparison is apt.

Drafting players means taking them right out of university. They’ve played the game at a pretty high level (the college ranks consist of the 90,000 best of the 1.1M high school players), they’ve been around good coaches, etc. These rookies make a lot of money to chase a ball around a field, but for most of them it’s peanuts compared to players who have been in the league for a few years.

Most free agents, on the other hand, already have experience at the professional level. They are presumably among the 1,696 best players in the world (32 NFL teams × 53 players per team = 1,696). Their skills have been honed by excellent coaching and competing at the highest level. Because of this, they often command a premium when it comes time for a team to try to lure them from a rival.

Typically, a team that goes the free agent route is trying to win now, while a team that builds through the draft is focused on the long term. The latter invests in the development of these untested players with the hope that it will pay off years down the road.

Is it better to let that senior role sit open for 6 months or to fill it with someone who can start on Monday, but has less experience?

In my experience, most companies are trying to win now. They “only hire the best” and try to hire only senior developers who can “hit the ground running” on day 1. There are a few reasons for this.

1. There is a perception that senior developers are worth every penny because of how much more productive they are than less senior folks.
2. Everyone is maxed out and can’t imagine having to spend “extra” time bringing new people up to speed or “holding their hand” while they learn.
3. The way their technology is structured, everything seems like a difficult problem that only someone with X years of experience will be able to tackle.
4. They are on a short runway and really, truly can’t afford to invest in people without risking going out of business.

The problem is, there is a finite pool of senior people. And everyone wants them. Is it better to let that senior role sit open for 6 months or to fill it with someone who can start on Monday, but has less experience?

Going back to sportsball for a second, no team only drafts players or only signs free agents. They all do some combination of the two. The best teams are able to build through the draft, developing those players into solid contributors and sometimes stars, but also add a few, key, veteran free agents—both for their playing abilities as well as for the leadership they provide.

With so much work to be done and so many junior developers pouring out of code schools, tech organizations should consider doing the same. But, they need to have thought it through. They need to be intentional about how they are going to nurture and grow their junior developers. Otherwise, they’re setting people up to fail.

OK, fine. But how?

A lot of what it takes to have a high-performing development team that includes junior developers is the same as what it takes just to have a high-performing development team. This can be broken down into the following areas:

1. Structure — E.g., keep up-to-date, detailed, written documentation for things like how to set up your dev environment, how code reviews work, how to merge code, etc.; hold regular team meetings where members teach and learn from each other
2. Context — E.g., maintain a well-defined backlog of issues with clear done criteria; define how the work at hand fits into the larger goals for the product and of the organization; talk about idiomatic versus opinionated code; model the act of asking questions
3. Process — E.g., encourage pair programming and require code reviews (that are not hostile) so newer team members can learn from those with more experience and familiarity with the systems; implement automated testing so bugs are caught early and change can become routine

All of the above will benefit any development team while also laying the groundwork to help junior developers be more successful.

In addition, a nurturing tech organization needs engaged leads and managers who are willing and have the empathy to know how and when to provide the additional context or direction a junior developer might need.

Lastly, great development teams include those veterans who can and want to mentor the rookies. Some developers prefer to tick off their assigned tasks and go home. The best teams include ones who want to bring up the people around them.

Now what?

There are plenty of reasons a company might not want to hire junior developers. Doing so in a way that sets people up for success is hard. It means taking the time to sort out your own sh…tuff. It means laying groundwork that will make everyone more effective. It means building in extra capacity to bring people along (or saying “no” to a few things to create that space).

I personally know people who have successfully transitioned from non-technical jobs to careers in tech. I also know new developers who are struggling to find a job or are finding it difficult to learn and grow within their current engineering organization.

With so much demand for programmers, it would be foolish for organizations to ignore the 1000s of people coming out of code schools in favor of only hiring “the best.” With a bit of intention, we can create situations for many code school grads to be productive now and grow into solid contributors over time.

It can feel like a big ask with so many of us working under immense pressure to get the work out yesterday, but creating workplaces that have the capacity to support and grow junior developers will help you win now and keep you competitive over the long term.

❦

Many thanks to Robyn, Morgan, and Valerie for reviewing this post prior to publication.