Junior developers are junior developers: regardless of whether they've been coding since age eight, started in college and graduated with a CS degree, or bounced around odd jobs before doing a bootcamp, you can't let their code near production without substantial oversight from more senior developers. (I fit into the first bucket and it is frankly amazing to me that they let me touch a keyboard at all in my first two years in industry. I used to pronounce projects done which did not compile, as a result of "just one quick fix" on the last day.)
Engineering organizations either a) understand this fact and build teams around it, b) accept that their salary floor is now +/- $140k or so (in Silicon Valley), or c) whine incessantly about the engineering shortage.
Juniors write a lot of code. Often significant amounts for a company's products and services. They're the ones who are implementing all the decisions that seniors spend their time making in all their meetings.
Most senior engineers I've seen have most of their days filled with meetings with very little actual coding time.
The seniors are valuable, making decisions, coming up with solutions, building frameworks etc, but it's the juniors who then take that and run with it and build everything on top of it.
So while some will still code, it's far less than what the junior engineers are creating.
Yes they require some more training, and clear direction, but they are the ones actually creating and executing the vision of the company informed by the seniors.
What companies really want, like others have said, are senior engineers who are willing to accept a junior salary.
I think this is a sign of companies not knowing how to get useful work out of junior developers with only a few years of experience, much less fresh college graduates. This is an extremely challenging problem at small scales, and one that most companies simply aren't up to. In my experience, listening to engineering management discuss these matters, the few people who entertain the idea of hiring junior developers do so for fairly abstract reasons:
a sense of moral obligation, a sense of contributing to the health of the industry, a desire to challenge the software engineering team to mature in its practices, etc. I'm sure there are companies out there that know how to employ a junior developer at the going rate and actually get their money's worth, but it isn't common knowledge, and I haven't seen anybody succeed at it firsthand. If my experience is typical, we're just overall shitty as an industry at using young talent.
That creates a problem of incentives, where purely self-serving organizations will let other companies bear the expense of employing junior developers and helping them learn the ropes, and then hire them when they're worth it.
As an aside, professional soccer solves this by granting a team certain rights to the players it develops, so if a player is trained in Team A's youth academy, and Team B wants to sign them at age 18, Team B pays a fee to Team A. Team A may agree to reduce the fee in exchange for a share of any subsequent sale, so if the player develops into a top professional and is sold to Team C at age 22, both Team A and Team B benefit financially.
Companies want to hire junior developers because they can pay them half of what they pay senior developers. But they also want the junior developers to have the same experience ...
Some companies tend to hire only junior devs for junior positions. The argument is that, once hired, senior people complain about being paid lower than a less experienced dev. Some management does not want to deal with that. I know it sounds stupid, but that is what I've heard from some of my seniors.
I like having junior developers on my team and always ask to have at least one, but the reality is that we can't really afford to have more than about 20% of the team being junior.
There are some problems that aren't really addressed by the article. The main issue is that it's much, much, much easier to write bad code than good code. Even when you have a couple of decades under your belt, it's hard to write good code. While bad junior developers will sit around browsing Facebook all day, good junior developers will spend their time churning out hundreds and hundreds of lines of bad code. Mentoring or not, dealing with the fallout of that code is not trivial. And the volume of it can be daunting!
There is an additional problem that people's expectation of junior, intermediate and senior is skewed. The vast majority of people I've interviewed think it's reasonable to be "intermediate" or even "senior" after 1 or 2 years of experience. Their increasing confidence in their ability (which is admittedly improving rapidly at that stage of their career) translates into demands for more authority. Handling that transition is often difficult -- it is normal to completely screw up several projects before you figure out how to really be a good senior developer. It is also (unfortunately) normal to be completely unaware that you are screwing up those projects (even many years after the project is completed).
So when you hire a junior developer, you need to mentor them. You need to fix up problems that they create. But you also have this kind of time bomb where they will be pushing to break things on a much bigger scale. You have to be prepared to help them through that period. If you have 4 or 5 juniors on a team of 8, God help you in 2 years.
Which is not to say that you don't need juniors. However, keep in mind that the potential length of career of a programmer is something like 40-45 years. It should not be strange to have a team with several people who have more than 20 years under their belt -- and yet it is often very strange.
A guy with 30 years of experience that has only exposure to imperative programming, and never really learned OOP, networking, functional programming (it's not new: lisp, scheme, haskell, etc. have been around for decades), never really learned about operating systems, never really cared about automation, testing... unless you work on implementing software at a low level, which is very rare these days... guess what, that guy has a lot to learn from a fresher engineer, or engineers that actually cared about learning.
Are companies hiring differently, or are we just defining the terms differently?
"Junior developer" used to refer to someone who can program but who doesn't have a lot of practical experience.
Today "junior developer" refers to someone who can't program but who has a CS degree or went to a bootcamp, and there are more of those today as a proportion of the talent pool than there have ever been.
I think this failure of academic institutions to teach practical skills is diluting the talent pool, causing companies to favor more experienced engineers because they've been getting burned and don't trust their own (or academic institutions') ability to determine in advance whether a candidate will be a productive programmer or not.
Of course, the problem is not that some people are junior. The problem is that most people are junior, because, ironically, unless you live in one of the most expensive cities on the planet, their compensation is not commensurate with what an experienced developer can make in any first-world market.
When you have an inexperienced crew running your tech, you get a lot of very preventable issues, which sometimes approach apocalyptic scale (like GitLab's February data loss). That's fine for some businesses, but it shouldn't be fine for something as important as GitLab.
The funnel for junior software engineers is big but the tip of the funnel is narrow. Most of those who zip through it either went to a name-brand school or got hands-on experience with internships first. Everyone else is just trying to get lucky. On the cscareers subreddit there are a ton of people who either went through bootcamps or taught themselves how to code who have been searching for a role for a year - in the mean time doing personal projects, or trying to pick up some contract work - but no takers for full time salaried work.
The true "shortage" is really for developers with 3+ years experience who can "hit the ground running". Most companies will only make limited commitment to junior engineers, favoring mid and senior level developers.
This is exactly it. I'm involved with a lot of hiring for junior developers. It saddens me how many of them are trying to get into the field not because they're passionate for programming, interested in computers, or enjoy tinkering with digital tools. They're here because they're allured by big paychecks and "because everyone else at school is doing it."
There are, of course, exceptions, and those are the junior developers who excel the most but they are few and far in between.
It's a symptom of normalized salary ranges for entry level positions, a saturated market, and massive range in the skillset of entry level developers.
There are two sets of juniors that I've come across. The first critically assesses a problem and it's edge cases, how to integrate the solution into the greater body of work, and considers performance. They might not know the stack of the company but they can be brought up to speed quickly by more experienced team members. The second is one that is incredibly proficient at the most cutting edge tools. They are hired because they are up to speed with what the company considers valuable at that moment. There is a much greater emphasis on getting shit done quickly rather than considering how it fits in later, how performant it is, or assessing how to integrate the solution in larger contexts.
I've found the first type to be much stronger teammates over an extended amount of time. They are also the ones that are able to command higher salaries when starting out because of the approach. The second type sees the salary numbers being set by the first and has an expectation that it is what they too are worth. Now you have two drastically different candidates competing for the same entry level positions, at the same rate. The first won't have an issue getting a job and the second will struggle.
Both can flourish in the right situations. We need to do a better job at distinguishing the two.
A lot of junior developer positions, are expecting people who can't code just yet, straight out of college. They are not expecting a developer whos been freelancing and building start ups at college. But they are not going to do something about it, because they are getting someone good for cheap.
Spot on, I see many wide eyed junior developers thinking just becse they can code they can be the next startup enterprenuer with their side project and show what they can do at their current job. With a bit of experience they soon realise just because you can code doesn't mean it's good code nor does it mean it will satisfy the user requirements. Luckily most juniors I have dealt with respect their seniors and take advice, there are a few who quite frankly haven't got a clue but make out they know what they are doing.
Junior developers just can't write clear, simple code. They accidentally over-complicate everything, in the most unhelpful way possible. If you have a senior developer that does that, I would consider them a mid-level developer at best.
I've seen this play out in 2 large companies I've contracted for so far.
At the start of a new project, recruitment look for developers with the lowest daily rate they can find and end up with a team of recent grads / people switching careers within the company etc. That's all fine as long as you add a good measure of developers with >5 yrs relevant experience to the mix. But as these people are twice as expensive, they often start without them.
A few years later the product "almost" works. But it's full of bugs, it takes months instead of days to make minor changes, and it still requires an enormous team of people who are all irreplaceable (they possess the "secret" knowledge about the product that usually would be embodied in clear code intentions, past jira tickets, commit history, basic documentation etc.)
Meanwhile a new competitor in the market has developed a much better product.
This situation can last for years (because some companies are a bottomless money pit, despite being tight with it)
Eventually some expensive people get hired to put the "finishing touches" on the product and they start the long slog to fix it up (or just quit in horror after a few weeks)
So far:
1) retired the entire project after years of development
2) company got bought out and the product scrapped after several years of investing money on it
3) is in progress (company has enough money to fund the situation for years, but time will tell if we manage to untangle the mess before it kills the project)
Engineering organizations either a) understand this fact and build teams around it, b) accept that their salary floor is now +/- $140k or so (in Silicon Valley), or c) whine incessantly about the engineering shortage.
reply