I think despite how much tech keeps getting hyped, the average person didn't have a 'technology' watershed moment in the past decade or more, so they're taking what they can get.
I think the idea of 'junior' needs to be refined a bit. By the time I got my first job I've been coding for years, and have built rather substantial things.
In fact, in terms of pure coding ability, I was probably past the initial, fast part of my growth.
As should have others, which the university education system should have made sure.
The fact that some people come out of 4+ years of software engineering education utterly clueless means that they somehow managed to dodge having to build anything, I think means that they will never get good at any point in time, as they either were very talented at dodging having to build things, and I don't think that talent is going to abandon them, or they couldn't really grasp the basics in an environment designed for just that.
With that said, I think you can see for most juniors, what you can expect out of them in terms of pure coding ability - sure a lot of them have room to grow, but I've met so many great people who were very young, yet were useful from day one.
In fact, if you have the willingness to grind away at some problem, that puts you ahead of a significant amount of the pack. I have had the misfortune of working with people who lacked any demonstrable skill, and had coping strategies for having to deal with any sort of hardship. Getting useful work out of them was a challenge in of itself.
These people managed to get the years in to be considered senior, and are probably dispensing their wisdom 'mentoring' juniors somewhere else, and are no longer expected to actually contribute to meaningful issues.
I'm not sure if enthusiasts are the exception rather than the norm? I've noticed in the last few years, a lot of junior engineers do not have much active coding experience outside of their university education, they aren't the traditional "obsessed with computers and programming as kids".
There has been a much higher demand for software developers over the past 10-15 years than there are people who are obsessed with computers and programming
If you look at the general topic shift on HN over the years it's obvious most people are getting into tech because they want power and money, not for love of tech
> If you look at the general topic shift on HN over the years it's obvious most people are getting into tech because they want power and money, not for love of tech
I think that is a bit presumptuous, even if there is a hint of truth there. Just because a kid didn't grow up around computers and programming shouldn't exclude them from the tech path or mark them as imposters/pretenders.
That is more a sign of our messed up society. Yes, techies earn middle class salaries that are hard for everyone else to earn, but the issue was everyone else falling behind, not techies racing ahead (our salaries are extravagant becuase…we can buy a house like our very normal salary parents could).
I agree it definitely distorts the market because what else are kids to do?
Even the statement that (100% safe) Rust does not have memory bugs/mutable aliasing is not always true.
It's well known that Rust has difficulty representing graph-like memory structures, and people have taken to using arrays of `Node`-s to represent graphs, where each graph edge represents a pointer to another node.
This both efficient, and fast, but this approach sidesteps the borrow checker.
If you had a method that 2 mutable `Node` references as parameters, the borrow checker would complain if they'd point to the same struct. If you pass 2 ints, it won't.
Likewise, since liveness is tracked by user logic, you can refer to stale, deallocated `Node`-s or ones that haven't been initialized yet.
I've had people argue this is not a true memory bug, since you're not causing 'real' memory faults, but in C, `malloc` is just a function that hands you pointers into chunks of pre-allocated memory space most of the time, when it doesn't have to ask the OS for more.
I know from experience some people see this criticism as an attack on their favourite language and instantly rebuke it.
But I'd like to argue that there's something there, and it bears thinking about how 'memory allocation exisitng outside Rust' and 'memory allocating existing inside Rust' behave differently might be seen as an interesting dicothomy that needs to be resolved and that resolution might improve Rust's (or some successor language's) memory model.
The difference is the checking, and actual enforcement of it.
Go and use get_unchecked if you want to and get C like behavior. But the safety note tells you the potential issues:
Safety
Calling this method with an out-of-bounds index is undefined behavior even if the resulting reference is not used.
You can think of this like .get(index).unwrap_unchecked(). It’s UB to call .get_unchecked(len), even if you immediately convert to a pointer. And it’s UB to call .get_unchecked(..len + 1), .get_unchecked(..=len), or similar.
The weird thing about this is many core Rust people agree that Rust is not the best language that could possibly ever be, even evaluated by the core principles of Rust (that is: no UB, no mutable aliasing, no memory bugs).
And if we move outside of Rust's memory model, some people have raised issues with the inconsistent syntax, and the module-based compilation model which makes compilers inherently slow, as you have to parse the whole module every time.
So there's room for improvement, and people are already working on putting ideas into practice, and some of these people who came from the Rust ecosystem itself.
And if you happen to disagree with Rust's core goals (or just place less emphasis on them), then it's obviously not the perfect language.
What coding with LLMs have taught me, particularly in a domain that's not super comfortable for me (web tech), is that how many npm packages (like jwt auth, or build plugins) can be replaced by a dozen lines of code.
And you can actually make sense of that code and be sure it does what you want it to.
We used to reuse code a lot. But then we got problems like diamond dependency hell. Why did we reuse code a lot? To save on labor. Now we don't have to.
So we might roll-your-own more things. But then we'll have a tremendous amount of code duplication, effectively, and bigger tech debt issues, minus the diamond dependency hell issue. It might be better this way; time will tell.
Not just to save on labour. To have confidence in a battle tested solution. To use something familiar to others. For compatibility. To exploit further development, debugging, and integration.
Speaking of rolling your own things, i had claude knock out a trello clone for me in 30 minutes because i was irritated at atlassian.
I am already using it for keeping track of personal stuff. I’m not going to make a product out of it or even put it on github. It’s just for me. There are gonna be a lot of single team/single user projects.
It is so fast to build working prototypes that it’s not even worth thinking if you should do something. Just ask claude to take a shot of it, get a cup of coffee and evaluate the results.
I'm sure after you've had Claude build it, you learned a ton of how to build such a thing (I certainly did for my projects).
Basically, the data model is dead simple, you just spin up a SQLite db, create a React frontend, grabbing a good drag and drop library that implements these cards, write some simple but decent looking CSS, some React and backend boilerplate to wire the thing together - and boom - you're done.
This sounds simple when I write like this, but the complexity comes from knowing what library to use, figuring out its API, and assembling the whole thing together - which Claude is great at, but once you see the whole thing put together, you come to understand these things as well, and become more skilled at building stuff like this.
But i don’t want to learn how to do that. I already know how to write code and i have built a bunch of production rust apps from scratch. I would prefer if i never have to write code. I don’t enjoy writing code, don’t take pride in having that skill. I enjoy the process of identifying a problem and producing a solution to that problem. Coding is just something i had to learn how to do in order to solve problems.
The absolute moment that ai is capable of producing all the useful code for a project I probably will never write another line of code again.
Yeah, that is the future isn't it? Because I've built the same thing for myself and have the same plans to not put in the work of sharing it with other people. It works for me and my friends and the contractors working on my house and I'm sure everyone else is doing it too!
So… this has been happening for a long time now. The baseline set of tools is a lot better than it used to be. Back in 2010, jQuery was the divine ruler of JSlandia. Nowadays, you would probably just throw your jQuery in the woodchipper and replace it with raw, unfinished, quartersawn JS straight from the mill.
I also used to have these massive sets of packages pieced together with RequireJS or Rollup or WebPack or whatever. Now it’s unnecessary.
(I wouldn’t dare swap out a JWT implementation with something Claude wrote, though.)
Sorry by, JWT, I meant the middleware that integrates the crypto nto my web server (pretty sure even Claude doesn't attempt to do hand-rolled crypto, thankfully).
That express middleware library has a ton of config options that were quite the headache to understand, and I realized that it's basically a couple hundred line skeleton that I spent more time customizing than it'd have taken from scratch.
As for old JS vs new JS - I have worked more in the enterprise world before, working with stuff like ASP.NET in that era.
Let me tell you a story - way back when I needed to change how a particular bit of configuration was read at startup in the ASP.NET server. I was astonished to find that the config logic (which was essentially just binding data from env vars and json to objects), was thousands upon thousands of lines of code, with a deep inheritance chain and probably an UML diagram that could've covered a football field.
I am super glad that that kind of software engineering lost out to simple and sensible solutions in the JS ecosystem. I am less glad that that simplicity is obscured and the first instinct of many JS devs is to reach for a package instead of understanding how the underlying system works, and how to extend it.
Which tbf is not their fault - even if simplicity exists, people still assume (I certainly did) that that JWT middleware library was a substantial piece of engineering, when it wasn't.
reply