Books for software engineers and managers
The Junior Developer is dead.
While the world angrily points at hiring managers and recruiters with unreasonable expectations, I want to investigate less obvious and more insidious suspects.
Disclaimer: Half of the engineers I’ve hired in my managerial career fit the persona of Junior Developer and I would happily work with them again.
Our first suspect isn’t a person or organization. No, we first need to investigate an emerging system of incentives built around engineering productivity.
Engineering managers constantly feel pushed to increase the throughput of their team. That’s always been the case.
But in the last few years, the picture of high performing software teams has clarified thanks to books like Accelerate and The DevOps Handbook.
We now know the four key metrics of successful software teams:
When judged and incentivized by these performance metrics, engineering and hiring managers face a dilemma – do I hire a junior developer and accept decreased short-term productivity or do I require more experience in the hopes of maintaining productivity?
Now combine this decision with the knowledge that the junior developer will probably leave your company within 18 to 24 months. After 3-6 months of onboarding you’re likely to only get one year of productive work from a junior developer. That’s not enough for engineering managers to justify hiring a junior.
Verdict: The pursuit of productivity has low-level involvement in killing the junior developer. Within the performance framework that companies evaluate engineering managers against, the decision to avoid junior developers is both rational and pragmatic although short-sighted.
JavaScript first appeared in 1995, long before the death of the junior developer. So how did JavaScript contribute to the kill?
Well, it’s not the JavaScript language that Brendan Eich launched at Netscape that needs investigation. Rather, we should investigate JavaScript as a modern ecosystem.
Let’s start with the basic needs of engineering hiring managers. Hiring managers want engineers who can program. Candidates who can write code and solve business problems.
But modern JavaScript has changed the landscape of candidates. Too many junior level candidates today rely on haphazardly gluing together node modules and frontend frameworks.
When hiring managers read a résumé of someone that’s exploded from zero programming knowledge to JavaScript + Node + React + Redux + TypeScript + HTML + CSS in just a few months, what do we see?
Engineering managers see someone who is gluing frontend technologies together. Not programming.
These candidates produce semi-workable projects or small applications. However, there’s no indication that these junior level candidates can actually write code.
Leveraging technologies like React does help engineering teams improve productivity by lowering the skill level required for individual production.
However, to the hiring manager these technologies also raise suspicion about who among the candidates can actually program. And where doubt exists, engineering managers will err on the side of certainty, which means looking for experience.
Verdict: The emergence of JavaScript and corresponding ecosystem has created an unexpected and unfortunate situation where hiring managers don’t feel they can trust junior developers to actually write code.
About 10 years ago, UX design started hitting the mainstream. UX Designer became a trendy job title. Everyone started taking design more seriously.
Design became a field to grow within. You could remain a designer for life, receiving promotions and trying different specialties within the field.
The transition from designer to developer was no longer desirable or necessary to get things done. So what’s the problem?
These historical transitions from designer to developer happened internally within a company, creating a natural progression and safe environment for junior developers.
The designer was already a trusted person in your company. You knew their coding skills were junior but you didn’t care – they were a good employee so development managers were willing to train them and support their growth.
The rise of UX and increased specialization of development created barriers to entry that can feel insurmountable for junior level candidates.
Verdict: Low-level involvement and mostly applicable to frontend engineering roles
Code schools have done wonderful things by introducing more people to software development and diversifying the field of software engineering. However, code school advancements have come at a cost. What have code schools done to kill the junior developer?
When I post engineering job openings, my inbox floods with applications from code school graduates and soon to be graduates. These are ambitious and bright people, but the volume can feel overwhelming.
In effect, code schools have ruined any scarcity bias that exists, which says that humans view scarce things as more valuable and abundant things as less valuable.
Engineering managers don’t view code school graduates as an asset or opportunity. Rather, many engineering managers view code school candidates as a commodity. This feeling of abundance fundamentally ties back to the way code schools have over-saturated the junior developer market.
Follow the money. The more candidates that code school candidates accept and graduate, the more money they make. Code schools are incentivized by throughput.
To be fair, Hanlon’s razor applies – I don’t think code schools are lying about market demand. More likely they just grossly misunderstand the market and therefore overestimate demand.
The chief assumption code schools got wrong is that could prepare candidates to be productive members of software teams. In reality, code schools can only make you semi-productive but much burden remains on the company. Companies understand this, but do students?
You might first ask why code schools should be responsible for training engineering managers. But it’s not about responsibility to the hiring company or manager, it’s about responsibility to the students that code schools are promising a career to.
Most engineering managers don’t have the skill to hire, onboard, and train a junior developer. That’s particularly true for small to midsize companies.
In this manager skill gap lies an opportunity for code schools.
The résumés and cover letters I receive today look identical to those I received 2-3 years ago from code school candidates. The same projects, the same mile-long lists of technologies they know, and the same gratuitous résumé formats.
Verdict: Highly involved. Code schools have a tremendous amount of work ahead of them to revive the junior developer.
Software developer job titles evolve. But the junior title hasn’t evolved yet. Let’s look at the last 20ish years of developer job titles and how they also manifested for juniors:
Job Title | Corresponding Junior Title |
Programmer, Webmaster, etc. (pre-2000) | Junior Programmer |
Web Developer (2000-2015) | Junior Web Developer |
Software Developer (2000-2015) | Junior Software Developer |
Software Engineer (2015 – Present) | ??? |
We don’t use Junior Software Engineer on a widespread basis yet. In other words, juniors are stuck with Developer while the industry has moved onto Engineer.
Code schools are trying to change this by telling their graduates to call themselves Software Engineer. Every code school graduate that I see on LinkedIn or that applies to a job opening calls themselves a Software Engineer.
So the code school strategy is to avoid the naming problem and encourage graduates to skip the line. The downside is that hiring managers now compare these “Software Engineers” to other Software Engineers, which have years of experience.
Code school graduates express reasonable frustration – they were promised jobs, they applied to jobs, but now hiring managers expect them to have years of experience. That sucks. But perhaps there is a path forward that includes rebranding to Junior Software Engineer.
Verdict: Industry names have low-level involvement but do frame the way hiring managers compare and evaluate candidates.
Understanding the cause of failure in a complex system is frustrating. As humans, we like to point fingers at a person or component that failed. But that’s not how systems fail.
Complex systems fail in complex ways with multiple contributors acting rationally within their localized environment. Hiring managers acting rationally. Recruiters acting rationally. Code schools acting rationally. And junior developers acting rationally.
But the end result is failure for the Junior Developer. And we’re all to blame.