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

@dysfun@treehouse.systems For sure, but I do think that a change in software development culture *could* be a good starting point to get broader cultural changes rolling, without needing to wait for the rest of society to fix its issues.

There's a lot of pragmatic arguments in software dev that can be used to convince people that different approaches are more viable, where the consequences are more immediate and obvious than they would be in most other societal contexts.

@dysfun@treehouse.systems (I'd say it typically took only about 5-10 hours of tutoring to really teach someone the process of problem decomposition, to the point that they could do it independently with a high success rate)

@dysfun@treehouse.systems Right. It's not impossible to teach - I've tutored quite a few people 1:1 in the past, and I've found that focusing on decomposing problems before writing code *really* helps with that.

The question is how to scale that into a cultural change, and address the trickier emotional bits like ingrained and widely loudly repeated beliefs about what 'libraries' look like - because this is fairly easy to override in a 1:1 conversation, but a community-wide culture change is different.

@rune That, plus experience in quickly identifying information to eliminate/reject!

@dysfun@treehouse.systems Or another way to phrase that: I've developed that attitude *in spite of* widespread software development culture, when it should have been *because of*. And a wider culture change is thus really needed.

@dysfun@treehouse.systems For sure, I'm the same - and I often go a bit beyond that, trying to complexity-reduce problems that are widely believed to be non-reducible (with mixed but nonzero success).

But there's a lot of history and experience and personal development behind that attitude towards things, and I really think we need a more effective way to convey this to *new* developers, without requiring them to stumble along for 10 years first :/

@rune Thing is, I've done a lot of programmer support on IRC and such. And a *significant* chunk of the questions, probably more than half, I answered not from memory - but by having some vague inkling of what to look for, doing some quick research, and summarizing my findings.

I have yet to find a book that can answer questions faster than this process. Far as I can tell, this is pretty much the optimal process for figuring stuff out.

@dysfun@treehouse.systems Like, I *want* to make it easier for people to design good APIs. But 9 out of 10 times when I bring up my findings, I pretty much get laughed out of the room, because nobody even believes it is an existent problem to solve. "The big frameworks are fine!"

@dysfun@treehouse.systems Oh, for sure. This is what I always aim for in my API designs, but it's *hard* work, and requires a degree of bidirectional engagement with other humans that a lot of developers don't seem to feel comfortable with.

I've long been wondering whether part of the "opinionated framework" ideology can be explained by people (knowingly or otherwise) using it as an excuse not to have to do this hard work, by pretending that the easy-but-mediocre "solution" is the only one that exists.

Unfortunately this ideology of the pretend-single-solution also makes it really difficult to start conversations about other, *better* solutions.

Most of the hard work in good API design is figuring out the principles you can follow to make the design process easier and more reliable, which is a one-off cost - but I can't really share the findings of the work I've done there, because there's no public conversation to insert it into...

I wonder whether this can be convincingly explained to people (who have bought into that ideology) by equating it to the saying about "teaching someone to fish", as that saying seems to resonate with a lot of tech folks on an emotional level - an opinionated framework is giving someone a fish, providing guidance on how to select options and what options there are is *teaching* someone to fish.

I really have to write Properly(tm) about these intersections between authoritarian ideology and software development culture some day, because this is *far* from the only case where this crops up

I also feel like this ties into authoritarian ideology in interesting ways. The broader belief that the only way you can make people do something "for their own good" is by forcing them into it and giving them no other choices, rather than giving people agency and trusting them to be responsible and competent in handling it.

@rune Not just that, it also tells you that they know *nothing* about how things work *anywhere* outside of the US, and they have bought into the ideology that whatever the US does is automatically the optimal solution (because in national ideology, that is the expected outcome of the "free market", and if it weren't, that would threaten capitalist ideology).

@rune I have had more than one USian get aggressively confused at me when I told them we don't have school buses in NL.

"So you're forcing every parent to drive their kids to school before going to work?!"

... no? Have you considered that better solutions might exist?

It boggles my mind how it's *still* a widespread belief that libraries/frameworks must be opinionated "because otherwise people would get lost in the options" - as if "technically forcing people into a specific choice" (with all of its significant downsides) is somehow the only possible way to help guide someone towards a sensible solution.

@aral While I do think this is a real issue (and *yet another* reason why ESM is not a suitable replacement for CJS), it should be noted that hot-reloading modules is never a safe thing to do in JS regardless of the module system - the language does not provide sufficient state isolation guarantees to prevent state leaking between versions of modules, and this can lead to very strange non-reproducible bugs.