Comment by recursivedoubts
12 hours ago
As I tell my students: juniors, you must write the code
https://htmx.org/essays/yes-and/
Everyone else: we must let the juniors write the code.
Seniors come from juniors. If you want seniors, you must let the juniors write the code.
> Seniors come from juniors. If you want seniors, you must let the juniors write the code
The average tenure of a person in engineering role is so short that very few employers are thinking about developing individuals anymore.
The actual way this gets approached is "If you want seniors, you must hire seniors".
I'm not sure how this plays out now. But it's easy to imagine a scenario like the COBOL writers of the last generation.
It's a self inflicted wound. Companies do not reward loyalty. They do not give out raises congruent with what you can find if you leave. Business-types unirionically think seasonal layoffs is a "good thing." Self hemorrhaging your institutional knowledge is insanity
Is it? Seems to be working fine for most
1 reply →
The issue stems from 2 things:
1) People hearing "an LLM is as smart as a junior" and actually opting for the LLM subscription price instead of hiring a junior
2) The gap between senior and junior in terms of performance has become larger, since the senior devs had their hands get dirty for years typing stuff out manually AND also tackling challenges.
This generation of junior-mid developers will have a significant portion of the "typing stuff" chopped off, and we're still pretending that this will end up being fine.
I think your second point is interesting, and it has actually already happened a couple of times.
It used to be a lot easier to find devs that knew assembly and could navigate call stacks through memory by hand because a lot of folks had to learn that to get their job done. Now higher level languages have mostly eliminated that level of operation.
The same applies to infosec roles. It is 10x harder for junior infosec folks than 20 years ago because there are a bunch of skills you need in infosec that today's mainline dev experience doesn't need, but were more common a while ago.
Case in point, I remember working with a partner company's junior engineer on some integration. They needed some hard-coded constant changed and time was of the essence. I told them to change a couple bytes in the elf binary directly. They looked at me like I was a wizard. I thought it was a fairly pedestrian skill having grown up reversing computer game save files.
Hex editors are a black box to most 99% devs these days. I noticed their use falling off once code-signing came into use.
The challenge is to get cost sensitive businesses to support this. Juniors are a cost and when trained move on, thats the fundamental problem. Retention only works with smart companues, for most other companies its a revolving door.
On the plus side, as a dev with 30+ years of experience, I am commanding a very good contract salary these days. Revolving door companies stuck in process hell and product rot, and cannot deliver new value, so they’re scrambling to find experienced devs that cost a premium. My salary today makes up for peanuts at the start of my career.
The real question will be; Do we need to pay the juniors to write code to become seniors?
If coding is an art then all the juniors will end up in the same places as other struggling artists and only the breakout artists will land paying coding gigs.
I'm sitting here on a weekend coding a passion project for no pay so I have to wonder.
So non technical business people will hire vibe coded seniors?
> Seniors come from juniors. If you want seniors, you must let the juniors write the code.
Companies know this as well, but this is a prisoner dilemma type situation for them. A company can skip out on juniors, and instead offer to pay seniors a bit better to poach them from other companies, saving money. If everyone starts doing this, everyone obviously loses - there just won't be enough new seniors to satisfy demand. Avoiding this requires that most companies play by the rules so to say, not something that's easily achieved.
And the higher the cost of training juniors relative to their economic output, the greater the incentive to break the rules becomes.
One alternative might just be more strict non-competes and the like, to make it harder for employees to switch companies in the first place. But this is legally challenging and obviously not a great thing for employees in general.
The way other professions do this is by burying trainees with debt and then writing off debt if they stay.
See Revature.
Not every career path starts at a software first company. Not every software first company works on the most intense codebase.
And therefore in my experience not every senior engineer would hack it as a senior engineer at a more intense company myself included.
This isn’t a software unique experience. It’s life.
It’s already getting harder to find juniors willing to write the code and harder to discern whether someone is as willing as they say. And I feel like asking junior to make this decision and just have self control is a tricky double edged sword. Even if I want them to (and I do!) the competitive and ambitious juniors I suspect will still lean into AI code gen heavily as it makes them look better and seem more productive. Seniors probably need to do more than let them write the code, we probably need to figure out ways to encourage, require, or even enforce it at some level, if we want it to happen.
before you had a lesson that every engineer has to start with writing C, yet most of modern devs never did.
Seniors should be prepared that Seniority will mean different thing and path of getting there will be different too.
Just like there was a shift from lower lvl languages to high level
I agree with the sentiments here. But, I’m less hopeful about the presented solutions.
I think my argument against humans still needing to know how to manage complexity, is that the models will become increasingly able to manage that complexity themselves.
The only thing that backs up that argument is the rate of progress the models have made in the last 3 years (ChatGPT turned 3 just 3 months ago)
I think software people as a whole need to see that the capabilities won’t stop here, they’re going to keep growing. If you can describe it, an LLM will eventually be able to do it.
disagree because when the "super fast" new CPUs of 20 years ago became common, it was easy to write code that executed slower than previous code, due to language constructs and wasteful work patterns. Therefore, I predict that LLM code can explode in complexity (14KLOC for a binary file parser with some features) but that compute will bog down and effort to understand will explode.. that is, in extreme cases.
> If you want seniors, you must let the juniors write the code.
I do not want more juniors, because given time they will be my competition.
Ok but even pre ai I felt like each years interns wanted to take as many shortcuts as possible and not learn.
I think the allure of high TC (150k base or more for entry level) led to many non engineer brained people to enter tech.
Many people can do rote memorization, it’s even ingrained heavily in some cultures iykyk. However they can’t come up with much original or out of the box thinking.