Informative and fun new work from Stamen (along with a shout-out to How Big Really).

"It costs us something to be the beginner. Our minds opt for intellectual ejector seats, taking us away from new ideas. But “I hadn’t thought of that before” is actually the experience of joy trying to reach us." Sara Hendren on expressing discovery as pleasure rather than threat.

Aha: a course for people who can program already! Good; Python is my Umpteenth language and I can just about bodge it together, but it'd be nice to know it better. Might hammer at this over some evenings.

"…he doesn’t strike me as someone that Hubertus Bigend would hire. He strikes me as somebody that Hubertus Bigend would trick an opponent or enemy into hiring.”

Notes from Jeremy Keith on starting out in front-end circa 2019. Really useful for [Longridge], because I never have a good answer to where to start any more, and lots of these resources look great.

This is a great talk by Zach Gage, from PRACTICE (I believe) on how to both design difficulty into games, but more importantly, how to help people become better at problem-solving, and the very specific relationship between shapes of problem, learning style, and difficulty. Great reading for game designers, but also recommended for any interaction designers, really.

"I think as experienced game developers / engineers / artists / makers, we don't realize how we've developed strong senses of "vision" — the ability to visualize and maintain this thing in our head, and gradually work to realize that thing into existence despite countless obstacles. Frequent failure is expected! But this kind of emotional intelligence, to be patient with yourself and your work, takes time to cultivate. People have trouble grasping this if they are new to making things, and maybe it's our mission to help them own their constant failures." This is a really good way of expressing this issue. And, in particular, spending time understanding what's going wrong, rather than throwing hands up at the first error message. Those tracebacks, however weird they may seem to begin with, are designed for the reader, and they help with the journey.

"I remember a Christmas as a boy where I was given both a bicycle and a copy of The Hobbit, and strict instructions to make immediate progress with both. [My dad and I] continue to find it very easy to choose birthday gifts for each other." Mainly linked just for this paragraph.

"In school most people got to try drawing or playing instruments. Trying out code should sit in the same category: as a creative pursuit that you should at least try before you decide whether you like it or not. There is a huge drive now to get kids to do just that, whether it’s to give them skills required by the modern world or whether it’s about teaching creative ways of thinking. CodeClub is one of the initiatives that has the potential to not just show how much this is needed, but provides the solutions. Kids will be okay." [this is good]

A huge, fascinating, braindump from Bret Victor, mainly on the state of how programming is being taught (especially in the "learn to code, live" idiom that's popular at the moment). A lot of it is very good; I'm not sure it applies everywhere, and I'd like to see examples not about geometry (which I think are entirely possible, given Victor's idioms). But still: it's huge, and dense, and well-reasoned, and has lots of jumping off points. Good to see someone thinking about this stuff like this.

"It’s okay if they don’t completely understand how a program works after they’ve played with it a little. Very few ideas are completely original. The more material you give your students to plagiarize, the wider the range of derisive works they’ll make from them." Perhaps my favourite point in this very good piece. (Though I've found GameMaker way less of a "kit" than it makes out). But yes: no-one wants to learn to program (for its own sake). People want to learn to make things for screens; programming is incidental.

Really good look at getting your head around vim from Mislav. Especially on the money with regard to starting slow, and adding things as you need them. The worst thing you can do is _start_ with somebody else's .vim files.