Sven Slootweg (🔜 WHY2025) @joepie91@pixie.town

@rune I... think so? I know very little about snaps and how they work (as I have a bit of a distaste for the "wrap it all into a container" approach to 'solving' package management woes)

@rune I think that popup is actually produced *by* the package manager? I've seen a virtually identical popup for other snaps

@dysfun@treehouse.systems Oh yeah, to expand on my earlier comment about teaching problem decomposition to programmers: my approach to teaching it is somewhat non-standard, in that I let students pick *their own* projects to work on, regardless of what its total complexity would be (explicitly stating that it's completely okay if they never actually *complete* it fully), and then help them break down their own project into smaller bits and pieces.

I do this instead of giving them 'example projects' because with their *own* projects, they would already fully understand all the details of what they want to achieve, so the only unknown is "how to approach it". If I used sample projects, they'd have to simultaneously understand (and probably misunderstand) what the goals of the sample project are.

Overall this makes it much much easier to learn problem decomposition because they 100% understand the frame of reference 100% of the time, ie. they have a stable base to work from, and so they can actually reason about the smaller pieces and why they're chopped up like that.

After doing that a few times, they eventually learn the patterns and how to identify sensible problem boundaries, and start being able to do it independently.

@dysfun@treehouse.systems Fair :) And yeah, as long as we are stuck with this weird approach to education, I agree that problem decomposition should probably be in there.

@dysfun@treehouse.systems I don't really agree with that because I look at it from a different perspective; "when they leave school" is an arbitrary boundary, as is "while in school".

I'm of the opinion that all learning should be available to people *at any time, at any age*, including support from other humans who can help them understand things and explore their needs and wants, and that our current concept of "school" is a mediocre knock-off of that idea that doesn't really work in practice.

So I agree that people should have the opportunity to learn these things when/before they need them, I just disagree that "when they leave school" is the correct lens to look at that problem through, and that that lens is very much a product of a capitalist-structured society - and that we can do *so much better* than that.

@dysfun@treehouse.systems (I actually *sort of* got this in school, briefly, as an elective class; it was about "formal logic", which kinda did statement decomposition as a side-effect of reasoning about logic)

@dysfun@treehouse.systems I have mixed feelings on this. I don't think that *any* forced curriculum should exist in schools (it doesn't really make any sense from a didactic perspective), but *if* we're gonna have such an educational system instead of one that genuinely guides people to what they need, then this would probably be one of the most useful things to put in there, yes.

@dysfun@treehouse.systems Like, we were *almost there*, basically

@dysfun@treehouse.systems I'm reminded of the JS thing here: https://social.pixie.town/@joepie91/108227324270640760

@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.