Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@aeva@mastodon.social That's what the original toot is about; trying to target that as a primary objective involves *significant* tradeoffs, that will interfere with other, much more important systemic problems in software that still need to be solved

@aeva@mastodon.social Not really, no; games are a special case where performance is a much higher priority than in most other kinds of software :)

The issues (eg. with dependencies) that I'm describing *do* apply to game development to some degree as well, but the whole recent "we must prioritize efficiency above all" phenomenon is a decidedly non-game thing

@maia "The management level of a shitty company recognizing you by name despite never having worked there" is one of the entries in the Hard Achievement Diary for anti-capitalism

(Another way to look at this, is that "just write efficient code" is an attempt to solve a collective problem with an individualist solution, and I hopefully don't need to explain why that is doomed to fail)

Potentially controversial opinion: I think that "making software more efficient" is the wrong thing to focus on right now.

There's a significant kernel of truth to the idea that "it's easy to make good code performant, but it's hard to make performant code good" - and so before going all-in on optimizing code as the primary objective, we should make sure that we're optimizing the right thing.

And right now, we're not. We're very much not.

There are significant problems to be solved in how we address software development, and the power dynamics embedded into it - the most obvious example would be the still-widespread fear of dependencies, which actively interferes with making software work better for people, and results in an endless treadmill of broken shit.

And guess what, there *are* significant efficiency benefits to be gained here - everybody using the same well-optimized implementation is going to be much better than everybody using their own homegrown half-optimized "clever" implementation.

But by putting all the focus on software efficiency and performance as the #1 priority, we risk removing all the oxygen in the room for figuring out better ways to deal with dependencies and many of the other industry-wide problems I haven't even mentioned here yet, and ending up in a *worse* place (even efficiency-wise!) than where we *could* be if we started with other problems first.

TL;DR: software efficiency and performance is important, but if you treat it as a goal to chase directly, you will end up with broken and faux-simple software that isn't even as efficient as it could be. Fix the big problems with software first, *then* think about how to optimize the remainder.

It's still bizarre how my brain synchronizes with whatever music I'm listening to, even when I'm doing something completely different

Looks like they basically rewrote the whole event handling system to make Suspense work

TIL

@Byte (But only *after* getting it done - *while* working on it, I do my best to remove any pressure and any sense that I "have" to get it done, because that'd interfere with reframing it as a leisurely break)

@Byte Oh and I mentally frame the "getting boring stuff done" as an achievement, "finally I'm getting through it, see, I *can* do this", to get the gratification sense

@Byte I've had some success with treating those things as a type of 'break', where I turn off my brain from more exciting things for a bit and do something calm and boring, when I'm feeling overstimulated by other stuff. But of course that assumes that you can schedule the boring stuff at will. And it requires some creative rearranging in my brain of what qualifies as 'work' vs. 'leisure' to make all the brain opinions about the boring stuff line up.

@silvermoon82@tech.lgbt It's just so, so bad. The React build system alone entails more complexity than most JS libraries do in the libraries themselves, and it can be a true challenge to get reproducible builds (actually OOTB it generates builds with the wrong version number). It's completely absurd.

- Please stop publishing your library as minified bundles, I beg of you

Reading the React codebase and, some observations:
- The code quality is pretty okay
- *Fuck* the build system
- Most of this logic should be in reusable stand-alone packages, not in core React
- Why is there a Facebook compatibility mode embedded into the codebase

> (0.5278031243612911).toString(36)
'0.j016klztvb'

frustrated-i-guess.png