I'm skeptical any public company is really going to have the strength to develop junior talent no matter how many experts say its important or what the long term consequences are. ShitCo A will slash headcount and see their stock go up 50%, investors & VCs at ShitCo B will ask why aren't we doing this and will soon follow. The same thing played out with all kinds of manufacturing industry jobs.
The track record in all industries for companies having well thought out plans to develop talent is pretty bad in the age of money. More likely they just fire the juniors, slowly lose seniors and pray for AGI to take over all coding. Maybe it does and they win, maybe it doesn't and they start panic hiring after 5 years.
The "citizen developer" framing assumes AI flattens the skill distribution but the data says the opposite. Next-token prediction and RLHF typicality bias mean AI converges to the mean, so domain experts get more valuable, not less.
> We must keep hiring EiC (i.e. newbies) developers, accept that they initially reduce capacity, and deliberately design systems that make their growth an explicit organizational goal. ...
this has always been the case - even the Mythical man-month stated so.
One has to allow some slack for the experts, essentially having them as teachers - as investment in future people. Which means - the system as it is should not change much in essence. Whether i talk to a junior about his own code or about some(body|thing)-else's code, should not be much difference to me, though it might be harder for the junior as s/he would not have been internalising/producing the code but only gazing at it. Probably there should be some work done manually, maybe in parallel to the automated one, regardless of the speed, for the sake of learning by doing.
IMO the suggested structure of preceptors (i.e. mentors) with students can be separate only for a short term but then has to be embedded in the usual projects etc work, for much longer time. Which again is what we have now, though it has to be named and made explicit and not hand-waved, or there would be a lot of "spent-3-years-but-learned-nothing" people.
I'm skeptical any public company is really going to have the strength to develop junior talent no matter how many experts say its important or what the long term consequences are. ShitCo A will slash headcount and see their stock go up 50%, investors & VCs at ShitCo B will ask why aren't we doing this and will soon follow. The same thing played out with all kinds of manufacturing industry jobs.
The track record in all industries for companies having well thought out plans to develop talent is pretty bad in the age of money. More likely they just fire the juniors, slowly lose seniors and pray for AGI to take over all coding. Maybe it does and they win, maybe it doesn't and they start panic hiring after 5 years.
Is this any different than pre-ai?
The "citizen developer" framing assumes AI flattens the skill distribution but the data says the opposite. Next-token prediction and RLHF typicality bias mean AI converges to the mean, so domain experts get more valuable, not less.
Centaur setups keep beating AI-only on things like Humanity's Last Exam. I wrote about this: https://philippdubach.com/posts/a-bull-case/
Also worth noting the Jevons paradox angle. AI doesn't reduce engineering workload, it expands it. 77% of employees in one survey said AI added to their work: https://philippdubach.com/posts/does-ai-mean-the-demand-on-l...
Mark Russinovich and Scott Hanselman are both prolific engineers and content creators.
Russinovich wrote SysInternals, which I remember using like 25 years ago to figure out what ran on startup.
Hanselman has a pretty popular podcast, Hanselminutes, that's been running for years and years.
> We must keep hiring EiC (i.e. newbies) developers, accept that they initially reduce capacity, and deliberately design systems that make their growth an explicit organizational goal. ...
this has always been the case - even the Mythical man-month stated so.
One has to allow some slack for the experts, essentially having them as teachers - as investment in future people. Which means - the system as it is should not change much in essence. Whether i talk to a junior about his own code or about some(body|thing)-else's code, should not be much difference to me, though it might be harder for the junior as s/he would not have been internalising/producing the code but only gazing at it. Probably there should be some work done manually, maybe in parallel to the automated one, regardless of the speed, for the sake of learning by doing.
IMO the suggested structure of preceptors (i.e. mentors) with students can be separate only for a short term but then has to be embedded in the usual projects etc work, for much longer time. Which again is what we have now, though it has to be named and made explicit and not hand-waved, or there would be a lot of "spent-3-years-but-learned-nothing" people.