Comment by jmalicki
6 hours ago
> How do you think engineers in the second half got there? By writing tons and tons of code to "build those reps" and gain that experience.
It's not by writing syntax that you get there. It's by creating software and gaining the experience of seeing it go wrong.
"Good judgement comes from experience. Experience comes from bad judgement."
AI just shortens the cycle without needing to type out syntax, so you get even more iterations, faster, and learn the lessons more quickly.
Some do not learn from that experience. They were never going to learn without AI either.
> It's not by writing syntax that you get there.
Writing syntax is still an important part of the experience. It is valuable because it requires you to spend time immersed in the nuts and bolts that hold software together. I'd compare it to cooking, if you have an assistant or a machine do everything and you never actually touch a knife or stir a pot, you'll lose your touch. But there is also something valuable about covering more ground and the additional experience that brings.
Totally! I mean, the same could be said of painstakingly hand coding assembly language - that today's developers haven't done so is what leads us to bloated electron apps, so there is something lost!
But the larger scale system design is stronger than ever. Today, distributed systems, version control, including branching, stacked PRs etc., VMs/containers, idempotency, multimaster ACID databases, all of these things were probably never achievable in the world when the best devs had to spend their time poring over assembly language every day. Losing that skill allowed them more time to build other ones!
Why are you focusing on syntax so much? There's more to that when writing code.
That's why students learn how to write pseudo-code before picking up a programming language. Learning how to think through implementing a solution to a problem is extremely important. It's exactly this experience that helps engineers grow their scope and understand bigger, more complex system.
There's also the tactical components of using programming languages. The only way to know when to use one type of data structure over another, or to debug tricky language-specific behavior is _to actually have used that language._
And it's exactly this knowledge that's being threatened by LLMs given how they are implemented today.
Data structures are not tactical components of programming languages.
E.g. when I am writing SQL, I need to be thinking about the underlying data structures too - even though I am not specifying the execution path.
You can lead a horse to water, but you can't make it drink.