Links - 24^th October 2021

The basic idea, I think of “cursed” in the context of Extremely Online Twitter Speakers is the way that an idea can persist in you and bother you, not necessarily in an anxiety spiral kind of way, but just in an analytical, reflective way, things that we might rather not have known. Things that don’t actually change our behaviours or impede the way we are, but now you know them, you might be reminded of them at times when you’d rather not think about it.

There is an uneasiness in knowing some things. Our brain is an association engine. Sometimes if we know something and it’s strange and weird, that can mean that we forget it, and it lays under the waves of our mental process most of the time. And then, something that stirs that memory, and suddenly it’s there, and you’re back confronting that unpleasantness. Not painful, not traumatic, just… unpleasant. Like a fart in your ear.

To put it simpler, cursed knowledge, in a useful way, is knowledge that you can’t know for sure you’d rather not know. The only way to know is to learn it; the only way to learn the effect it has on you is to know it. But there’s a recognisable risk in how it works. This isn’t just curses of the vulgar and the body. There’s a mild curse associated with knowing the structure of Gustav Holst’s The Planets, and suddenly you see the underlying structure in every movie score across several genres. Maybe if you can recognise the Four Chords, every pop song sounds more similar, the world seems narrower. And maybe that’s something you’d rather not know, if you had the luxury.

But you didn’t know that you didn’t want to, before you knew it.

When I think about speed I think about the whole process — researching, planning, designing, arguing, coding, testing, debugging, documenting etc.

Often when I try to convince someone to get faster at one of those steps, they’ll argue that the others are more important so it’s not worthwhile trying to be faster. Eg choosing the right idea is more important than coding the wrong idea really quickly.

But that’s totally conditional on the speed of everything else! If you could code 10x as fast then you could try out 10 different ideas in the time it would previously have taken to try out 1 idea. Or you could just try out 1 idea, but have 90% of your previous coding time available as extra idea time.

The best part is that you can improve your coding speed a lot by improving simple mechanical skills which are easy to measure, practice and improve. It’s a lot easier to get faster at coding then it is to get better at choosing the right idea!

Within the team, Jira is a way of communicating without talking with each other. As such, it is inferior to any of the usual forms of person-to-person communication, such as being together, getting together over Zoom, or even talking on the phone. It is impersonal, and the written word offers only a fraction of the understanding we get from talking with each other human to human.

One might argue that Jira can contain more information, that might be forgotten during conversation. This is true, but working as a team isn’t really about information, it is about common understanding, which is hardly based in information at all. That said, if a team wanted to keep some useful information in Jira, that would seem acceptable, but the danger is that Jira will begin to be used as a communication hub, rather than an information library.

Jira almost always interferes with teamwork, even as it helps in a small way.

I’m a strong believer that wires are the most underdeveloped part of visual programming tools.

• In most VPLs, when you disconnect a wire from a node and then let go of the wire, the wire is immediately deleted. So there’s only 2 valid states for a wire — either connected to a node on both ends, or connected to a node on one end and the mouse cursor on the other end. I think this is a mistake. I think the wire should continue to exist until you explicitly delete it. If you want to draw a wire freely in space, not connected to any nodes, good! If you want to unplug a wire from a node, and then put the wire down for a moment while you go get a different node ready, good! You should be able to think of wires the way you think of physical cables in the real world, except that they can be whatever length you want, never get tangled, and can show you what’s going on inside them.

• Wires tend to be straight lines, S-curves, or some other shape that is completely outside the control of the programmer. I think this is a mistake. Rare is the VPL that lets you choose what path the wire should take. Rarer still is the VPL that lets you work with wires using a robust set of tools — braiding multiple wires together, choosing the color or texture of wires, offering different kinds of wires that are specialized for specific tasks, drawing elegantly curving wires with an inkpen tool, manipulating individual vertices or bezier curves, adding "hints" to help an autolayout system route your wires intelligently.

If you watch an anime or a TV series “about” fighting, people often improve by increasing the number of techniques they know because that’s an easy thing to depict but, in real life, getting better at techniques you already know is often more effective than having a portfolio of hundreds of “moves”.