[quickthrower2]

Hold on! The construction analogy doesn’t apply because in a lot of code bases, probably most there are very few menial tasks. Some code bases need IQ 120 + to do anything non trivial in and maybe even higher.

So there are menial tasks, but menial like “yeah just redraft this architectural drawing for me mate, to take account of the new 2021 fire regs, I got actual brainy stuff to get on with”.

Pairing senior and junior devs works. But not because the junior is an idiot, but because they have stuff to learn and raw talent and can figure stiff out. They probably already know how to code well from their passion or maybe bootcamps or interning. Not from university usually unless there is lot of coursework.

I am not saying construction workers are idiots. But I am saying the OP article is implying the worst employees are left by this dead sea effect. Are you saying you can absorb untalented people on work sites. In dev teams they slow things down it would be better to pay some of them garden leave.

[economicalidea]

I disagree with your point that this analogy does not apply.

You say there are some codebases that need over 9000 IQ to do anything. While that might be true, it is not the norm and a small fraction, so it’s not relevant to the broader argument.

You say it’s completely different in programming. Sure it doesn’t help if one of your workers is a complete idiot — but that was not the premise - it was unskilled but energetic.

And there are always menial tasks to do — you pointed out some example yourself.

So to sum up my points are: - most codebases do not require gigabrain for every single change

- there are always menial tasks to be done in a team environment

- “untalented” people don’t necessarily slow things down in development

- in fact talent is irrelevant when writing code - I would even argue that being talented is not always an advantage, in any field or profession - but that last point probably would need some more explanation.

[forgetfreeman]

100% of the most catastrophic IT disasters I've witnessed have been directly attributable to the most intelligent and skilled programmers I've worked with.

Example 1: I got hired to work in the dev department at a large regional printing company. One of the suites of software built in-house took large retail clients orders for printed store display material. From the client's initial order the software would automatically detail print batch sizes, assign these to the work queue, and would then go on to figure out how many of each type of display needed to be boxed and shipped to each of the client's retail locations and would create shipping labels, packing lists, etc. from this. At it's heart was a 10 page long SQL query that I couldn't make heads or tails of after two weeks spent studying it. I left the company certain of two things: 1. the dev that wrote that was one of the 3 smartest people I've ever met and 2. when he left the company they had literally zero chance of ever hiring someone to maintain that system.

Example 2: I got hired by the 2nd largest print media conglomerate in North America to help manage a fleet of 31 newspaper websites and a fleet of 125 niche verticals. This was at a time when the industry was just beginning to come to terms with their revenue models being gutted by craigslist and the shift to online marketing. To say the least money was tight. It was decided that the back-end systems that drove the integration between newsroom terminals, printroom layout qeues, and the newspapers' websites needed updating.

They hired #2 on my list of top 3 most intelligent people I've ever met to drive a complete overhaul of the system. It was decided a complete rewrite in a cutting-edge language was called for. The guy in charge didn't sleep for 3 days after which he'd provably onboarded and synthesized a complete understanding of the chosen language and it's ecosystem despite no prior experience, then went on to single-handedly rearchitect (feature complete) a system with roughly the same LoC as an operating system. In six weeks.

Over the course of the next 18 months the dev department responsible for implementing this masterwork (no sarcasm) floundered and the project was eventually scrapped having blown through the entirety of it's original 2M budget with literally nothing of use or note to show for it. Apparently nobody else on the team was capable of implementing and debugging the blizzard of microservices the new architecture called for.

My key takeaways: proposals to make codebases "interesting" should be met with deep skepticism if not outright hostility, and a roomfull of mid-level developers are significantly less likely to get an organization into deep trouble than a single rockstar with the bit between their teeth.

[throwawayqqq11]

> Pairing senior and junior devs works. But not because the junior is an idiot, but because they have stuff to learn.

I agree so much. The "dead sea effect" or whatever is just a lack of knowledge transfer. This problem remains over time too, eg look at the use of Cobol in the banking sector. Newer talents dont tend to learn old stuff. So what else is left for management to do in the long term than document really good and train newbies. If you think "migration", consider the timing, when the lack of knowledge already becomes pressing.

[082349872349872]

To be specific on the garden leave: "[run to the truck] for some nails" is easy to formulate yet takes effort to do. The majority of the effort for most coding tasks is the formulation, and by the time you've explained to the lame duck how to do what needs to be done, and checked that they actually did it, it would've been easier to have done it yourself.

(were one to have suitable lame duck tasks, how would wetware lame ducks compete in an LLM world?)

[economicalidea]

This is where working at an actual construction site would be a good experience for you — or any developer really.

Run to the truck and get nails also requires explanation/experience to get right if you have never done it before — what nails?which truck?how many?etc.

It is completely the same thing. The first time around you might have to explain the menial tasks in detail - btw a good exercise anyway, since you need to be able to explain aka understand the task anyway, after all you need to review later. And the first time around there will be some mistakes or misunderstandings.

But it gets better over time. With everyone.

[KineticLensman]

> Run to the truck and get nails also requires explanation/experience to get right if you have never done it before

After retiring from IT I volunteered at a raptor conservation centre. My previous experience counted for nothing and I was given numerous menial tasks: clean that water bowl, chop down that overhanging branch, sweep out that pond, re-attach that broken perch, put a trailer on the ATV and take this rubbish to the dump area, clean that aviary back wall, operate the music for the 11.30 display, etc.

After doing this for a while I had great experience of how the place actually ran, where things were kept, when it was safe to do things without interrupting flying, etc. I knew I was getting somewhere when my tasks started being looking after work-experience students, inducting new volunteers, helping in the displays, etc. It was actually quite humbling being a complete newbie again and having to go up new learning curves. I wish I had done it sooner in terms of resetting my objectives of what work actually involved.

[082349872349872]

You've just described a "junior"; I had mistakenly thought your "lame duck" was referring to the "salt" in TFA, who, on a useful timescale, do not get better.

Remember, for us the machine already plays the gofer role: handling menial tasks.

[SideburnsOfDoom]

> Some code bases need IQ 120 + to do anything non trivial in and maybe even higher.

And in the majority of cases, I would say that this is "accidental complexity" - i.e. it can and should be otherwise, and calling out the unnecessary cognitive load, is a benefit.

[Terr_]

> not because the junior is an idiot, but because they have stuff to learn

There's also value--sometimes hard to capture--in getting an external perspective on things. In a sense, they are a new user/customer for internal systems and processes, and can identify pain points that veterans have largely learned to ignore or bypass.

[forgetfreeman]

Couple of things.

1. The author said IT departments. This ostensibly includes everything from software development to systems admininstration, vendor management, and end-user support. Plenty of drudge work to be found there.

2. If your codebase requires someone to be on the edge of the bell curve of human intelligence to work on it is almost certain that mistakes have been made by very smart people.

3. The author is absolutely implying that the worst people are left, which is entirely my point. They have most likely never encountered the idea that managing folks to their strengths is more effective than trying to cram the room full of edge-of-the-bell-curve unicorns.