A key point that you're missing is that junior devs are likely to jump ship at least once in their career trajectory before they become senior devs. So yes, junior devs do need to be trained by someone, but if you're going to put in a lot of work and not receive much of the benefit, it's not in your best interest.

There's a variety of reasons for why devs jump ship so often (including compensation), but unless you can tackle that problem first and solve it, it doesn't make sense to jump head-first into expanded junior dev mentorship.

Once they're trained up to a point where another company is willing to pay them more for a more senior position, you could give them a raise? Congrats! You trained a junior dev and they turned into a senior dev.

This is the answer, but they just won't listen. Management at so many firms have convinced themselves that developers leave because of all these magical reasons that aren't either

1) they're dissatisfied with their pay and you're not listening

2) they're dissatisfied with their working conditions (bullpens or open offices anyone?)

so they'll never keep their best people and they'll never learn.

That's because fixing 1 and 2 are really expensive. On top of that, the further removed someone is from the work being done, the more they want people to look "busy".

I got moved from a desk in in a dead end office with to a desk in a bullpen so that I could be "closer to the people who I work with." My performance fell off a cliff. People would stop by all the time to check up on things, there was always a conversation going on. It was incredibly stressful and I slowly burned out trying to maintain my level of productivity.

My boss (the director of the org.) started asking me why I was making mistakes and forgetting deadlines. I told him that it was entirely because of my new desk, and he said he would do what he could to help.

A couple of months go by, and we have another meeting. I say the same thing.

A few more months go by, we have another meeting. I say the same thing. He said he asked people to keep their conversations quieter.

A few more months go by, and we have a meeting, and I tell my boss I'm leaving because I'm burned out, and my desk is the #1 culprit. He and HR were like "you should have let us know before it got to this point."

I don't think there was a chance for them to understand the issue, regardless of how I articulated my concerns. To them, my new desk was an upgrade from the old desk. It was bigger, had lots of drawers, was closer to the "desirable" part of the building.

To me, it meant that everyone had to walk by my desk, and would use the time to chat, and ask questions that would be better handled via email. It was nice being closer to the team, but I had a way different workflow from everyone else. My boss probably thought it was great that everyone could turn around and ask me a question the second they thought of it, but it meant I was getting interrupted 3-4 times an hour, when I used to be able to work for 3 hours straight without seeing anyone.

I've honestly been thinking of calling up my old boss and asking him if he wants to grab a drink to see if he ever wrapped his head around why I left. To this day I'm baffled by the entire situation.

TL;DR: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"

How is it expensive to solve the bullpen issue? Tell people to STFU or build a wall in the office, or at least put up some dividers. It’s not rocket science.

Most CEOs and VPs are idiots, handing money around to each other in a circle jerk of old white guys club, backslapping each other for hiring each other and keeping the hegemony going.

These idiots do not know what they are doing, they have just been conditioned to ooze confidence and ignore critics.

I tried, and nearly got fired for this. Well, not fired, but I'm currently a contractor, and was told because of this that I may not become an actual hire. (This has since settled down, but I'm still not hired because of unrelated issues —they're still waiting for a government grant.)

The story is simple: we have a prefab building with 3 stories, a beautiful interior, 52 desks on each floor. All open, but for 2 closed meeting rooms per floor. And the toilet. The desks are arranged close to the window. The centre of the floor holds a couple meeting spaces, and the coffee machine. It was, unsurprisingly, very noisy.

I talked about the issue during a sprint's retrospective, and was told to lay out my proposals to HR. I had plenty, most of which didn't involve actually chopping up the "lovely" open space into actual desks. It was mostly about putting dividing half walls and generally muffling the whole thing, while mostly preserving that "open" look that is so dear to whoever doesn't actually work there (funny how most people who condoned the open plan end up spending most of their time in meetings).

I had indirect feedback later (through my team's product owner). Turned out the head HR was surprised to see me raise the subject—I was the first to do so. So she asked around. The feedback she got was mostly "well, yeah, it's an open plan, but it's okay", which she translated by "there is no problem, it's just a single contractor being difficult". I guess she was oblivious to the biases introduced by her being in a position of power. That nobody will say to her face that the noise is not okay, lest she thinks they can't fit in. (I no longer have that fear, for better or worse.)

I have later learned that a "Life in the Open Plan" group formed because of the noise issue.

> I'm currently a contractor, and was told because of this that I may not become an actual hire

They are never going to hire you. The contract is, in a way, a more airtight way of paying you under the table. Depending on the size of the business, labeling everyone as 1099 can reduce taxes for the business quite a bit. Thing is, though, is that it's illegal. But it's usually up to the worker to report it, so it is extremely under-enforced.

Bottom line is that you're being abused. I encourage you to file Form SS-8 as soon as possible with the IRS and check into your state's labor office to see what they can do.

https://www.irs.gov/forms-pubs/about-form-ss8

Source: I left a contractor role in October after realizing that I was a victim of misclassification.

First, I live in France. The practices you speak of are familiar, but legislation may be different. Second, several contractors did got hired before me. Third, the terms of the grant they seek compels them to have very few contractors. They are expected to hire en masse if they get it.

Fourth, my contractor status is actually secondary to me. More important is being allowed to work part time (4 days a week), which I'm currently negotiating.

I honestly don’t know why so many companies are clinging to open offices with a death grip. Who does this benefit???

Accounting. Open offices take less space, which is cheaper. The real costs are hidden, so they tend to be ignored.

It also looks good from the outside.

Yeah, the funny thing is that the accountants and HR all had private offices with doors that locked because they dealt with confidential matters.

In our case, even the higher ups have their desk in the open plan. Closer to the corners of course, but still. And I think this actually contributes to the delusion of harmlessness of this environment.

Having their desk in the open plan, they're more be inclined to think they are as affected as everyone else. Except they're not, because they spend way more time in meetings, and live on the manager's schedule.

As far as I can tell, the higher ups actually do mean well. I'm not sure what drew them to the open plan, but I think cold blooded cynicism explains only a fraction of their error.

I am surprised no companies offer noise cancelling headphones for staff. They are relatively cheap (compared to restructuring an office building) and could increase productivity a lot for some people.

Those headphones only block constant background noise, not conversations. In order to do that you have to put your hearing at risk with enough actual noise to overwhelm the rest.

I have tried some decent quality ones. They don't block out conversations completely, but it does sound a lot quieter. They are definitely an improvement over not wearing them.

I tried this, and my problem was that I would end up with "listening fatigue" or whatever you want to call it after 6 hours of listening every day.

I think he meant "conversations" as in someone walking up and interrupting you to have a conversation

Yep.. my Bose QC35's are amazing!

> He and HR were like "you should have let us know before it got to this point."

Why is this so common? What kind of brain dead morons are becoming managers?

Why do they even become managers if they don't want to manage. At my firm, it was the same. Some people were automatic fits and managed to do fine. The others were left to fend for themselves. No mentorship, no management, nothing.

I'm fairly aware that the about half the management at this job thought I was inscrutable. Someone who kind of knew me was interviewing for a position and asked my boss about me. His reply was something to the effect of "He's the genius who we leave alone in the corner while he does mad science experiments."

I guess it's complimentary in a way, but I can articulate exactly what I did in a way that my mom, who is an artist and barely uses a computer, can understand.

I think a lot of the problem is that some managers are really inflexible. They only know one way of management, and if that doesn't work they don't know what to do. They are a lot like teachers in that regard. We've all had teachers who could only explain things one way, and they constantly confused students who didn't grasp that explanation.

I even got my boss and HR to admit that I was really self-aware, and was able to articulate what I needed to succeed. It was like that meme where you break a logical explanation down into atomic parts and get them to agree with every step along the way, but they just said "no" to the conclusion.

I guess it's maybe an example of the Peter Principle in action.

> That's because fixing 1 and 2 are really expensive.

Re point #1, I simply don't understand how, long term, it is more cost efficient to hire and train someone entirely new than it is to build a culture of valuing current staff. Maybe I'm naive? Maybe it is difficult in ways I don't perceive?

Different budgets. Raises are continual, ongoing costs but the cost for hiring a new person can be considered one off costs, even though you are performing the "one off" task repeatedly

Some managers also seem to only respond to crises. Being down an employee is a crisis. Making sure that your employee gets an appropriate raise isn't, especially since most people aren't going to leave their boss know that they are looking for another job

This is why you take notes.

This I can nod agreed with, Im forced into open office, with a lot of marketing people, and I cant be productive, often times I end up spending my time at home fixing the hard problems, and just doing the easy ones at work. btw. I'm a junior dev. without mentor working with non tech people.

> This is the answer, but they just won't listen

Is there a counterfactual? A company with a strong culture of promoting from within that outperforms as a likely result of this attribute?

In my experience promoting from within is still insufficient. Getting a promotion means maybe a 10% raise. Quitting means a 50-100% raise. I've got a guy on my team in a junior-ish position making 80 who is about to leave to make 160. There's no promotion path in the company to get that kind of raise over night.

Where the heck are these kinds of companies? I've heard jumping for a $10-20k raise (so, roughly 20-30%), but double for a junior? Unless COL influences stuff, I'd be wondering what he did right and knock that off as an outlier.

His junior position probably doesn’t have a junior label, and the next one might have a senior.

This is the correct answer.

Well that sucks time to change the company...

I've personally never heard of any company doubling a developer's salary like that. Have you?

Double, no. But I had a company that gave me a 30-40$ increase one year because it was obvious I was performing at that level.

Then a couple years later they were giving me basically no raise. When I told them I thought I was worth more, they asked me if I could "wait a year".

I got a new job and a huge raise compared to the last one. (Again, 30-40%.)

So while it's possible, it's not always even reliable at the same company that has done it in the past.

It's certainly rare, but my employer is aggressive about keeping compensation appropriate. Top performing new hires can see their comp double in 2-3 years.

GE used to do this (not developers, but generally) in the 1980s, I think. Here's an article about promoting CEOs from within and how that is beneficial: http://www.jimcollins.com/article_topics/articles/companies-...

3) They're dissatisfied with how they are managed.

Awhile back I left my first software job (they did have systematic hiring of new grads) at a very large corporation because I was moving to another city. As it happened, that company also had an office in the city I was moving to. I applied for a position at the new location and they gave me an offer. But their offer was something like 15-20k lower than just about all the other offers I had. Apparently there was some limit on how much you could increase someone's compensation that was preventing them from offering me more. I heard a rumor that my previous boss (one of only two level 6 software engineers in the company's whole eastern region) made some noise about how ridiculous it was given that hiring me was way less risky than hiring someone else since my track record at the company was well established. But it was all to no avail. He couldn't move the bureaucracy. So of course I took the highest paying offer with another company.

Absolutely happened at my first job, too. There was a huge fuss over how much a raise they could give me and how they were capped to a certain limit.

It's great you love my work but it's not enough of a reason that I shouldn't walk across the street to your competitor and get paid 20% more.

Even if you're a savvy manager who is totally on board with this idea, you have to work within the rules HR gives you. There are lots of companies that cap promotion raises at 10% and need VP level sign off above that. How many companies allow a manager to make a habit out of 50% raises - not just for the once a generation talent who made the company 10x their salary this year, but for "pretty good" employees who are progressing as expected?

For whatever reason, letting them walk and paying that same 1.5x salary to a new mid-level hire is easier for everyone to swallow.

And from the employee's perspective, saying "yes" to a recruiter who expects to pay market rate sounds like a lot less hassle and stress than preparing a presentation on why your current company should change or make an exception to its HR polices for you.

If you're going to end up paying market rate anyway, why not just skip the training cost and hire them after someone else has put in the hard yards?

Because the problem domain, process and tooling is specific to your company and a senior person also needs time to learn them.

Plus, turning a junior into a senior developer isn't exactly a boolean switch, that is turned over night. It's a process and that junior developer will spend a lot of intermediate time between both states, in which he's still very useful, yet affordable since he's probably paid below senior level.

That's true. Presumably the junior developer is cheaper while they're junior, but if nobody's hiring them anymore then I guess they're not cheaper enough to compensate for needing to train them.

Maybe by creating a workplace where developers want to stay you could keep them around at slightly under market rate? Not everyone is looking to job hop every 6 months. But the amount below market rate that you seem to end up by staying in one job feels like it's unreasonably large.

That's true but it also misses the point: A portion of the limited money-pool you could have used for their raise is already gone, spend in the extra costs (direct or opportunity) of the training period.

There isn't much of a "raw mercenary economics" argument for training (which the MBA types prefer), you've got to talk about intangibles like loyalty, goodwill, social connections, etc.

That doesn't make sense to me.

Let's say you train someone whose salary is [x]. After training, their market salary would be 30% higher; [1.3x].

Are you suggesting that if they end up with a hypothetical 10% raise, to [1.1x] because [.2x] was spent on training?

That's absurd. You can't just walk out on the street and hire a person who is already trained for [1.3x]. You have to devote resources to the hiring process, which are probably nearly as expensive as training up a junior dev, all things considered.

I honestly think the difference in the second example is that the expenses in the second example are paying the kinds of people who make stupid personnel decisions like this.

I'm obviously cynical about the whole thing, but it seems that MBA-style thinking is almost deliberately evil. I have friends who have gotten MBAs from top schools, and friends who work in management consulting for the Big 4, and I've talked at length with them about their feelings about business practices that they implement and support. I literally have never gotten an answer that justifies philosophical objections to their work, beyond perhaps "well, it's just the way it's done."

I think it's a myth that organizations have to behave in a deliberately sociopathic manner in order to be successful. I mean, to a certain extent being a sociopath is an advantage, but I really don't think that's really a necessity.

On the flip side, I acknowledge that I am not very good at divorcing who I am from what I do. It's why I've made a career helping non-profits and social enterprises. I'd probably be a healthier person if I were able to get less invested in what I do.

> Are you suggesting that if they end up with a hypothetical 10% raise, to [1.1x] because [.2x] was spent on training?

Either that, or the company makes cuts somewhere else which -- all else being equal -- puts it at a competitive disadvantage. Budgets are generally zero-sum at a particular moment in time.

> You have to devote resources to the hiring process, which are probably nearly as expensive as training up a junior dev, all things considered.

If you can prove that to the bean-counters, by all means spread the good word.

However even if true you must consider a third potential outcome: You train up the junior employee, and then they don't stay with your market-rate offer for whatever reason, and you have to incur the hiring-process costs anyway for the empty senior position.

That scenario is always be more expensive than the other two, and it can only strike junior-trainer companies. Senior-poacher companies don't have to even worry about the odds of it occurring.

But if they leave, now you have to pay to train a new junior dev, and you still have to pay full price for a different senior dev.

The "raw mercenary economics" argument is saved money on recruitment/and allowing better calibration of performance to salary.

Consider the costs associated with recruiting for a single role. You have to either advertise a role/filter out candidates or engage a recruiter (which costs time or money). You have to interview a number of people, taking time (money).

You then have to onboard that person, and choose a salary based on your limited knowledge about them. And even then you could still hire a lemon (although admittedly it could go the other way and you hire someone better than expeceted). You then have to wait for them to become productive in the new organisation.

You also have much better information about someone who has worked at your organisation for a longer period of time and can therefore tailor their salary better to their skills than for someone who you know nothing about.

Spending money on training is a predictable cost vs. an unknown future cost of hiring. And yes, people will also appreciate it as an intangible, which if you are 'mercenary' you can enumerate as a supplement to a certain amount of salary.

Market rate compensation, non-toxic culture, and realistic expectations for work output solves 90% of the reasons reasonable people leave jobs.

People claim all sorts of reasons for leaving jobs but its always one of those three or uncertainty about company longevity. (i.e. acquisition/financial difficulties for the company)

The other 10% is people who are naive or have a family/relocation related issue that you can never control for.

And yes, before you say it is impossible, I've worked at a company where "voluntary quits" was _that_ low and no one voluntarily left because they knew how good they had it. Literally, in a team of 20+ I knew all 3 people who voluntarily quit over the span of 10 years there.

You may have a point in here. Provided I have productive working conditions and 5-10% YoY salary bump I'd probably never have the inertia to look for a new job myself.

Most company doesn't work this way. They are not really toxic, it is just their internal policy structure.

Junior devs should look for jobs once they reach the 2 years mark any more, for their own good as well. They now know better what they want to do, more focused, more experienced, and most importantly, more valuable on the market.

When I first got into programming, as a high school intern in the early eighties, I was told a programmer stays at a job, on average for the years. I haven't heard this number change at all. While I'm sure there are many jobs where people stay along time, the average length of stay is still fairly short. Boredom and wanting to work on something new is probably the biggest driver

   Boredom and wanting to work on something new is probably the biggest driver 

I have to disagree with this point. Switching jobs is a very stressful and scary experience. Most people don't want to jeopardize their income without having some very strong motivator. In my experience, the most common reasons someone changes jobs is:

- Promise of a higher income

- Low perceived stability at the current job (employees want to secure a new job before they're layoffs)

- Toxic work environment

I HAD to switch jobs 3 times within 2 years when first starting. (Redundancy, restructure, outsourcing.)

It's no longer scary or stressful. I now choose to switch jobs regularly because I get better incentives to join somewhere else and I get more bargaining power with each transition.

C-levels and shareholders made it this way - if they kept with market rates and the organisation put more value in employees and their IT I'd stay around. But I've been seeing more and more of a shift to outcome-based budgeting, maintenance and refactoring isn't even part of BAU budgeting - it's strapped on to project work. This is likely exclusive to non-tech companies (even though most companies are shifting towards tech as their basis ala "Software is Eating The World").

Managers can only do so much within an org, I haven't worked for a manager I didn't like (I've turned down jobs based on my interview process though). Not US based.

> When I first got into programming, as a high school intern in the early eighties, I was told a programmer stays at a job, on average for the years. I haven't heard this number change at all. While I'm sure there are many jobs where people stay along time, the average length of stay is still fairly short.

I've literally worked at _one_ place that scored well on those three items. Most places are racing to the bottom in one or two of those. Usually it is pay unless you are somewhere competitive like the Bay Area.

> Boredom and wanting to work on something new is probably the biggest driver

That is much like the "exciting new opportunity" story people tell about why they changed jobs. It is not _real_ in the literal sense.

If it was real, they would shop around internally to change projects and succeed. There would be no real need to change jobs.

Idk where you have worked but I've literally never worked on the same project for longer than 1-2 years. Even if I was at the same employer for 6+. If you have people with realistic expectations who aren't piling on technical debt, maintenance work _should_ be negligible even if you are lightly attached to old projects.

Comeon now, there are more reasons than that for people to leave, like a new exciting opportunity appearing.

People _say_ that to acquaintances, to coworkers. Just like they stay positive in the workplace and a bunch of other fronts people keep up as part of work life. Your job at work is to sell yourself and your skillset.

With people you talk with honestly outside of work YMMV but I've never seen that as a legitimate thing except with naive people who ended up regretting it. I've only seen people being happy with it when they were already underpaid, unhappy with the culture, or forced to work absurd hours to keep their jobs.

> a new exciting opportunity

You mean a salary or title increase? Yeah, that's in the GP's comment.

No, like a project or team you really want to work on for any number of reasons other than salary or title.

Not just the risk of them jumping ship, the problem is that because mid to senior dev salaries are highly desirable it attracts juniors into the field who are not suited to the job but like the idea of working in the industry or the potential money in it. So, you spend time training a group of people where some aren't suited for the job but you spend a lot of time on them and the better ones leave quickly. If you don't pick the juniors carefully in the first place and if you don't have the environment and renumeration to keep the better ones from leaving then it's probably better to just not spend too much time on recruiting them. It actually might work well for a company that doesn't want or need a large dev team. Also, not everyone is good at mentoring, some of the best people are often self taught and some of them find it difficult to teach others.

They jump ship more often when they stop or significantly slow growing than when for compensation, but eventually compensation becomes a problem just the same as at any job.

You're underestimating how quickly a junior dev can be putting out useful work - within a few months they'll be tackling a ton of bugs and freeing up senior people to work on bigger features. Yes, eventually they leave, but it seems like everyone seems to think they're just dead weight.

You could poach them too. It could be a tragedy of the commons scenario, but it would be nice.

I did say "they still need raises" :) But I get what you are saying.

As a junior dev, I have received at least one double digit percentage raise. This was a while ago, and perhaps I worked for an enlightened boss, or maybe I was just really really undermarket. But it can and should happen.

The long term approach would be to give the juniors raises and challenge them and keep them within the org. Unfortunately the short term perspective doesn't value that and so jumping ship is the best way to get more money, causing the org to lose all the training and the institutional memory.

> No one wants to train junior devs.

Many dev shops want junior devs, and that's a great place to get experience if you get placed on-site with a good client. Also cash cow businesses where tech isn't their core competency (media, fashion, pharma, etc.) will hire junior devs.

Basically if you're spending all your time trying to get hired by a startup or by FAAMG then you're going to have a bad time, but if you focus on the types of companies that actually hire junior devs then you shouldn't have too much trouble at least getting interviews. It's obviously still very difficult because you're pretty much useless, but if you're at least willing to put in the time to do the hiring homework assignments then you'll get taken seriously as a candidate.

That's weird, in my experience FAAMG (maybe less so Apple) hire junior devs by the truckload. However, I don't think they are typically in the business of hiring bootcamp graduates; it's mostly new grads or people transitioning from a similarly technical job/advanced degree in e.g. physics or math.

It's pretty interesting -- as a startup founder leading a dev team of ~10 people now, I've hired almost all junior level candidates. We never had a posting for "Junior Software Engineer" though. We just had one posting and considered everyone who applied separately and within the context of their experience.

One reason I see especially in larger companies that there is specific hiring headcount allocated. Always it doesn’t specify if the allocation is for junior/mid/senior level. So to optimize your team’s output, you tend to look for the mid/senior and not even consider junior people.

This. If more managers were given a budget rather than a headcount, they'd hire more juniors. At my last managing gig, I was the only manager at my level to hire junior devs.

I prefer a little mentoring/supervision to the "too many chiefs" problem. And juniors have fewer bad habits I need to break, so I can more easily mold them into the kind of developer I want. Also, junior devs are much more willing to take the crap tasks that seniors find less challenging/interesting. I can stick a fresh college grad on bug duty and they'll often churn through them faster than the senior devs. The raw horsepower of some young devs is damn impressive just as long as you keep them pointed in the right direction.

But I've also found that mentoring is a rewarding part of the job and now that I manage, I really enjoy mentoring mentors. Helping turn great experienced devs into great teachers helps take them to the next level and I've had guys that didn't want to do anything but write code thank me for pushing them to mentor.

So yeah...lots of companies give their managers perverse incentives and allow them to be lazy. But if you're conscientious and put a plan in place, mixing in around 30-40% juniors can be cheaper, more productive and better for everyone involved. It's just harder and most managers are more interested in playing politics to increase the size of their fiefdom than they are in actually shipping software and thinking about their reports' careers.

You're missing a rather obvious point. A junior dev after months of training could jump ship for much better comp now that they're less junior or that suddenly some other company's product interests them more. Another point missing is that sometimes there are very hard problems (eg. self-driving cars, fusion power, DNA pattern matching) that need solving quickly and that's what some companies try to do, there are other type of companies that solve move mundane problems (hr software, customer relation management software, email tool) that have been solved over and over again. To bundle all companies into one category when it comes to training junior devs is a mistake, junior devs could be trained at companies working on easier problems much more cost effectively and efficiently.

> A junior dev after months of training could jump ship for much better comp now that they're less junior or that suddenly some other company's product interests them more.

Sure, but that's why you need to give people raises in line with market rates if you don't want to experience high turnover. That goes for junior and more senior people.

Companies often don't want to give big raises as junior people transition into mid-level, then senior. So many companies have a standardized 2-8% pay raise scale, which results in developers being drastically underpaid as they gain experience. The silly part of that is that those same companies are gonna have to pay market rate to replace those skills when their employees leave, and they have to eat the additional recruiting costs, lost institutional knowledge, and ramp up time for a new employee. Penny-wise and pound-foolish as it were.

I think there is a lot of assumptions being made in regards to what training actually is. In software development field change is constant a senior dev can not afford to stop learning new techniques, frameworks, etc. that’s not something you just get mentored at and you’re set for the rest of your career. The issue that seems to be ignored here is the fact that good devs are active learners on their own and do not typically require the kind of hand holding that is implicitly implied to be required in these type of arguments. A company can not train an employee who otherwise does not have the required skills for the job and hope that once they are trained will stay at the same company.

Here is the equation in my mind:

cost of junior dev added slowness + senior dev lost training time > recruiting cost for senior devs + lost institutional knowledge + ramp up time for new senior devs

Devs are constantly learning but there's a still a lot at tech jobs that you are paying people to learn once. Some of it is how to get around in legacy code bases that haven't been worth replacing yet, but even things like "this is how you file an expense report" add up in time and need to be repeated for every new hire

I disagree with that statement. I find that a junior dev is far less jaded by the work world and will often develop a loyalty and dedicate to the team (if it is a good environment) that a sr. Dev wouldn't. Once your are 5 to 10 years into your career how you view your work/life balance and professional relationships changes dramatically.

A junior dev will often stay with an organization much much longer than what is probably good for them, especially if they are actively mentored and engaged.

I agree with this. My first job I was under a fairly good partner who took the time to mentor me, get me involved in decision making processes, and take me out to see clients. It was some of the best times of my life and I did learn a ton. I had to move for a family issue and immediately received a 35% raise in a similar COL location. If I didn't have that issue come up, I probably would have stayed much longer and continued to be underpaid.

Junior devs can also be great for sticking on smaller\simpler\more rote things that might be boring for a senior developer, but for a junior is new territory. Depending on the size\complexity of your codebase, a senior will take lot of time to actually be useful anyhow.