this post was submitted on 29 Jan 2024
53 points (100.0% liked)
Technology
37719 readers
402 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
So what if you had the capability to be good at that heart pump software, and by not doing it you’re letting in someone who’s not as good as you at it.
Not trying to trap you or anything, but at a certain point somebody’s gotta do that high stakes stuff.
Maybe you know you’re not good at that kind of precision stuff, and I respect that. But maybe the difference between you and the guy who did step up to do that work isn’t that he has more skill, but merely less humility.
Maybe you, the one scared shitless of the ramifications of a mistake, are the one for that job.
Maybe. I've just shipped too many bugs to prod to trust myself. But you're right for every senior engineer who is paranoid about that there's 100 devs who will ship it and then take vacation for a week.
Perhaps the reason you ship bugs to prod, is because you know it doesn’t matter. Maybe your bug rate isn’t a pure function of the coding task complexity, but is context-dependent on the goal being coded toward.
I don’t even know why I’m pushing you on this to be honest. Trust your gut man
Lol I'm taking it as a motivational speaker, lol you just may be right. Who knows, but you cheered me up
There's quite a difference between rapid prototyping on software/hardware versus the human body.
Musk's approach to developing engineering advances has worked well in the software, aerospace, and vehicular industries. Development on inorganic things is much more predictable, we can isolate variables, and it is easier to understand cause & effect. If you screw up some software on an inorganic system, your program might crash, your rocket might explode, or your car won't start. These risks can be anticipated and costed fairly well, therefore rapid prototyping has an acceptable risk/reward ratio in that environment.
The human body, on the other hand, is an extremely complex system that we still don't fully understand. Each person is a unique variation on the model and that changes over time depending on upbringing, diet, exercise, and life experiences. Applying the same engineering approaches from inorganic industries has a much higher risk once you cross into the medical realm. If you have errors in a medical situation, you risk sickening, injuring, or even killing a person. The risk/reward ratio is skewed towards ensuring that human life is protected at all costs.
Using SpaceX as an example, the first three launches failed spectacularly and a fourth failure would have ended the business but fortunately the fourth test was a success. If you're suggesting that we apply the same risk-taking to Neuralink, are you suggesting that it's acceptable for the first three patients to die, as long as the fourth is a success?