If you watch an expert arborist (tree man) at work, you’ll notice that they’ve removed every single safety guard from their chainsaws.
Every now and then, there’s a nasty accident, but most of them respect their tools, and just make a lot of money (which you’ll understand, if you’ve ever hired one).
Same goes for pretty much any vocation.
That said, manufacturers have learned that there’s a lot of money to be made, selling professional tools, to insecure fools with money.
There’s a big ego hit, in LARPing a highly-experienced engineer, when you’re not one, yourself.
cinntaile · 1h ago
> If you watch an expert arborist (tree man) at work, you’ll notice that they’ve removed every single safety guard from their chainsaws.
You can say that about everything that has some form of guardrails. It goes faster without them. That doesn't necessarily mean it's the right decision to remove them. People tend to change their minds after they have an accident, which to me is an indication that they can't seem to properly assess the risk and the outcome beforehand.
pm215 · 52m ago
It might alternatively be an indication that they can't properly assess the risk and the outcome afterwards....
(More likely both: we are as a species absolutely terrible about assessing low-probability risks.)
ChrisMarshallNY · 45m ago
I've benefitted from modern "safe" languages.
I cut my teeth on things like Machine Code, ASM, and ANSI C.
I don't miss them, at all.
Nowadays, I write primarily in Swift, and I absolutely love not testing for leaks, anymore.
cinntaile · 39m ago
How does this support your original position? Now you're saying you want the guardrails, I don't get the point you're trying to make.
darkerside · 16m ago
It can also mean they properly assessed the risk and got incredibly unlucky
cinntaile · 48m ago
Yes, that is a valid point you make!
roenxi · 1h ago
> Every now and then, there’s a nasty accident...
That may just be they aren't very good at risk assessment. Nasty accidents with a chainsaw are in a different league of damage for the person involved compared to, eg, accidentally deleting a database or upsetting a manager. A software engineer is all but guaranteed to walk away from deleting a DB with their limbs intact. Even if their manager gets really angry a dev is almost certainly going to survive the encounter.
ChrisMarshallNY · 51m ago
Deleting a DB could have life-changing ramifications, depending on what's in the DB.
I used to write a lot of hardware-interfacing software.
The cool thing about writing things like device drivers, is that you can have some really kinetic bugs.
withinboredom · 14m ago
You have bad catastrophe management if deleting a database causes issues. I've seen databases accidentally deleted in production ... we just restored from a backup losing only a few ms of writes.
This stuff happens; sure it causes downtime, but it shouldn't have any real ramifications.
ChrisMarshallNY · 11m ago
True. That's what good process and risk management gives you.
I have blown up $40,000 receivers, though.
Hard to restore from a backup.
thrown-0825 · 59s ago
race car drivers are the exact opposite of what you are describing and they compete in a sport where every gram matters.
closewith · 1h ago
> If you watch an expert arborist (tree man) at work, you’ll notice that they’ve removed every single safety guard from their chainsaws.
I've never seen an expert arborist remove any safety feature from a chainsaw and they'd be off site in a heartbeat if they did.
You're imagining a scenario to support your opinion, no basis in fact.
ChrisMarshallNY · 53m ago
Actually, I have several friends that are arborists. It's a fairly common vocation, hereabouts.
It's not nice to be not nice...
XorNot · 45m ago
What safety features are they removing from their chainsaws to speed the job up?
closewith · 45m ago
> Actually, I have several friends that are arborists.
Right, and they're removing chain brakes and throttle lockouts, are they?
> It's not nice to be not nice...
It is nice to make up stories to support your worldview?
I've never seen a professional modify equipment to remove safety features, let alone an expert.
> Deliberately break written company rules sometimes
I love this. It’s so true. Rules are written for indemnity, but nobody will blame you for not remembering every one of the 216 rules the company has as of this moment (217 tomorrow).
And they’ll love you for fixing the problem now, instead of waiting for the two week review cycle to finish. That is assuming you don’t break shit, but even then it’s a matter of ‘sorry’ in all but the most egregious cases.
> Rules exist to constrain engineers with bad judgment, not to bind the ones with good judgment
Also, “how to fall to the dark side” xD
withinboredom · 1h ago
As an engineering manager ... please don't "knowingly" break the rules. It makes my job so much harder. Just break them and apologize. And try to break a different one every time; this is the one thing to be inconsistent on.
Also, I never said this; I disavow all knowledge of writing this message. I am probably drunk and queued this message to be sent during working hours as a prank to myself.
atoav · 2h ago
I don't feel the need to give dangerous advice. As an educator that has to do with the stuff people build more or less unsupervised I can assure you that dangerous is the defacto default starting point for anybody who has no idea what they are doing.
There is only a very specific class of person, who is often overcautious and perfectionist to a degree that they won't even get started. They might need some advice that eases their worries. But the dangers are real. Overcomplexity is also a danger.
Most of the "dangerous advice" I have encountered as an engineer (be it electrical or software) I have seen in the form of legacy projects without anybody there to explain them to me. There you can see where corners where cut, where they were completely out of their depth, etc.
If you watch an expert arborist (tree man) at work, you’ll notice that they’ve removed every single safety guard from their chainsaws.
Every now and then, there’s a nasty accident, but most of them respect their tools, and just make a lot of money (which you’ll understand, if you’ve ever hired one).
Same goes for pretty much any vocation.
That said, manufacturers have learned that there’s a lot of money to be made, selling professional tools, to insecure fools with money.
There’s a big ego hit, in LARPing a highly-experienced engineer, when you’re not one, yourself.
You can say that about everything that has some form of guardrails. It goes faster without them. That doesn't necessarily mean it's the right decision to remove them. People tend to change their minds after they have an accident, which to me is an indication that they can't seem to properly assess the risk and the outcome beforehand.
(More likely both: we are as a species absolutely terrible about assessing low-probability risks.)
I cut my teeth on things like Machine Code, ASM, and ANSI C.
I don't miss them, at all.
Nowadays, I write primarily in Swift, and I absolutely love not testing for leaks, anymore.
That may just be they aren't very good at risk assessment. Nasty accidents with a chainsaw are in a different league of damage for the person involved compared to, eg, accidentally deleting a database or upsetting a manager. A software engineer is all but guaranteed to walk away from deleting a DB with their limbs intact. Even if their manager gets really angry a dev is almost certainly going to survive the encounter.
I used to write a lot of hardware-interfacing software.
The cool thing about writing things like device drivers, is that you can have some really kinetic bugs.
This stuff happens; sure it causes downtime, but it shouldn't have any real ramifications.
I have blown up $40,000 receivers, though.
Hard to restore from a backup.
I've never seen an expert arborist remove any safety feature from a chainsaw and they'd be off site in a heartbeat if they did.
You're imagining a scenario to support your opinion, no basis in fact.
It's not nice to be not nice...
Right, and they're removing chain brakes and throttle lockouts, are they?
> It's not nice to be not nice...
It is nice to make up stories to support your worldview?
I've never seen a professional modify equipment to remove safety features, let alone an expert.
I love this. It’s so true. Rules are written for indemnity, but nobody will blame you for not remembering every one of the 216 rules the company has as of this moment (217 tomorrow).
And they’ll love you for fixing the problem now, instead of waiting for the two week review cycle to finish. That is assuming you don’t break shit, but even then it’s a matter of ‘sorry’ in all but the most egregious cases.
> Rules exist to constrain engineers with bad judgment, not to bind the ones with good judgment
Also, “how to fall to the dark side” xD
Also, I never said this; I disavow all knowledge of writing this message. I am probably drunk and queued this message to be sent during working hours as a prank to myself.
There is only a very specific class of person, who is often overcautious and perfectionist to a degree that they won't even get started. They might need some advice that eases their worries. But the dangers are real. Overcomplexity is also a danger.
Most of the "dangerous advice" I have encountered as an engineer (be it electrical or software) I have seen in the form of legacy projects without anybody there to explain them to me. There you can see where corners where cut, where they were completely out of their depth, etc.