6 ms·

I know exactly why you’re being downvoted: most developers identify as the average experienced developer and can’t handle the fact that they can be outperformed

by emsy 5y ago

I know exactly why you’re being downvoted: most developers identify as the average experienced developer and can’t handle the fact that they can be outperformed by an extraordinary rookie (although such people usually have a lot of experience from working in their free time).

tgv 5y ago
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."
ClumsyPilot 5y ago
"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?
- Google234 5y ago
  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.
  - ClumsyPilot 5y ago
    Do you know how many hundred top tier chemical and nuclear scientists died while "following the checklist"? Look up Demon Core
    - Google234 5y ago
      1, you are now really exaggerating. 2, this analogy is really straying far from software engineering. 3, what is your point here?
    - oriolid 5y ago
      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".
      - Google234 5y ago
        Also how could there be a checklist? They were literally pioneers
        oriolid 5y ago
        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.
      - ClumsyPilot 5y ago
        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
    - RichardCA 5y ago
      Not calling you out, but where did you get the number deaths > 100 from? https://en.wikipedia.org/wiki/Criticality_accident https://en.wikipedia.org/wiki/Criticality_accident
    - chha 5y ago
      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.
  - exdsq 5y ago
    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.
laumars 5y ago
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.
- dilyevsky 5y ago
  “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
  - laumars 5y ago
    On some tasks that’s true. I was making a generalisation rather than defining an absolute.
    - dilyevsky 5y ago
      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 ;)
      - laumars 5y ago
        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.
acituan 5y ago
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.

by emsy 5y ago

tgv 5y ago

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."

ClumsyPilot 5y ago

"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?

Google234 5y ago
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.
- ClumsyPilot 5y ago
  Do you know how many hundred top tier chemical and nuclear scientists died while "following the checklist"? Look up Demon Core
  - Google234 5y ago
    1, you are now really exaggerating. 2, this analogy is really straying far from software engineering. 3, what is your point here?
  - oriolid 5y ago
    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".
    - Google234 5y ago
      Also how could there be a checklist? They were literally pioneers
      - oriolid 5y ago
        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.
    - ClumsyPilot 5y ago
      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
  - RichardCA 5y ago
    Not calling you out, but where did you get the number deaths > 100 from? https://en.wikipedia.org/wiki/Criticality_accident https://en.wikipedia.org/wiki/Criticality_accident
  - chha 5y ago
    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.
- exdsq 5y ago
  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.

laumars 5y ago

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.

dilyevsky 5y ago
“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
- laumars 5y ago
  On some tasks that’s true. I was making a generalisation rather than defining an absolute.
  - dilyevsky 5y ago
    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 ;)
    - laumars 5y ago
      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.

acituan 5y ago

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.