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

@jonny What I tend to do when teaching programming and related things, is to have 'guided self-exploration'.

I make it very clear upfront that there is no penalty for getting things wrong, and that they *will* sometimes get things wrong and that's completely okay, and that's an intentional part of how I teach, and that I will be there to help them out whenever they get stuck.

Then I do usually 1-2 hour sessions at a time, deciding together on a small task (in a real project they want to do, not a sample/demo project!) that lets them practice some aspect of programming or project maintenance, and we go through it together.

Crucially I don't tell them *how* to do it; I give them a pointer on how to reason towards the answer, but don't provide the answer itself, and instead encourage them to 'reason out loud' and try things out (emphasizing that if something goes wrong, I will help them undo it, so they should feel free to try things even if unsure), and constantly ask them questions on "okay, and what would you do next?", incrementally narrowing down the scope of the question until the answer occurs to them.

The idea behind this is that you're always there as a 'support net' for them to fall back on, but they do as much of the "reasoning towards an answer" process as possible by themselves - and this helps them very quickly learn to identify the "meta-process" of working *towards* an answer based on incomplete information and missing background knowledge.

(For this to work, it's important that they work on a project/goal of their own invention - because that means that they already intrinsically know what the end goal is with all of its detail and nuance, and so you only need to teach and communicate the "how to get there" parts, not the "what are you supposed to be doing" parts.)

This approach often takes a bit for students to get into, as it *feels* hard initially and so being supportive is very important, but I've had universally positive feedback to it in the end. It usually only takes 2-3 sessions before they start getting the vast majority of "what to do next" answers right, even on topics they've never worked with before, and usually before they feel confident about their answers.

Interestingly, this has also worked very well with students who self-reported serious learning disabilities, and who had run into walls with everything else.

@porkroll (At least it's only allocating within a memory-mapped file and not system memory in general)

@porkroll It's not exactly voluntary :P Unfortunately it's more or less necessary to have a reasonably performant SHM implementation...

@frith01 Just to confirm, you have (direct or indirect) personal experience with not having reliable internet connectivity available?

@gsuberland@chaos.social @tsrberry @baldur Also, related to the 'user surveys' point - it's surprisingly helpful to just enter your project name into a search engine every once in a while, and read every blog post, Reddit thread, and rant you come across. Those tend to be *full* of things that never made it into 'properly filed' issues, and give a good impression of the general atmosphere around your project, because people tend to speak more freely and directly.

Of course that does mean that you should refrain from responding to them unless you are absolutely 100% certain that you can do so non-confrontationally, because seeking out confrontation with people talking in their own spaces is (deservedly) a very quick trip to the trash pile. Better to just take notes and work on fixing their complaints in the background.

(Bonus points: you can do this one as an 'unaffiliated' contributor with no formal power within the project. Whereas a proper user survey, although it can have better coverage, tends to require speaking formally for the project.)

@gsuberland@chaos.social @tsrberry @baldur One thing I'd want to add to that is that if it's not feasible to find experienced designers (funding reasons, community politics, whatever reason), it *is* possible to just learn how to do this stuff yourself on-the-fly as a maintainer, but it makes the "be humble" part all the more important, and to make that work, you *need* to have an attitude of "if a user complains about something, that means there's a bug, even if it's not where the user thinks it is" (eg. it might sometimes be a documentation issue instead of a UX issue, but as long as people complain, there's *a* bug somewhere).

I change my mind on things carefully and deliberately, after ensuring I understand the reasoning well enough, specifically to avoid falling into reactionary traps - but I think this just looks like stubbornness from the outside?

@gsuberland@chaos.social @baldur Don't know that it's worth much, but if it helps: I agree on all of this, and it has been frustrating me for over a decade.

(And I've experienced the same active resistance to changing that culture, too...)