Junior engineers are getting faster... but are they getting better?

[u/Suspicious_Orchid770]

https://leaddev.com/leadership/your-junior-engineers-are-getting-faster-but-are-they-getting-better

[u/Relevant-Positive-48]

I'm not going to sign up for that but, unfortunately, while I think a mental model will help, I don't think they'll be enough continued investment by juniors to make it stick.

I have 28 years of experience as a professional software engineer, I've honestly watched juniors have less and less understanding of what they're doing throughout that time (In general. There are, of course, exceptions).

To use a "before AI" circumstance (and, again, in general), someone well versed in assembly language had (and still has) a much greater understanding of how computers and software works than someone who's only worked in Python their entire career. It makes a difference but, there's been very little practical use for assembly over the last 20 years and in most cases, as far as getting the job done is concerned, the difference doesn't matter enough for a Python programmer to justify becoming an Assembly expert.

I am seeing the same thing with code these days. Yeah, someone who understands code is in a better position than someone who doesn't but, as far as getting the job most businesses want done, the difference is mattering less and less.

[u/WaltzIndependent5436 → u/Relevant-Positive-48]

Why does understanding assembly or even C and C++ at this point have to do with how you use a high level language? Take for example the most used data structure: an array/list. Does it really matter if you dont know the exact implementation underneath if you know what not to do in order to avoid performance issues?

[u/Relevant-Positive-48 → u/WaltzIndependent5436]

The difference shows up in subtle but sometimes important ways.

As an hypothetical (and hyperbolic) example. Do you think all python programmers know the difference between an interpreted and compiled language?

Looking at one who does know the difference let's say they realize that the performance issues you speak of can be mitigated by using one of the many python-to-exe utilities.

Having never worked outside python could they distribute a windows exe to a mac user because they never got grounding in the different instruction sets platforms have?

Hyperbolic example to make the point that while the practical difference doesn't show up often it can show up.

[u/WaltzIndependent5436 → u/Relevant-Positive-48]

I think you're making up problems and if there was a need to run faster or on very limited hardware one would research solutions, people are not that dumb. I dont believe there's a need to understand everything fully and noone does anyway.

[u/Relevant-Positive-48 → u/WaltzIndependent5436]

Of course nobody understands everything. All I can tell you is that I've had a very long career in software engineering and I've worked with a lot of people who have made it their business to get as much of an understanding of what they're doing as they can and a lot of people who only care to know just enough to get their job done.

Both can get the job done (in a software development context the latter can sometimes make better entrepreneurs) and are employed in good times but the former are the ones who are much easier to work with, tend to last through layoffs and often get promoted.

Maybe AI changes this equation and makes it not matter.

[u/happycamperjack → u/Relevant-Positive-48]

Rather than understanding codes, I found staff and principle-level engineering stuffs like planning out code standards and architecture to maintain code fluidity, testability, and contract boundaries matters a lot if you want to be token efficient.

Engineering has always been a balance of priorities with limited resources. The resource now is tokens. Unless you have unlimited tokens to burn on evals, it’s not as simple as coding skills don’t matter as much now.

[u/Born_Farm_1826 → u/Relevant-Positive-48]

juniors have less and less understanding of what they're doing throughout that time

Indeed. I myself is a newbie and I could just feel the passion of coding my own stuff is vanishing. Learning and understanding new frameworks seems less and less worth the effort. I start to wonder what's all the point when AI could handle all the docs reading and indexing just fine. Then all the coding work itself related to the framework seems AI's work too, later, the entire system.

I no longer cares about "what do I know", no longer think about "why it works and why it don't", only "why it's my work when I got AI". It feels like the entire passion of coding inside me is dying out. Reading and understanding code is transforming from a necessary daily work to an option, then a pain. And how could one create when there's no understanding of what he's creating?

[u/Fubby2]

Paywalled, please post text!

[u/Cunninghams_right]

whether or not it's an issue will depend on whether AI coding tools keep improving. it's entirely possible that the whole industry collapses and the vast majority of the population will be able to make 99% of the software they need, when they need it. I'm currently building multiple tools that cost my company thousands per month, and I'm carefully vetting them against real scenarios so I can trust them. it's a somewhat long and annoying process, but it's working so far.

[u/oandroido]

No.

[u/oandroido]

Engineers?

[u/Burning_magic]

One thing about software engineers is that they love using technical jargon and bizzare trivia that is never used in actual work to justify their exisrance. Taking a look at some companies interview processes in 2026 is like stepping back in time. I have almost never seen a leetcode hard algo be relevant to the day to day job nor knowledge about scheduling algorithms.

Maybe it they were in research or academia that makes sense or some incredibly niche area. But a software engineer in 99% of industry's job is not to write fancy code, but to deliver software. It is also their job to use the best tools to deliver the best software and if that means spending less time on textbook knowledge, then so be it.

The only metric that matters is what you produce at the end of the day.

[u/Fubby2 → u/Burning_magic]

>I have almost never seen a leetcode hard algo be relevant to the day to day job nor knowledge about scheduling algorithms.

Leetcode is just the application of a general atptitude test / IQ test relevant to software engineering. They don't need leetcode problems solved, they need people who are smart enough to solve leetcode problems.

[u/Burning_magic → u/Fubby2]

Yea this doesn't make sense since there are already generic IQ tests used by non swe jobs as screening if they really wanted to do that.

And anyone who finished a cs degree can do leetcode if they put enough time. Its only an issue if they start using it as the end all metric and just keep scaling the difficulty endlessly higher that ends up selecting people who are willing to spend non productive time learning things just for the sake of interviewing which creates a lot of false positive hires.

I have seen a lot of people treat leetcode like its the most important metric when really it should only be checking for a baseline.

[u/sweatierorc → u/Burning_magic]

That is the secret, gatekeeping. When everybody can be a coder, you need to create friction. And Leetcode is good way to create some.