7 ms·

If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial gr

by czep 10y ago

If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times? If you were wrongly convicted and awaiting a death sentence, would you pick a 22 year old attorney fresh from law school to defend you? If you have a field full of tomatoes that needs picking, do you save a few dollars an hour hiring the young guy at minimum wage who is healthy, has no family, and will easily work beyond maximum hours without reporting it, or do you hire the older tomato picker who needs a higher salary because of his kids and can't work more than 7.5 hours a day because of his bad back? So are we law and medicine or are we tomato pickers? I had always thought of engineering as the former but sadly the more articles I see on how "culture fit" discrimination works, maybe we've commoditized the industry into a low wage manual labor job.

witty_username 10y ago
> If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times? Rationally one would care about the outcomes, and the number of times would merely make us more certain about the outcome. Relative to the two scenarios you showed, programming is usually more like tomato picking—nobody is going to die or be injured because of a bug or failure to deliver something.
- sharemywin 10y ago
  self driving cars.
- ojbyrne 10y ago
  Perhaps most of the time that's true, I suspect that a lot of health care is the same. There have been plenty of instances of software bugs killing or injuring people: https://en.wikipedia.org/wiki/List_of_software_bugs https://en.wikipedia.org/wiki/List_of_software_bugs
- pmoriarty 10y ago
  "nobody is going to die or be injured because of a bug or failure to deliver something" You should read through RISKS Digest.[1] [1] - https://en.wikipedia.org/wiki/Risks_digest https://en.wikipedia.org/wiki/Risks_digest
rubber_duck 10y ago
Umm the more comparable parable would be "or the proverbial graybeard who has done ~~it~~ kidney surgery a thousand times" The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. Like holly shit most people weren't even using source control back, unit testing and automated testing in general was SciFi, it was done by QA departments if you were big enough to do it. People were writing C and the major problems of the industry were how to fit shit in to x MB of ram and x CPU cycles. Security was abysmal - you didn't even have process isolation on OS-es. The languages and the practices are also completely different - disregarding the "we did it in the 60s with LISP in this paper" crowd - outside of academia people were just getting in to the OOP which was the pinnacle of abstractions back then. This is the drag&drop and copy-paste as an abstraction VB shit era. Unless you were at one of the cutting edge places that were actually innovating back then in terms of process and stuff there's likely nothing from that skill set that transfers on to the problems that we are dealing with today beyond the CS grad basics.
- clockwerx 10y ago
  Stuff that hasnt changed markedly: geometry math, statistics. SQL - 1970s. SOLID - parts of that are late 1980. C still looks like C. Unix like environments. Awk/sed/etc. Go read about the history of the web or XML; you get a very strong sense that these things have been thought about for a long time - data interchange has varied formats, but there is still a lot of tedious ETL type work. The importance of naming things well hasnt changed. Identifiers for data being a hard thing hasnt changed. Schema/vocabularies and more are still important problems. If you cant see some of these things underpinning much of the work we do, you might be missing the forest for the trees
  - bshimmin 10y ago
    One thing I've found that's significantly changed since I began my career, before my beard went grey, is that projects are now in general run much better. People never make a total mess of estimating timings, and the Agile methodology (and Kanban boards, and Trello, and JIRA, and of course Slack) really fix all organisational and prioritisation problems such that projects never end in disaster; gone are the days of frantic last minute firefighting and all-nighters, as we desperately work out which features are critical to getting the project live before everything explodes. Clearly the experience of older, wiser heads in moments of crisis is now basically never required because projects run so smoothly. Haha, sorry, I'm only kidding.
omginternets 10y ago
>So are we law and medicine or are we tomato pickers? There's engineering and engineering. Making apps using electron.js and writing high-frequency trading software isn't the same gig. I think much of the problem described by the parent comment falls upon those programmers doing the former.
pc86 10y ago
> If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times? I can make ridiculous scenarios too. If the cardiac surgery is using the latest technology, which the younger surgeon had used all 4 times successfully, and the older surgeon had used once and killed the patient? This idea that being around since COBOL = smarter/better/"we GTD while they sit around doing nothing for 16 hours" is idiotic and not at all based in reality.
Spooky23 10y ago
Churning out code usually isn't engineering, and it isn't tomato picking. It's more like being a machinist in an industrial setting. You need to know the tools and how to read the spec. That's why you can post a technology position, get 1,000 resumes from people working professionally, and find that 80% of the candidates lack basic knowledge. The problem is that if you don't up your game to be in a more engineering-y role, you're just one ROI calculation away from being automated out of existence.
coldtea 10y ago
>If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times? If you were hiring, you would want the starry eyed, finger in the pulse of latest fads, young programmer you can pay less, overwork, boss around, and screw over, or the senior engineer, who values sane hours and time with family, doesn't blindly adopt any BS fad technology you want them to use, and demands salary that matches their experience? Especially if the first can still get out something that "kinda works" and you could not give a rats arse about technical debt and bad decisions behind the UI facade?
- Roboprog 10y ago
  Soooo.... Tomato pickers it is! :-) Good counterpoint, liked both this and the grandparent comment. Ouch.
- AnimalMuppet 10y ago
  If that's what the hiring person is like, though, I'm fine with not getting that job...
  - coldtea 10y ago
    As long as there are enough other good programming gigs available though... As in, most McDonalds workers also hate both the hiring person AND the job, but they do it anyway.
  - clifanatic 10y ago
    - until that's _all_ there is.
WalterSear 10y ago
>If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times? http://www.npr.org/sections/health-shots/2014/12/22/372508398/is-your-heart-doctor-in-if-not-you-might-not-be-any-worse-off http://www.npr.org/sections/health-shots/2014/12/22/37250839...
Gracana 10y ago
The vast majority of software engineering work does not have the same rigor that other fields of engineering do. Standards, safety, inspection, accountability, documentation, testing, certification, etc... many other fields focus on these things, but in software it's pretty much "anything goes so long as we make money." The trick to making companies value good engineers is getting them to value good engineering.
carbocation 10y ago
As a cardiologist, I would prefer to refer my patients to the cardiac surgeon who is the most skilled, regardless of their time out of training. Similarly, I don't think that a programmer's age tells me much.
surge 10y ago
Weirdly, the mortality rates from surgeries can go up with much older doctors, for a variety of reasons, but mostly because they have lower volume of work so aren't as in practice and may not be current on latest techniques that may be less invasive or higher success rate. It could also be older people like having older doctors and the mortality rate is higher with older people getting surgery. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1856535/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1856535/ There is probably a statistical sweet spot, where someone has years of experience, is active enough to be up on the latest techniques, or at least learns the new techniques and adopts them. Parallels can be drawn between this and tech workers I'm sure.
sotojuan 10y ago
Engineering might be the former. Programming and software "engineering" is definitely the latter.
pfarnsworth 10y ago
If you were building a team to win the Super Bowl, would you pick the hot shot 23 year old fresh grad from college, or the 50 year old experienced Hall of Famer?
- Shebanator 10y ago
  50 year old hall of famer? Its rare for a QB to make it to 40 years old in the NFL. Peyton Manning retired at 39 years old after he won the Super Bowl last year, and he was considered ancient and past his prime despite that achievement. Furthermore, I just looked it up, and the oldest player to ever have played in the league was George Blanda, who retired at age 48. http://www.profootballhof.com/football-history/40-and-over-club/ http://www.profootballhof.com/football-history/40-and-over-c...

by czep 10y ago

witty_username 10y ago

> If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times? Rationally one would care about the outcomes, and the number of times would merely make us more certain about the outcome. Relative to the two scenarios you showed, programming is usually more like tomato picking—nobody is going to die or be injured because of a bug or failure to deliver something.

sharemywin 10y ago
self driving cars.
ojbyrne 10y ago
Perhaps most of the time that's true, I suspect that a lot of health care is the same. There have been plenty of instances of software bugs killing or injuring people: https://en.wikipedia.org/wiki/List_of_software_bugs https://en.wikipedia.org/wiki/List_of_software_bugs
pmoriarty 10y ago
"nobody is going to die or be injured because of a bug or failure to deliver something" You should read through RISKS Digest.[1] [1] - https://en.wikipedia.org/wiki/Risks_digest https://en.wikipedia.org/wiki/Risks_digest

rubber_duck 10y ago

Umm the more comparable parable would be "or the proverbial graybeard who has done ~~it~~ kidney surgery a thousand times" The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today. Like holly shit most people weren't even using source control back, unit testing and automated testing in general was SciFi, it was done by QA departments if you were big enough to do it. People were writing C and the major problems of the industry were how to fit shit in to x MB of ram and x CPU cycles. Security was abysmal - you didn't even have process isolation on OS-es. The languages and the practices are also completely different - disregarding the "we did it in the 60s with LISP in this paper" crowd - outside of academia people were just getting in to the OOP which was the pinnacle of abstractions back then. This is the drag&drop and copy-paste as an abstraction VB shit era. Unless you were at one of the cutting edge places that were actually innovating back then in terms of process and stuff there's likely nothing from that skill set that transfers on to the problems that we are dealing with today beyond the CS grad basics.

clockwerx 10y ago
Stuff that hasnt changed markedly: geometry math, statistics. SQL - 1970s. SOLID - parts of that are late 1980. C still looks like C. Unix like environments. Awk/sed/etc. Go read about the history of the web or XML; you get a very strong sense that these things have been thought about for a long time - data interchange has varied formats, but there is still a lot of tedious ETL type work. The importance of naming things well hasnt changed. Identifiers for data being a hard thing hasnt changed. Schema/vocabularies and more are still important problems. If you cant see some of these things underpinning much of the work we do, you might be missing the forest for the trees
- bshimmin 10y ago
  One thing I've found that's significantly changed since I began my career, before my beard went grey, is that projects are now in general run much better. People never make a total mess of estimating timings, and the Agile methodology (and Kanban boards, and Trello, and JIRA, and of course Slack) really fix all organisational and prioritisation problems such that projects never end in disaster; gone are the days of frantic last minute firefighting and all-nighters, as we desperately work out which features are critical to getting the project live before everything explodes. Clearly the experience of older, wiser heads in moments of crisis is now basically never required because projects run so smoothly. Haha, sorry, I'm only kidding.

omginternets 10y ago

>So are we law and medicine or are we tomato pickers? There's engineering and engineering. Making apps using electron.js and writing high-frequency trading software isn't the same gig. I think much of the problem described by the parent comment falls upon those programmers doing the former.

pc86 10y ago

> If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times? I can make ridiculous scenarios too. If the cardiac surgery is using the latest technology, which the younger surgeon had used all 4 times successfully, and the older surgeon had used once and killed the patient? This idea that being around since COBOL = smarter/better/"we GTD while they sit around doing nothing for 16 hours" is idiotic and not at all based in reality.

Spooky23 10y ago

Churning out code usually isn't engineering, and it isn't tomato picking. It's more like being a machinist in an industrial setting. You need to know the tools and how to read the spec. That's why you can post a technology position, get 1,000 resumes from people working professionally, and find that 80% of the candidates lack basic knowledge. The problem is that if you don't up your game to be in a more engineering-y role, you're just one ROI calculation away from being automated out of existence.

coldtea 10y ago

>If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times? If you were hiring, you would want the starry eyed, finger in the pulse of latest fads, young programmer you can pay less, overwork, boss around, and screw over, or the senior engineer, who values sane hours and time with family, doesn't blindly adopt any BS fad technology you want them to use, and demands salary that matches their experience? Especially if the first can still get out something that "kinda works" and you could not give a rats arse about technical debt and bad decisions behind the UI facade?

Roboprog 10y ago
Soooo.... Tomato pickers it is! :-) Good counterpoint, liked both this and the grandparent comment. Ouch.
AnimalMuppet 10y ago
If that's what the hiring person is like, though, I'm fine with not getting that job...
- coldtea 10y ago
  As long as there are enough other good programming gigs available though... As in, most McDonalds workers also hate both the hiring person AND the job, but they do it anyway.
- clifanatic 10y ago
  - until that's _all_ there is.

WalterSear 10y ago

>If you were having cardiac surgery, would you prefer your surgeon to be a year out of med school having done the operation oh 3 or 4 times, or the proverbial graybeard who has done it a thousand times? http://www.npr.org/sections/health-shots/2014/12/22/372508398/is-your-heart-doctor-in-if-not-you-might-not-be-any-worse-off http://www.npr.org/sections/health-shots/2014/12/22/37250839...

Gracana 10y ago

The vast majority of software engineering work does not have the same rigor that other fields of engineering do. Standards, safety, inspection, accountability, documentation, testing, certification, etc... many other fields focus on these things, but in software it's pretty much "anything goes so long as we make money." The trick to making companies value good engineers is getting them to value good engineering.

carbocation 10y ago

As a cardiologist, I would prefer to refer my patients to the cardiac surgeon who is the most skilled, regardless of their time out of training. Similarly, I don't think that a programmer's age tells me much.

surge 10y ago

Weirdly, the mortality rates from surgeries can go up with much older doctors, for a variety of reasons, but mostly because they have lower volume of work so aren't as in practice and may not be current on latest techniques that may be less invasive or higher success rate. It could also be older people like having older doctors and the mortality rate is higher with older people getting surgery. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1856535/ https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1856535/ There is probably a statistical sweet spot, where someone has years of experience, is active enough to be up on the latest techniques, or at least learns the new techniques and adopts them. Parallels can be drawn between this and tech workers I'm sure.

sotojuan 10y ago

Engineering might be the former. Programming and software "engineering" is definitely the latter.

pfarnsworth 10y ago

If you were building a team to win the Super Bowl, would you pick the hot shot 23 year old fresh grad from college, or the 50 year old experienced Hall of Famer?

Shebanator 10y ago
50 year old hall of famer? Its rare for a QB to make it to 40 years old in the NFL. Peyton Manning retired at 39 years old after he won the Super Bowl last year, and he was considered ancient and past his prime despite that achievement. Furthermore, I just looked it up, and the oldest player to ever have played in the league was George Blanda, who retired at age 48. http://www.profootballhof.com/football-history/40-and-over-club/ http://www.profootballhof.com/football-history/40-and-over-c...