As far as i know, management provided zero training (online courses, conferences, books etc) and the dev intern is receiving 500€/month for 40h work week, which around Amsterdam/Netherlands hardly covers housing expenses in shared accommodation, even though the intern is soon expecting Erasmus support, which will alleviate his situation apparently.

Needless to say i find the situation rather vile independently if it’s a common practice or even if non-paid internships are common.

Recently i took the dev intern out for dinner and beers, gave him a few tips on how to improve himself to be ready for a decent job (online courses, writing blog posts etc) and told him he could repay me by paying forward to an intern at his next proper jobs.

As a note, another intern (part time) is also working on his maybe 5 years old laptop that apparently crashes a lot and can hardly run something like Pycharm.

I’m looking for another job :-)

"Devs can't be cheap enough! We can't find decent devs!"

If you want to get paid a lot more and you have the right skills the City or Silicon Valley are good options (assuming you are allowed to move there).

It doesn’t need to be a huge tech hub at all. Luckily English resembles Dutch so most Dutch speak it well enough to survive a job abroad.

I know very well paid developers in NL and very poorly paid ones, it is mostly a matter of knowing what you are worth and refusing to charge less than that. You might find 'your spot' taken by a skilled immigrant but that's a relatively small chance.

I'd hate to have to find a developer job in Spain or Portugal judging by the number of people from there that have moved to either NL or DE. Anything East of the German-Polish border is going to pay a lot worse unless you are willing to move to Finland where there are pockets of start-ups with reasonable compensation.

Dutch developers moving abroad to increase their salary is not a trend as far as I can see.

I know well paid developers as well, some niches pay pretty well. SAP for example. Or simply people that have domain knowledge that's irreplaceable and know how to negotiate. But something average like C#, RoR or Node development doesn't really pay well in The Netherlands. It's a decent salary but nothing to brag about.

My take on this: it's so easy for Polish developers to move to and find a job in Western Europe, that local companies have to pay salary that provides at least a roughly comparable living standard (vs the West)- as otherwise talented people would just leave. For "suits", on the other hand, there's far less opportunities abroad, so their wages don't need to track Western standards so much.

This effect is even stronger in Ukraine, where a teacher will be paid $300 (per month) while a dev will make $3000.

Internships in the Netherlands are akin to modern slavery imo. You work full time and with luck you get a compensation of 500 euros a month,though often no compensation is more likely to be the case. You will get a maximum loan of 1100 euros a month from the government, so a lot of students have to take on a second job if they don't get any compensation at all at their internship.

National institute of neuroscience provides no compensation whatsoever, and for applied mathematics students the average compensation is around 200 euros.

Obviously not wholly related to your comment but the internship situation in the Netherlands really grinds my gears.

Your employer has no obligation to compensate for your internship, but is not prohibited either. There is no minimum or maximum amount set for this compensation.

The focus for internship should be on training, not work. If the Inspectie SZW (employment auditor) finds that the internship consisted of mostly paid work, the employer will be ordered to salary the intern according to normal wages [effectively, minimum wage].

However, there is a practical limit to compensation: students earning more than E20,000 a year are no longer eligible for the student loans you mention.

Student visas?

Hmm...I don't think you are correct, or possibly you are misconstruing a limited, special case to generally apply.

From my own experience I earned more than 600eur as an intern in the NL, and I had classmates who earned full minimum wage as interns too (~1200eur).

Good, I was just going to suggest that!

On further note, before i started the contract i was asked to bring my own laptop as work computer, i didn’t necessarily agree (for all the obvious reasons as security and business/personal risk) but he was being pushy about i said i could take my laptop (at least to get started) and i was expecting to get a working computer. I never did. Management recently purchased brand new macbook pros and iphonex for themselves (which they are in their full right to do).

So i didn’t even dare to criticize them regarding the interns. I already got myself in boiling water by criticizing management in that the way projects and tasks were being managed was highly unprofessional and my only wish is if i could leave a warning sign for interns (and devs) to keep clear of this company (or think really hard on how much they need the job)

Edit: which is unfortunate given that the projects there are interesting in my opinion

    I already got myself in boiling water by criticizing
    management in that the way projects and tasks were being
    managed was highly unprofessional...

I'm not making any comments on your personal situation, but as a general rule it's important to talk in terms of solutions and not problems. So don't say, "we have a problem and here is my recommendation to solve it". Say instead, "I think we can improve our productivity by...", or "I think we can save some money by...".

Do some calculations to help sell your case. You want to spend time optimising the build process? Record how long it takes to build the code currently. Maybe it takes 5 minutes. Maybe you build the software no fewer than 12 times a day. That's an hour of productivity wasted per developer. Do the maths, convert it into dollars. Then say, "we can save X dollars a week by optimising the build process. We spend a week working on this, we will have made our money back within a month (or whatever it is)."

Your manager will be quite happy to go to the board to tell them that he's improved efficiency by a factor of X.

Highlighting existing problems, even whilst providing solutions can put a manager on the defensive when you really need him to be your ally.

Obviously I'm not saying never highlight problems. Sometimes you have to highlight problems, but it requires delicacy and if you don't need to, then don't. You probably don't need to a lot more than you think. We developers tend to put the problem first and the solution afterwards and it's quite hard to put aside that mindset when talking to stakeholders. Even Elon Musk finds this hard to do when talking to the press. It's quite funny to hear him talking about all of a Tesla's inefficiencies while trying to sell it!

Also be patient. Your manager actually needs to be convinced of what you're saying; he can't just take your word for it. So if you see an example of how your solution would have prevented a problem that just had to be dealt with, point it out. Take him on a journey, to use an old cliché.

I'm not suggesting you shouldn't do anything without getting permission first, but for the things you do need permission for, the above advice might help.

You have to watch out that a "go getter" attitude doesn't result in you just getting overburdened.

They seem to be scamming the shareholders diverting money from productive investment into their self worth. It's not your problem, but it's not in their full right to do either.

It is also almost certainly not the employees (unless it's a cooperative).

I told them they could pay me a compensation (for using/bringing my own tools) but that is quite expensive since most deductions don't count for this. Even more expensive than buying a proper laptop. Quite quickly I got a proper company laptop after finances improved to resolve the issue.

On another note:

In my experience the term 'middle management' is a synonym for corrupt, useless idiots so getting rid of them saves huge amounts of money since they add no value to any product or to the company as a whole. Unfortunately there is no way to even moderately grow within most companies around here except for a management track which is idiotic since specialists are way more valuable to the gross product of the company.

and: Never underestimate the value of skilled workers and how to keep them or train them. In software they are your main business. Everything else is easily replaceable.

In the US at least, any work you do for an employer and get paid for is covered under what are called work-for-hire laws which assign the copyright to the company, unless you have a written contract stating otherwise. This is true regardless of what equipment you use, and there’s absolutely zero legal barrier to a company asking you to use your own equipment in the course of a job without any compensation. The fact that your ultimatum wasn’t met with a “lol no” from Legal is pure luck.

That's the norm in some professions. Welders and mechanics often have their own tools, which can cost a lot more than a laptop.

Some managers, mentors or such seem to deal with this well. But, in the cases that I've seen having an employee that is not producing value is stressful and time consuming. Largely, it's driven by empathy. You don't want them to get fired, or embarrassed.

Anyway, the person taking up most mentoring time (including:'leave this part, I'll fix it) is also producing the least of the least important stuff. The best juniors can be left to their devices and everything is ok, but basically the time and effort allocation becomes very inefficient.

Mentoring is important, but I disagree with you somewhat. Software is just an ADD industry. Everything is fast. You hire for needs in the next 12 months. Junior devs (all devs, some places) average short stints.

Anyway, mentiring, training and such are long term investments. Makes less sense in industry segments that think in shorter horizons and treat everything from office space to employees or even products as 1-2 year solutions. Entire companies are built around 3-6 year horizons from cenception to exit.

I see this as a byproduct of product development time. MVP and its associated stuff... It's all about short horizons, clean slates and short term planning. Nothing is free and the cost of this is anything that's part of long term strategy, like hiring and training for long term benefit.

That's like, your opinion, man. Why can't you hire long-term? If all you plan for is short-term, it will only work short-term, and it should be no surprise if on the longer term you fail or you find yourself in a world of pain.

> I see this as a byproduct of product development time. MVP and its associated stuff... It's all about short horizons,

I think you severely misunderstand MVP... it's not at all about short horizons, on the contrary. It's about doing the right thing in the longer term. To put "MVP" in a hiring context - the right "MVP" attitude is to hire temporarily to see whether the person is right for the job - and once you determine you've got a good fit, invest massively in that person to make sure you've got a long-term employee (don't just skim him/her for short-term profit, but invest to build a long-lasting relationship).

> Entire companies are built around 3-6 year horizons from cenception to exit.

I've yet to see that work (and not in the sense that "lottery works" - nobody seriously suggests buying lots of lottery tickets if you want to get rich.

My point exactly, only in reverse. In industries (eg, merchant banking, corporate law, industrial engineering) where the plans are longer term, the thinking is longer term. Here you see highly involved onboarding programs with mentorship, in depth training and such.

Uber, FB, snapchat, netflix or whatnot never had plans that really looked past 2-3 years into the future. Ambitions, possibly. That's different to plans. These are on the young/ADD end of the spectrum, but they have cultural influence industry-wide.

I disagree about MVP. First, I don't think short horizon is bad, it's choice with advantages and disadvantages. Second, I do think MVP is part of a wider, shorter horizon planning mentality. That has certainly been my experience. The idea (IMO) is that instead of planning, you evolve. Evolution and planning are at odds with eachother, to an extent. You can make decisions early, and you get a longer term plan to work with. You can make decisions just-in-time (eg after launching an MVP), this gets you more informed decisions. That's not necessarily related to HR. You're hiring and onboarding could be unrelated to your product and engineering plans (or lack thereof). But (again, in practice), I think that mentality is influenced by these things.

^That's like, your opinion, man. ...always ;)

"I've yet to see that work" ... Uber. Netflix' streaming service.... for large, famous examples. Call those lotteries if you want. They're definitely risky. You may not like high risk strategies but they are a big part of the software industry, especially on the culturally influential wing.

I work in banking at the moment, and the thinking is anything but longer term. Management is so desperate to hire enough qualified developers that it fills a lot of the vacancies with contractors, which are, by company's definition, temporary. So, in other words, the company is already planning to let go of people who will build its vital systems. That's myopic thinking at its finest.

What's interesting is that big part of enterprise market in, for example, London seems to operate like that - management pretends that people are replaceable cogs that hold no company-specific knowledge and require no ramp-up time. The stupidity of it is mind-boggling.

I really don't think that Uber and Netflix hired for the short term. Especially Netflix. How did you get that? Netflix in particular seems to have been playing the long game for quite a while.

You can, but I have never been offered a multi-year employment contract. Employers seem to prefer the flexibility of being able to terminate employment sooner than that.

I've been working >10 years as a software engineer. If I'd never worked on a (necessarily) complicated system(s), I could maybe understand your viewpoint. Churning out the same CRUD app with minor differences would probably be safe enough to expect a junior dev to 'have at it'.

> Everything is fast

Unfortunately, this is the current 'thinking' on how some un-enlightened people think the industry should work. Ultimately, I think this is a load of nonsense. Software engineering is engineering. Some people may have snuck in & survived as they never had to do something non trivial & deal with the resulting consequences.

Anyway ,it's not about how people think the industry should work it's about how it does work. This is a fast industry, irl. People change jobs more frequently. Companies grow faster. Products go from conception to release faster. Financial horizons are shorter.

A big chunk of the 2018 industry did not exist in 2008. Mobile, for example. Not the companies, not the specializations. It's not philosophy. It's reality. I'm talking about side effects of this reality.

No one at Snapchat thinks "we'll hire this kid, he'll make a great engineering manager in 15 years." They do in some industries. We're on the other end of the spectrum.

In one case you've hired someone who isn't ready to do the tasks you need without excessive scaffolding. In the other you're not providing enough structure and scaffolding for the intern to succeed with help.

Mentoring, particularly in the legal context of what makes an intern, an intern and not a Jr. Developer ought to be a short run project, and frankly if you can't commit time to providing an educational experience you shouldn't be filling your staffing needs with an intern at all.

The thing is - they got 2 very driven loyal devs out of it, and cheaper than normal at first. They also had an assessment period of 3 months after which the one who would take up all my time was let go. It was absolutely worth it for the company.

I end up spending my own time helping out senior developers in places they get stuck! (Inconceivable!) Yeah sounds like a management team and a bunch of senior devs who have no concept of a team to me?... Which makes them no-hire types at my job. I help people regardless of what they're working on. If any of us fails it affects all of us in the long run.

I love programming and helping others achieve it and working with others to learn is one of the better and more fun parts of it.

I learned to not get upset by it but still help/share, trying to inspire others and always learning more in this process.

My suspicion is that anyone my age or older had to do a lot of banging their heads against the wall, alone in a room with the machine, when they were learning their craft. It becomes very tiresome dealing with people that don't even try to figure things out on their own first.

I've heard that being a dev is 90% thinking about code and 10% writing it.

In my experience you hire senior devs to do the thinking part and junior devs to do the writing part while learning how to do the thinking part.

Senior developers should be writing code for important systems, and juniors should be writing the less important bits. That way, they get the opportunity to experiment without the company being stuck with a critical system written by a person who reinvented Yet Another Elliptical Wheel.

Mentoring is important and all, but at some point, you just have to start working.

For at least 2 companies I've worked at, this is false. Junior devs cannot complete their work at all without help.

This may be the real problem: there is no way to learn the skills to do the job without actually getting a job first and learning the skills as you go.

Now that I’ve had some mentorship I can be productive on my own, but yeah, it took some work.

The senior devs get pulled into meetings, customer escalations, bug reviews, etc. all the time. The juniors, now trained and competent are free to code all day and get the work done because they have fewer responsibilities.

Yes, it takes work to get there, but it’s worth the effort.

As the employer/manager, you need to work to minimize the period of time this is the case and ensure those junior devs quickly get to a point where they can work individually.

I mentioned it elsewhere in this discussion - we have a 1 month on-boarding program for new devs. They all arrive at the same time (summer after graduation), stay near HQ, and work through all the common training together (some tech, some culture, some "how to be an adult", etc). They also work through a simple, but in-depth (UI, API, build pipeline, etc), group project. And wrap up with a two day hackathon for fun (done in common with the summer interns).

Pfft. I'm about as "senior" as it gets and I'm generally the fastest developer in any team I'm on. I've never met a junior dev that could hold a candle to me, and most senior devs I know are the same...we're coding monsters.

- Better (usually simpler) designs.

- Breaking the problem and choosing the order in which things are implemented.

- Setting up usefull feedback loops.

- etc, etc.

It is a lot about judgment.

that’s the worst kind of data - gives a meaningless feeling of objectivity.

PS: Most people have never worked closely with someone with 25+ years of experience, but the difference is staggering.

Good junior devs are... well, by definition, good. They're just younger, and less experienced - but every bit as smart as you are, and pretty skilled in the art of coding. If anything, they have more time than I do and are a lot more eager to "prove themselves".

I don't view the value I add as "can code features faster"...

I do, at least partly. I can code so much faster that my cost per feature is lower than a junior dev.

It was staggering how they had managed to survive for 25+ years. Every person is different.

Having not worked with the same person for 25 years I can only speak of the average case.

I pointed out how you decided to pick out a totally irrelevant, rhetorical sentence out of all points that OP made, and then decided to refute that, by claiming how much experience you have, and setting up yourself center stage, instead of adding value to the actual discussion topic at hand, which is the coaching gap.

> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!

> "Mentoring" is basically the job you hire a senior dev to do

What other "points" did OP make?

The topic is about a lack of mentoring for junior devs. You being a certified 100x rockstar developer is totally fine but irrelevant, because you don't scale.

What would scale is if you were to start coaching junior devs, because if you don't, all the juniors will keep reinventing 'left-pad' in this week's ES201x iteration, while your retirement keeps getting closer.

Instead of adding to the discussion on how to solve the coaching gap, you decided to defend your coding efficiency and how you deliver features faster than a Junior Dev. You missed the point completely. You're part of the problem the article addresses, don't you realize?

That is exactly what the post I was responding to said, and I've quoted it several times. Here it is a gain, since you keep glossing over it:

> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!

> "Mentoring" is basically the job you hire a senior dev to do

So, yes, the person I responded to said "senior developers shouldn't be coding'".

> You being a certified 100x rockstar developer is totally fine but irrelevant, because you don't scale.

How so? I'm a mentor as well as a developer. In addition to doing my part to train the next wave of devs, I also code my ass off. What part of that doesn't scale?

> You missed the point completely.

No. That's what you did though. And are increasingly insulting about it as well.

> You're part of the problem the article addresses, don't you realize?

Who's talking about the article? I was talking about the bogus "point" in the post I responded to.

I’m surprised you mentor, given all the hubris you have displyed on this thread.

If that's what he was saying, I'd be much more in agreement. Instead he said, effectively, that senior devs shouldn't be coding because they can't do it any better than junior devs.

A. GOOD junior devs can (and often do) outperform good senior devs at the metric of "quantity of code produced" (I later added that IMO in fact they should, not just can)

B. (the central point of my argument, really) If you're working on the premise "we can’t afford to have our senior developers mentor juniors" , you're misusing the senior devs. It's not just cost-ineffective (you're paying a senior do to a junior's work), but you also run into other risks as well (juniors that ask questions force seniors to explain stuff, which in turn forces them to think clearly about it; you may have experienced the phenomenon where you understand something much better after explaining it to somebody else)

> If you're working on the premise "we can’t afford to have our senior developers mentor juniors" , you're misusing the senior devs.

Actually, no argument there. Mentoring is indeed a critical function of senior devs.

> It's not just cost-ineffective (you're paying a senior do to a junior's work)

And you lost me there. I'm so much more effective that it's always cheaper to have me do it, assuming I don't have a higher priority task (in which case it's a non-issue, since I'm working on that one). I.E. I'm a 10x (or 100x) developer, but I don't get paid 10x (or 100x).

Could you do an MSc at a top-level US university (in your primary domain of expertise) in a week? Because plenty of people (juniors by definition, almost all of them) can do it in 2 years, so if you're "100x" in the sense that you say you are, you should be able to do all that work in 1 week. At least that much should be plainly obvious to you, that you can't possibly be "100x" in the sense that you claim to be. Or well, if you are... you're rather unique, I definitely haven't seen anybody that can even come close to you, and I know some top-notch engineers. So you're definitely the exception, not the rule.

No, but I probably think better...i.e. how to approach a problem, sift out the relevant details, formulate a plan, execute it, understand the trade-offs, etc. As a result, I can deliver more correct code faster than a junior dev.

> you can't possibly be "100x" in the sense that you claim to be.

I never claimed to be 100x. I was just mentioning the reason why I'm cheaper than a junior dev (that I'm not paid in line with my "effectiveness multiplier"). You were the one that mentioned a 100x engineer thing in a link, so I included the number.

You actually did - look 2 posts up, "i.e. I'm a 10x (100x) dev". But I suspect you didn't actually read that link, just the URL - not fair to chide me for mentioning the number if you didn't read what that meant.

> how to approach a problem, sift out the relevant details, formulate a plan, understand the trade-offs

That's exactly my claim, that you add more value with this sort of activity than the "execute it" part; doing that plus teaching others to do it, you add exponentially more value to the company, than just coding stuff in a corner .

You cling on the fact that a junior dev can't possibly code faster than you - even though it's a completely irrelevant detail. And yes they can, if you remove qualifications like "correct code" or "maintainable" or whatever (I never claimed junior devs will do the right thing all by themselves, that'd make them seniors, right? But - I participated in coding competitions in high-school, got a silver medal at IOI - I know very well that my younger self could code circles around my older self when it comes to raw speed. And I've seen other people like that later; experience can't fight youth when it comes to speed and enthusiasm... it just can't. It's more likely that you just never worked with a good junior dev before, than it is that you can always code everything faster).

> I'm so much more effective that it's always cheaper to have me do it, assuming I don't have a higher priority task (in which case it's a non-issue, since I'm working on that one). I.E. I'm a 10x (or 100x) developer, but I don't get paid 10x (or 100x).

The numbers were merely to indicate that my multiplier is sufficient that I'm cheaper than a dev.

> I suspect you didn't actually read that link, just the URL - not fair to chide me for mentioning the number if you didn't read what that meant.

No need to suspect, I confirm I didn't read it. I saw the number in the URL and just dismissed it as puffery.

> That's exactly my claim, that you add more value with this sort of activity than the "execute it" part; doing that plus teaching others to do it, you add exponentially more value to the company, than just coding stuff in a corner .

That was in no way you're claim, at least, not the claim I disputed. Your claim(s) were:

> You don't hire senior devs to code - good junior devs can code not only "just as fast", but probably faster too!

> "Mentoring" is basically the job you hire a senior dev to do

No way. Maybe mentoring is a part of the job, but it's by no means the main job in many organizations.

> if you remove qualifications like "correct code" or "maintainable" or whatever

??? This is a pretty ludicrous statement. Why would you ever count incorrect code? And yes, I probably can code incorrectly faster than a junior dev, too. After decades of experience, I'm a faster typist than most junior devs.

> I know very well that my younger self could code circles around my older self when it comes to raw speed. And I've seen other people like that later; experience can't fight youth when it comes to speed and enthusiasm... it just can't.

Rose colored glasses, to say the least. You seem to be switching back and forth on whether raw LOC throughput is meaningful...first you were "flabbergasted" that it might be a measure of productivity, now you're bragging about raw speed, and even suggesting that creating "correct code" or "maintainable" code is irrelevant, which is insane.

> It's more likely that you just never worked with a good junior dev before, than it is that you can always code everything faster).

I've worked with (and mentored) some really great junior devs, who grew into great senior devs. But they didn't walk into the building as my equals in coding.

This whole debate is nutty. I personally would welcome as much strategic and intellectual diversity as possible onto teams I'm running. I wouldn't put all my eggs in one basket, either.

Me too. I just think the blanket assertion that a junior dev is the coding equal to a senior dev is what's nutty.

> can code not only "just as fast", but probably faster too!

is pure BS.

Good junior devs will be more skilled in some areas than you are. Maybe it's stuff you're not interested in; or just stuff they're really interested in. The only way a good junior dev doesn't "out-code" you, ever - is if you're only skilled in a very narrow niche (bonus points if only few people are interested in it, at all).

Junior devs absolutely can, and often do, build "wrong things" faster than senior devs. The measure of seniority is in my mind about knowing what to NOT build, in the first place.

Who uses LOC? I'm talking about completed, tested, accepted features, as defined by our project teams.

> Good junior devs will be more skilled in some areas than you are.

Well, yeah...of course. I'm not comparing myself to someone who works in an entirely different field. A junior front-end dev will be better than me at front-end stuff. I'm talking about a junior in my area, who I'd be in a team with or would mentor.

> The measure of seniority is in my mind about knowing what to NOT build, in the first place.

I agree with that statement.

Still rather strange metrics for productivity in a senior engineer. This is more what I'm taking about: https://zef.me/the-100x-engineer-6d50a690a866

If you're really senior, you shouldn't be working on the kind of features that get delivered at a rate of "5 per sprint". More like on stuff that gets delivered once every year. The junior SHOULD outperform you in "code produced" - they just shouldn't outperform you in dollars produced (or saved).

When I look at code written by junior devs I often think 'dear god, how is there so much code that does nothing, and how did it all get witten since I last had a chance to look'.

Makes me wonder if there are parallels in writing. My understanding is that the most prolific authors can only write 8 publishable pages a day. I'd bet that amateur writers can produce more pages than that, but no page could be published without at least as much time spent by an editor.

This, 100 times over! It is simply incredible how much code and how complex systems a junior dev (junior by knowledge, not by years of coding) can produce in a short time while you were looking the other way... :-D

Senior developers make sure to question their assumptions on a regular basis, FYI

I'm sure you're a quick learner but at least in scenarios I've worked in there are often many, many possible solutions and no specific "right answer."

After all, it's hard for anyone to be right all of the time.

A better point is that this drought of new talent is just the other side of the pendulum. In the odd years, the problem is layoffs and difficulty finding work without being a new-grad or knowing the latest tech fad. You've seen some of those summers, too?

If we both had to read the manual? Yeah, I'd still be faster. It's just as easy to cherry-pick for one side or another.

All this to say that we need to be careful that we don't point the finger too hard at management and miss our own failings. Software done well is incredibly hard and increasingly complex. Focusing on adding value and not on code/day can help us all stay focused on the real goal and what is best for us and the company and the customers. </r>

Every organization I've worked at (for the past 25 years) has relegated that rule to the much lower prestige, much lower paying, zero career path role of either "business analyst" or "project manager". If you can produce code, you'll be producing code - and by and large, that's the only way to have anything resembling a future unless you're on an upper management track.

I think this is a stereotype that will lead to more harm than good. What if a junior dev doesn't code just as fast or faster? Does that mean we hired the wrong junior dev? I agree we can should be open to junior developers, just implanting this stereotype is harmful