Neural Nets vs. Cellular Automata (nets-vs-automata.net)
51 points by todsacerdoti 2d ago 5 comments
Reverse Engineering All the Raspberry Pis (jeffgeerling.com)
95 points by speckx 14h ago 24 comments
Dangerous Advice for Software Engineers
47 gxhao 15 8/26/2025, 6:15:17 AM seangoedecke.com ↗
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.
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.