Live data from Hacker News

New junior developers can’t code

nmn.gl

121–130 of 138 posts

Re: New junior developers can’t code

#121
post #120
post #118

Earlier quoted context omitted.

>I assume that 20-30 years ago when juniors were using either ide-provided auto-completion or refactoring or gui designers some old graybeard developer had a similar reaction. You assume wrong. Source: was there at the time. This time is genuinely different.

it's always "different this time"

Never before has a technology enabled kids to pass every high school class just by using it without learning anything. Calculators just solved a small part of math etc, this kind of technological change has never ever even close to happened before.

Maybe the kids will be fine anyway, but you can't say this time isn't different, it is different regardless of the outcome.

Re: New junior developers can’t code

#122
post #112
post #101

Earlier quoted context omitted.

They’re not black boxes at all. The code is all there and is deterministic. Sorry, but the peculiarities of one optimization level on one implementation of C do not affect my point at all.

I already said they are technically not black boxes. We are not in disagreement here. The fact that code is all there and deterministic isn't sufficient. People use newer versions of compilers and you can't predict what the people who write compilers will do (people are black boxes). The compilers may do something you don't expect but still conform to the spec. The point is that there is no one implementation of C. A…

> I already said they are technically not black boxes. We are not in disagreement here.

I’m saying they are not black boxes at all. Not just “technically”

> The point is that there is no one implementation of C. And the same is true for any other language too (to a lesser extent).

That doesn’t matter for my argument.

> It doesn't matter whether they are black boxes if you don't routinely inspect the boxes. Perhaps you do, but for most people they don't. So it doesn't matter as much.

It does matter. That’s my whole point.

For two main reasons:

First, you have the option to understand how a compiler translates C to assembly. You do NOT have that option with LLMs

With a compiler, you are abstracting the underlying machine code, but you’re not hiding it entirely.

Secondly, with an LLM there’s no tractable connection between your prompt and your code. That’s a huge issue when it comes to understanding the resulting program.

Imagine a world where LLMs turn raw language into assembly (or, more realistically, LLVM IR)

How would you reason about your resulting program?

You could give the same prompt to the same LLM and get wildly different resulting code, since LLMs are nondeterministic.

How would you debug? How would you ensure that small changes to your LLM prompt doesn’t change parts of your resulting code that worked well?

How would you even understand what your program is doing?

You couldn’t do any of those things, because there’s no deterministic relationship between the prompt and the resulting program.

Re: New junior developers can’t code

#123
post #120
post #118

Earlier quoted context omitted.

>I assume that 20-30 years ago when juniors were using either ide-provided auto-completion or refactoring or gui designers some old graybeard developer had a similar reaction. You assume wrong. Source: was there at the time. This time is genuinely different.

it's always "different this time"

> it's always "different this time"

If you're extrapolating from a sample size of one massively disruptive workflow innovation, then of course, it's natural to assume if you've seen one you've seen them all.

That said, a few examples of disruptive workflow innovations from the past, from someone who was there at the time:

IDE's - gray beards didn't say they made you stupid, they said they didn't like them.

Memory managed languages - gray beards didn't say they made you stupid, they said they didn't like them.

Spell checkers and grammar assist - gray beards didn't say they made you stupid, they said they didn't like them.

Source control systems - gray beards didn't say they made you stupid, they said they loved the concept but they didn't like the one being used on the project (regardless of what it was).

Object oriented programming - gray beards didn't say they made you stupid, they immediately listed it as a skill on their resume.

GUI builders - gray beards didn't say they made you stupid, they actually liked them when they were new (there is probably one from a billion years ago they still think we should all be using today).

Digital readouts on machine tools (yes, massive disruptive workflow innovation) - gray beards didn't say they made you stupid, they said you should absolutely use them.

Calculators (when they were actually new) - gray beards didn't say they made you stupid, they competed to see who could use them the fastest (backlash against them came much, much later).

This one is different. Yes, you should absolutely use it, and yes, if you aren't careful, it risks making you stupid.

Re: New junior developers can’t code

#124
post #63

Earlier quoted context omitted.

Old people have been complaining about the youth for 2000 years but THIS time they're right.

So the youth are always correct and always an improvement?

Always is too strong of a word but if you look at the history of human development I'd say that in general each generation is an incremental improvement over the previous one.

Re: New junior developers can’t code

#125

Earlier quoted context omitted.

This comparison of coding assistants to Stack Overflow comes up a lot so I feel like it needs to be addressed. It is SIMILAR - it is not the same. There's a minimal element of interaction by virtue of the fact that SO code is usually not completely bespoke for the developer's requirements. They'll need to do things like change variable names, re-arrange some parts of it, etc. The junior dev using an integrated LLMs (…

Also, Stack Overflow regularly came with multiple solutions and comments on each solution discussing drawbacks and alternatives. I've learned a lot from those.

And a lot more likely to (often correctly) say "you should not do this thing".

Re: New junior developers can’t code

#126

The reason why these articles appear every 5 years is because many engineers pride themselves on how they solve problems. And then when they see people solving those problems without putting in the hard work that they had to put in, it really bothers them. This is a timeless post. We'll see it today. We'll see it in five years. We'll see it in 10 years.

Yes. Ten years ago some friends asked me to teach PHP to them, I showed them the book I learned from 20 years ago. It had 1200 pages and you could learn web development and MySQL without using the Internet. No one used that book. They searched for easy ingestable tutorials and went from there. After a year, some of them actually wrote software in production. I can't know if more or less of them would be able to write…

Some people learn better by doing rather than getting info dumped.

Re: New junior developers can’t code

#127
post #123
post #120

Earlier quoted context omitted.

it's always "different this time"

> it's always "different this time" If you're extrapolating from a sample size of one massively disruptive workflow innovation, then of course, it's natural to assume if you've seen one you've seen them all. That said, a few examples of disruptive workflow innovations from the past, from someone who was there at the time: IDE's - gray beards didn't say they made you stupid, they said they didn't like them. Memory man…

> GUI builders - gray beards didn't say they made you stupid, they actually liked them when they were new (there is probably one from a billion years ago they still think we should all be using today).

oh I remember the bashing agaist dreamweaver (and frontpage) in the early 2000s because it allowed people to make decent looking web pages without learning html.

> Calculators (when they were actually new) - gray beards didn't say they made you stupid, they competed to see who could use them the fastest (backlash against them came much, much later).

that was not my experience in school, quite the contrary: my teacher kept saying things like "you won't always have a calculator with you" (joke's on her, we how have computers with computing power that could compete a whole rack of the early 90ies in our pockets, pretty much always with us).

> when they were actually new

it doesn't have to be actually new, the discourse applies to tech that has just become available at the general public (not to over-specialized people with budget to acquire or license it)

Re: New junior developers can’t code

#128
post #7

It's like relying on a GPS to go everywhere you need. You will quickly find out you don't know to go anywhere by yourself.

... and maybe that's OK? I've been reliant on GPS on my phone for probably over a decade now. I'm probably lost without it. But... I explore way more of the world now! I'll quite happily bounce around to random parts of a city that's completely foreign to me, safe in the knowledge that I'll always be able to find my way back again. (I don't know if this analogy will hold up for AI-assisted programming - I still think…

> I'm definitely not going to ditch my GPS in an attempt to improve my sans-GPS navigation skills.

Maybe you should, if Eleanor Maguire's research on "The Knowledge" and the hippocampus has any bearing.

https://www.nytimes.com/2025/02/14/science/eleanor-maguire-d...

Re: New junior developers can’t code

#129

The reason why these articles appear every 5 years is because many engineers pride themselves on how they solve problems. And then when they see people solving those problems without putting in the hard work that they had to put in, it really bothers them. This is a timeless post. We'll see it today. We'll see it in five years. We'll see it in 10 years.

Yes. Ten years ago some friends asked me to teach PHP to them, I showed them the book I learned from 20 years ago. It had 1200 pages and you could learn web development and MySQL without using the Internet. No one used that book. They searched for easy ingestable tutorials and went from there. After a year, some of them actually wrote software in production. I can't know if more or less of them would be able to write…

Hehe, in 2000 I bought the 2nd edition of the book "Beginning Linux Programming (Programmer to programmer series)" [1] and learnt so much about Linux programming, and programming in general.

For us people 40+, even "Stack Overflow" was the easy/lazy way to get knowledge. There was something called expertsexchange.com at some point in the 2000 (but it became pay-walled at some point). But generally, downloading PDFs from Emule or going to the library was THE way to learn.

Fortunately, nowadays we have LLMs and tools that are way better. No regrets, and I am so happy to live in this era.

[1] Beginning Linux Programming (Programmer to Programmer) 2nd edition by Stones, Richard, Matthew, Neil (2000) Paperback

Re: New junior developers can’t code

#130
post #122
post #112

Earlier quoted context omitted.

I already said they are technically not black boxes. We are not in disagreement here. The fact that code is all there and deterministic isn't sufficient. People use newer versions of compilers and you can't predict what the people who write compilers will do (people are black boxes). The compilers may do something you don't expect but still conform to the spec. The point is that there is no one implementation of C. A…

> I already said they are technically not black boxes. We are not in disagreement here. I’m saying they are not black boxes at all. Not just “technically” > The point is that there is no one implementation of C. And the same is true for any other language too (to a lesser extent). That doesn’t matter for my argument. > It doesn't matter whether they are black boxes if you don't routinely inspect the boxes. Perhaps yo…

LLMs can be deterministic if you set the temp to zero.

It's not feasibly debuggable though, I'll give you that.

On this point it's not really different in principle from having a non-OSS compiler. Using OSS compilers are great because you can look at the source and trace problems and fix them, but people also use closed source compilers in their work too.

Post reply on HN