There's something nice about holding your work in your hands. Tangible work is also both easy to explain, and hard to fake. So going the hardware route felt fun, fulfilling, and scored well.
This works if you're on call for your systems. In many situations (ranging from small startups to big tech), you're also on-call for the systems of sister teams.
Not that there aren't other ways to fix that. But fixing the erroring service isn't practical in all cases.
It's quite easy, actually. We did this at work, recently.
Bun is two things. Most commonly, it's known for its Node-competitor runtime, which is of course a very invasive change. But it can also be used purely as a package manager, with Node as your runtime: https://bun.sh/docs/cli/install
As a package manager, it's much more efficient, and I would recommend switching over. Haven't used pnpm, though--we came from yarn (v2, and I've used v1 in past).
We still use Node for our runtime, but package install time has dropped significantly.
This is especially felt when switching branches on dev machines where one package in the workspace has changed, causing yarn to retry all packages (even though yarn.lock exists), where bun only downloads the new package.
An interpretation that makes sense to me: humans are non-deterministic black boxes already at the core of complex systems. So in that sense, replacing a human with AI is not unreasonable.
I’d disagree, though: humans are still easier to predict and understand (and trust) than AI, typically.
In general, the way a walled garden wins is by providing everything its villagers need inside.
And Apple’s products seem to create walled gardens in order to prioritize [first creative, then economic] control.
Based on the demographic that a significant portion of their marketing seems targeted towards (artists and creative types), I think your theory sounds likely.
This sounds depressing. I’m sorry that you had that experience.
It’s a frustrating position to be in, and you can feel quite helpless.
In my experience, it’s less about “do only what’s asked”, and rather “say no”.
I.e. explain “I can do X, but if I do that then Y will suffer, and Y is a priority”. (Y being another company priority, or even your own mental health). Stated in these terms, it’s easier to negotiate your time with your coworkers.
FWIW, I don't think the code style in [2] is less simple (slightly more readable, to use `if (X) {} else {}` rather than `if (!X) {} else {}`, for example).
So to me, this reads as the author of [1] is just overcorrecting by adding process, when some test cases or code review would've been more helpful in preventing whatever incident [2] caused.
Exactly. I know if medication were to be developed, checking "are GDF15 levels significantly lowered" would be part of the trials.
But how often does the medication development process check the result we care about: "does this medication then go on to reduce the chance of dementia?"
> How would you alternatively design a system that calls emergency services in a crash?
If you want to prevent false positives—then, same as you’ve described, but only enable when either:
- phone is connected to Carplay via USB or bluetooth
- phone is connected to a bluetooth device known to be an auto (inferred by manufacturer ID, and configurable in bluetooth settings)
- GPS data for the last 5 minutes indicate you’re driving
And display an indicator on lockscreen that shows this feature is enabled.
Of course, consider that the downside of false positives don’t affect consumers or manufacturers—rather, they affect public utilities. Then, it’s easy to understand why this happens.
I tried it out, was enjoyable to play a few puzzles. My feedback is a) that the ring sound (when you win a puzzle) was too loud, so I ended up muting the tab, and b) that the logo looks like "BraiMax", and doesn't stylistically fit with the rest of the site theme.
I imagine planning the construction of a factory is harder than writing a product spec for your average software feature. Not sure that order requests speed up the process.
A couple examples (both from HackPrinceton, which had the best EE labs):
* https://blog.cyrusroshan.com/post/electronic-banjo (crowd favorite)
* https://blog.cyrusroshan.com/post/spin-to-win (a "moonshot" idea)
There's something nice about holding your work in your hands. Tangible work is also both easy to explain, and hard to fake. So going the hardware route felt fun, fulfilling, and scored well.
Good times.