UPDATE: I've revised this post for 2023! If you'd like to read the updated version, it's available on my blog: https://isaaclyman.com/blog/posts/junior-developers/

Let me tell you the story of a very successful company that made a very big, dumb decision.

We don't hire junior developers or interns...if you don't get a puppy, you don't have to clean up its messes.

~ Netflix

I'm flabbergasted that some corporate schmuck figured out a way to cast puppies in a negative light and people kept listening. I mean, puppies are the purest beings on planet Earth. Literally made out of playtime and fur. Bright spots in a lonely world. But I digress.

A lot of companies have followed suit with a "we only hire seniors" strategy. When asked why, they'll offer responses like:

• We don't have the time or resources to hire junior developers; we're moving too quickly.
• The company can afford senior developers, so there's no need to hire juniors.
• We can't afford to make mistakes at this point. The stakes are too high.
• Our organization gives a lot of autonomy to its employees. We aren't set up for the kind of hand-holding that juniors need.
• We want to get our base software product in place before we hire anyone inexperienced.

The implication here is that junior developers are a liability, something that a company takes on out of a sense of duty or because of an ailing budget. And the implication of that is, well, maybe other companies can afford to do corporate charity projects and substandard work, but we sure can't.

By the way, there are over 100,000 tech companies in the US, and I've never heard one single CEO say "our mistakes don't matter a lot" or "we need a way to spend some of this loose cash we've got sitting around." So, all you "senior developer only" outfits, whatever shortcut you think you're taking, whatever system you think you're cheating, the reality is that you've hallucinated the entire thing. There's no competitive advantage to shutting out juniors. And you've outed yourself as a poorly-managed company.

The way you hire and treat junior developers is a valuable proxy measure for the health of your organization, your product line, and your internal culture. Senior developers know this. And if that isn't compelling enough, hiring a fair balance of junior developers is a smart financial decision as well.

Preventing messes

If you refuse to hire junior developers because they make "messes," you're sending a strong and unintended message about your company culture: no mistakes allowed. You're painting yourself as the company that fires somebody every time a server goes down. Regardless of how much you pay, nobody wants to work in an environment where job security is touch-and-go. And trying to initimidate developers into making less mistakes spreads a culture of fear and initimidation, which is disastrous for mental health and productivity.

You might argue that this attitude encourages developers to be cautious and implement processes that guard against error: automated testing, QA, failovers, access protection, and reversible code changes, to name a few. But this theory is entirely backwards. If company guidelines encourage the use of failsafes like these and the company provides the time and resources for developers to implement them, the "no mistakes allowed" culture isn't necessary or valuable; most issues will be caught long before they reach production. And every developer, junior and senior, thrives in an environment where strong development processes protect them from worst-case scenarios.

What about the errors that make it past every layer of prevention you've put in place? Think of them as valuable opportunities to shore up your defenses. Junior developers, admittedly, usually uncover these opportunities sooner than senior developers. So the only question is, do you want to debug your process sooner or do you want to debug it later? "Never" is not a choice, as any experienced developer will tell you. If something can go wrong, eventually it will. No amount of experience can prevent human error.

Naturally, you'll need a few senior development and ops leaders to lay the groundwork and set precedents for an error-resistant development cycle. Nobody's saying you should only hire junior developers. But if you truly have a workplace that cares about mistakes--that is, a workplace where mistakes are caught early and often--junior developers will fit right in. And developers of all levels will enjoy higher job satisfaction, since error resistance liberates them to build great software (instead of constant firefighting) and protects their nights and weekends.

Saving money

According to Indeed, a Junior Software Engineer makes an average salary of $55,394, while a Senior Software Engineer makes an average salary of $117,374. A Senior costs more than two times as much as a Junior.

The cost is often justified. Senior developers are expected to be more productive than junior developers. That's not the whole story, though, and thoughtlessly writing it off as the cost of doing business is both lazy and expensive.

Not all application code requires years of experience to write, or even to write well. Every program includes "glue code" that connects various inputs and outputs in a mundane way. It doesn't matter a lot who writes it. You can pay someone $28 an hour to do it, or you can pay someone $59 an hour to do it. Either way it will come out about the same. If you only hire seniors, you're paying a premium for a great deal of entry-level work.

Code also varies significantly from application to application, and familiarity is a key factor in productivity. In most cases, a junior developer with six months of experience on a team will be more effective than a senior developer who just signed on, for no other reason than familiarity with the domain.

The aforementioned glue code and domain-specific code account for at least half of all development work. What remains is code that truly demands and benefits from the expertise of a senior developer. And even for this code, a junior developer can do outstanding work if they have access to sufficient educational resources and the guidance of an experienced mentor.

For these reasons, a pairing of one junior and one senior developer is generally equivalent to two senior developers, and comes at less than 75% of the total cost. If your goal is maximum productivity for minimal expense, this junior/senior pair should be the fundamental molecule of your organization.

As an aside, one factor that's impossible to account for in these numbers is the widespread tendency of senior developers to debate about topics that end up being trivial--such as algorithms, microsecond optimizations, and code style. If an organization hires only seniors and doesn't have a rock-solid decision-making process in place, hundreds of payroll hours can be lost to these arguments. Junior developers rarely have this kind of problem.

Building careers

If you don't hire junior developers, another message you're sending is that you don't know how career progression works.

Again, this isn't about corporate citizenship or "doing your part" in the tech community. This is about making your company a decent place to work so that developers will join your company and stay long enough to make an impact.

I've heard a few developers say "I'm done changing job titles. I just want to be a senior developer forever." However, I've never heard one say "I hope I never get a pay raise or learn something new or get recognized for my achievements ever again." And, inconveniently, the resources necessary to sustain ambitious ladder-climbers and complacent but passionate senior developers are about the same. You need ways to measure and recognize a job well done, plentiful educational resources, and a variety of projects young and old in your development pipeline. You need to create a sense of progress, even for those few who don't want a promotion.

But don't get stuck on those folks. They're a minority. Most people in tech aren't planning on being senior developers for 40 years straight. We dream of being software architects, team leads, CTOs, and founders. And a company that advertises its blatant disinterest in career progression is going to rank dead last on our list of prospective employers.

One of the most impressive things a developer can hear as they walk into a job interview is, "Hi, I'm a team lead, I've worked here for eight years and I joined the company as an intern." Impressive and very rare. That person is intensely valuable to the company--they know the product line in and out, they've seen code from every project within a 100-yard radius, and they've worked alongside everyone in the organization. They can innovate within that company in a way that very few can. And the company is earning inestimable dividends on that person's work because they figured out how to keep them interested for eight years--about one tenth of their life expectancy. That's a sign of success for the company's culture. It marks a workplace where morale is high, good work is recognized, and interesting projects are waiting around every corner.

Saying "we don't hire juniors," on the other hand, is an open admission that your company isn't prepared to be part of someone's career. It essentially advertises stagnancy: the company expects experienced and talented developers to join the company and contribute indefinitely while getting nothing but a paycheck for their efforts. Some might be willing to do that, but you'll never see their best work.

If your company is truly committed to career growth, on the other hand, an arbitrary restriction against junior developers only serves to shrink your hiring pipeline and shorten the possible tenure of your employees.

Making great software

Junior developers have several unique traits that their more experienced colleagues have usually lost. One of these is blind optimism. Another is a willingness to follow. But perhaps the most valuable trait juniors bring to the table is their lack of baggage. Senior developers have seen technologies come and go, projects fail, teams dissolve into infighting, and all the other trappings of the technology sector. They build up strong opinions and often overgeneralize, assuming that what worked (or didn't) for one team or one project must be equally effective for another. And this can manifest as a reluctance to learn the nuances of a new problem space.

Sometimes a project manager's job is to say "I know that didn't work there, but maybe it will work here." And a junior developer is usually the best person to test that theory--they can build a proof-of-concept or a prototype without bringing along any of the biases that senior developers have built up over the years. As a junior developer I frequently took on this kind of work, trying out new tools and technologies, rebuilding things in a different way, proving out ideas that everyone else had judged too quickly. I often discovered better ways to build and the company's software was materially better as a result. There were cases where page load time improved by an order of magnitude; multiple pages were condensed into one, saving weeks of future maintenance; or the company was able to rule out insufficient technologies that could have led to a lot of wasted time. The benefits provided by a clean slate and a fresh perspective are impossible to ignore.

Many companies can get away with putting a bunch of senior developers in a room and letting them fight through to a consensus over how to solve problems and build things. But adding a few juniors to the mix, developers whose time you can afford to spend on one-off experiments and wild ideas, will turn up surprising improvements to your products.

When it comes to software quality, junior developers also do an important form of work that generally goes unappreciated: they place limits on the heady, overengineered code that their senior colleagues may be tempted to write.

If you replace "average or mediocre" in the above tweet with "junior," you can see how this works. A codebase is an abstract record of the way its contributors think critically. A healthy mix of junior and senior contributors creates opportunities for simplification, which makes features easier to build as time goes on.

In summary, the widespread "seniors only" attitude in tech undervalues junior developers. It's a detriment to everyone, especially the organizations that mistakenly think they can make things easier by shutting out inexperienced candidates. Although some of these companies have been financially successful, the waste of money and opportunities they've absorbed is likely massive.

If your company is ahead of the curve on this issue--if you know how to hire, train, and retain junior developers--you're reaping benefits I've only begun to describe here. Your company has lower turnover, higher diversity, and less overhead than the competition. Your software is less likely to break and more likely to delight. There are, of course, other factors at play. But a positive approach to junior developers is an important mark of a quality workplace for developers at every level.