croshan
Joined 9 years ago
Joined 9 years ago
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.
Not that there aren't other ways to fix that. But fixing the erroring service isn't practical in all cases.
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.
The proposal has other flaws, but phone to tower latency isn't one.
I’d disagree, though: humans are still easier to predict and understand (and trust) than AI, typically.
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.
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.