In my experience, it's much worse to deal with enthusiastic juniors.
Another especially bad take coming from the same company is 'move fast and break things', which is one of the most destructive pieces of advice in our industry.
We got Boeing software defects costing lives, SolarWind pwnages, the npm crashes, we got the Cloudstrike fiasco, Tesla self driving bugs, and who knows how many failures of software engineering. And we, the software engineers wanna be moving faster and breaking things? What happened to writing correct and reliable programs?
We want to somehow pretend we live in a world where junior devs' ideas are some hot takes that nobody has ever thought of before and encourage them to do things first and ask their team later? You guys do you, then.
> We want to somehow pretend we live in a world where junior devs' ideas are some hot takes that nobody has ever thought of before and encourage them to do things first and ask their team later?
Nobody suggested that. And nobody suggested using junior devs' code in critical components.
But I would much rather work with people who want to learn and aren't afraid to change things than old farts who prevent any improvement with the excuse that there's a non-zero chance that it will temporarily break something. It's so tedious.
> But I would much rather work with people who want to learn and aren't afraid to change things than old farts who prevent any improvement with the excuse that there's a non-zero chance that it will temporarily break something
The whole idea that juniors are somehow the people who know what improvements need to be made, and the seniors are the gatekeepers stopping them, is hilarious.
Juniors:
- don't know the domain
- juniors don't know why the existing ecosystem is how it is
- juniors probably can't even ascertain as good as a senior whether there is really a problem that actually needs solving
- hell, juniors don't even know half the capabilities of the language/framework/infrastructure you are using
Imagine that you are a teacher in school, and you find that somebody wrote a book "Whatever your teacher says, don't listen, just do what you feel like" and is actively pushing it to your students. That's what this BS "Ask advice, not permission" advice does to junior developers.
> It's so tedious.
It's tedious to have 3 junior engineers in a typescript/react shop, each from a different team, one wanting to rewrite everything in rust, one wanting to switch to deno, and one wanting to rewrite everything in vue, while there is no actual problem to solve.
This is a real situation that happened to somebody I know. And he, the senior, was the old fart, gatekeeping the great and always-learning juniors from all that potential rust greatness.
What if I come to your team and want to rewrite everything you have in Lua, and then complain when you "gatekeep" me?
There is seniority in software engineering, and in companies in general, so somebody can stop stupid ideas from proliferating and occupying the whole company's time. Sure, there is a problem of bureaucratic middle management that doesn't allow good ideas to come to fruition, but to not acknowledge that a huge percentage of ideas coming from juniors belong to the waste bin, that's just pure hypocrisy.
Ok you must work with much worse juniors than me (or have an enormous ego) because generally I find that they are more or less competent but inexperienced.
> What if I come to your team and want to rewrite everything you have in Lua, and then complain when you "gatekeep" me?
I would say "what's the benefit of that?" and if you can convince me then I would let you try rewriting part of it as an experiment. No gatekeeping.
But no junior devs I've worked with have suggested anything like that anyway.
"There's no other scripting language that makes it as easy to add scripting abilities to native applications.
It is lightweight, simple, easy to learn, and not that hard to master. You can use it for anything: as a substitute for ini or json files, or to code entire games in it. Just like JS, just easier to embed and easier to use.
LuaJIT, in the hands of a skilled programmer, is a marvel when it comes to performance."
(Taken from reddit, by the way)
At the end, we'd go over some things that are probably not okay in typescript and Lua does better, but we'd be missing the point. The whole idea that it's not worth to rewrite whole systems in Lua just because you don't like some syntactic sugar's absence in typescript is totally lost on a junior dev. You can convince them, of course, but probably not to a full extent, and you'd still be considered a gatekeeper.
> and if you can convince me then I would let you try rewriting part of it as an experiment
What's wrong with a straight up opinion and saying: "this is probably not a good idea, considering we have 30 repositories, all using typescript, and no in-house knowledge of Lua"? Why do we have to endlessly coddle people and mislead them?
Imagine this scenario: somebody asking you to do something ludicrous and you enabling them, multiplied by the number of junior developers you have, month after month, busy with new experiments. Eventually, you'd have to allow some of these proofs of concepts into the codebase, or they’ll realize you’re just leading them on, right? Congratulations, your 30 repo react/typescript codebase is now 15 different versions of react, vue and angular, Lua, python and rust rewrites, and they are deployed (or are they) randomly on all your major cloud providers.
This is how, by being afraid to assert authority and not wanting to appear as a “gatekeeper,” you end up on a slippery slope, allowing junior developers to do whatever they want and dragging the quality of the codebase and the velocity of your team with it. How many competing experiments can your teams juggle?
If the junior devs want to learn, they should do so on existing systems, trying to understand and improve them, rather than we all pretending they are god's gift to humanity and giving them entire systems to develop from scratch and wasting months of work on experimentation.
You are doing the junior devs a disservice by leading them on like this, imo it's much better to coach them why existing systems are how they are, and help them improve along the way.
Basically, you want juniors to work on critical components, but do not want the responsibility for the very predictable result of things not working. So, you want someone else to make the decision of assigning that junior and you want seniors then to parachute in to save the day ... while calling them old farts as they are telling you this was predictable and they said so.
The advice isn’t destructive, people applying it in the wrong context is. Engineering companies, software or otherwise, probably should know enough not to take advice from a web dev/social media company.
I’m not sure about moving fast in a safe environment. In general it might be good for the individual devs to have initiative. A safety critical code requires a safe process, which should not rely too much on the prudence of an individual developer. Have really good devs is not a plan, right?
In my experience, it's much worse to deal with enthusiastic juniors.
Another especially bad take coming from the same company is 'move fast and break things', which is one of the most destructive pieces of advice in our industry.
We got Boeing software defects costing lives, SolarWind pwnages, the npm crashes, we got the Cloudstrike fiasco, Tesla self driving bugs, and who knows how many failures of software engineering. And we, the software engineers wanna be moving faster and breaking things? What happened to writing correct and reliable programs?
We want to somehow pretend we live in a world where junior devs' ideas are some hot takes that nobody has ever thought of before and encourage them to do things first and ask their team later? You guys do you, then.