"most developers identify as the average"

That is what average means

Let's make this more obvious: Imagine that in you have to produce Nitroglycerine, explosive set off by the slightest of mistakes.

Would you rather it done by someone superbly clever, but straight out of uni, or someone who's average, but has done it for 20 years and survived?

Well if you are happy that you found someone that can follow a checklist then fine. I doubt the top tier grad would want that type of job anyway.

Out of interest with your name Google234, are you a student or early employee? You seem to be very certain about things in your comments here but I'm unsure if they come from experience or speculation.

Do you know how many hundred top tier chemical and nuclear scientists died while "following the checklist"? Look up Demon Core

IIRC the work with Demon Core was described as "tickling the dragon's tail", not "following the checklist". Wikipedia also mentions "Slotin's own unapproved protocol".

You are right, it's a different point - just trying to illustrate that being some of the smartest people on earth doesnt mean you wont make a terrible mistake or will have good judgement.

Like they knew it was super dangerous, there wasn't new science discovered since then about this particular setup. Today rank and file engineers know not to do that

Also how could there be a checklist? They were literally pioneers

An easy way to create one would be to ask "what could go wrong" and "how bad would it be", then develop procedures to minimize the risk.

Not calling you out, but where did you get the number deaths > 100 from?

https://en.wikipedia.org/wiki/Criticality_accident

Problem was, there was no real checklist. They were part of a huge number of people who have created the checklists, partly as a result of lessons learned after making mistakes resulting in death and destruction.

1, you are now really exaggerating. 2, this analogy is really straying far from software engineering. 3, what is your point here?

Most senior engineers expect to be out paced by juniors in terms of raw throughout.

But what the seniors have over the juniors is several years of experience making mistakes.

“Raw throughput” like what? Mashing on the keyboard? Then - sure. Sorry but that’s just not true ime. On some tasks jrs are even infinitely slower than srs because they just can’t make any headway at all

On some tasks that’s true. I was making a generalisation rather than defining an absolute.

I’m having troubles imagining how more experienced eng could be slower than junior provided their code is reviewed and tested to the same standard. Unless the task is so soul crushingly rote that your senior is looking for another job rather than working on it ;)

Raw throughout isn’t the same as speed.

The senior might spend more time doing PRs (juniors might not feel as comfortable), more time in meetings discussing new projects or architecting around arising problems. A junior is generally more enthusiastic so might voluntarily work longer hours to close of tickets, or just take fewer coffee breaks than a senior. A senior might also spend a portion of their time training juniors.

I’m not saying a senior engineer can’t be a prolific at closing off tickets as a junior, but more seniority means more responsibility and that often means less time writing code.

But there are also occasions when I might genuinely expect a senior to be slower. Like if they’re in their mid to late 30s and have young children who aren’t sleeping. People say you shouldn’t bring your home problems to work but the reality is that we are not robots and if you’re not sleeping at home then you’re performance at work will suffer. Whereas most 20-somethings have fewer commitments outside of work.

If we are talking really senior, like 60s, then a sad fact of reality is our mental faculties aren’t going to be as sharp as they were when we were in our 20s. So it might take an engineer a little longer to solve complex problems than someone fresh out of uni. Particularly if it’s an academic problem that one might have studied at uni but seldom need in your career.

So there are plenty of mitigating factors that might affect the throughput of a senior engineer. But that doesn’t matter but you hire them for their experience rather than their youthful motivation. And it’s also why it is important to have a balanced team of junior and seniors.

I don't think that was the point. Rather, it's that many rookies, including bright graduates, think "meh, I can run this SQL script without making a backup first."

The hinge of this analysis is on the word "outperformed". Performance of what you're measuring exactly? If our sole performance criteria was churning out LOC and subsisting on adderall, any new grad can kick ass. But you wouldn't entrust them multi-million-dollar man-hours of headcount to a steer multi-quarter project to actually work and bring in money. Without such steering, any code is mere dead matter, for which the performance of making is irrelevant.