My name is Mat. I do a lot of software engineering for arty projects and I lecture part-time for Greenwich University's design school. -- How hard should it be to make your computer do all the things you have seen computers do? Before I learned programming, the assumption I had was that any programmer is able to make any kind of software. Once I started, I fell into the usual strategy of studying new concepts only when I needed them. I didn't want to over-complicate my job and miss deadlines. My initial assumption seemed naive. Programming became an immense field, and I felt pressure to always defer to 'cleverer' people. Use their code as much as possible. But after a few years, my room to improve felt limited. I realised that, a lot of what I knew was arbitrary. My job required me to produce a similar result across a variety of third-party platforms, but never to fundmentally understand how computers solve the problem itself. So I decided to practice separating arbitrary knowledge from fundamental knowledge, and I used that feeling to guide what I spent my time studying. This distinction would later inform my teaching style. Now, I'm always up-front with my students if I think a concept is an abstract, transient, artefact of our culture, rather than something worth really internalising, about computation. My hope is that this nurtures confidence. At the very least it offers a protective mindset, for when the quirks of their tools make them feel totally lost and useless. So I was studying a lot, and shopping for niche textbooks in my lunch hour. Books became stepping stones to aspects of my field that I had previously not felt I would ever care about, let alone need. As I explored deeper, and told my coding friends and colleagues what I was upto, I noticed a pattern in their responses. Interestingly there was occasional ridicule, and even hostility. But far more common was self deprecation: "Wow, way too complicated for me!". I think that response is vague. It could mean: A) I don't know how to do that. B) I don't know how to learn that. C) I don't have time to find out. D) The problem fundamentally requires many components with many connections between them. I'm just not interested. A, B, and C are accessibility problems. And until you have access, its impossible to identify if D) really applies. I am convinced that sub-fields of programming are not hierarchical. The emotional experience of working on a technical problem, with limited understanding, is universal. I think we *all* deal with far too much complexity. -- I've been writing and re-writing and re-re-writing a framework, but really just a pile of code, for the past few years. It has no dependencies. There is only my code, the compiler, and the operating system. My income is now mainly from using it to make custom software for designers. It has been really hard to get here, but in all the best ways. It is called Puffins. -- Memory management has a scary reputation for three valid reasons: 1) We have to request memory from the Operating System, which often couples a program to the whims of a very complex system! 2) Bits in digital memory don't come with extra information. The lifetime of a program's data in memory is not stored anywhere, it is abstractly expressed by the code we write. 3) Modern processors vastly out-pace modern memory transfers. The fastest programs are no longer those that reduce the number of executed CPU instructions, they are instead those which operate on neat, sequential arrays of data. In my experience, memory mangement can be simple, but you need to a strategy which addresses reasons 1 and 2, and is ideally sympathetic to 3. I'm not going to pollute this talk with my favourite strategy, instead I want to talk about the metric I came to use while developing it. Think about all the what-if, edge-case questions: - What if the Operating System says no? - What If I don't have enough memory? - How many lifetimes do I even have? If a strategy allows you to awnser these questions, soley by considering the specific needs of the actual thing that building -- the problem you are solving. I think, that is a sign, complexity has been minimised. -- Removing dependencies can reap unexpected rewards. Last year I built a game with the Hudson-Powell team at Pentagram Design. We wanted to maximise device accesibility, but also have nice performance. I ended up compiling Puffins to webassembly. I didn't need Emscriptem, because again -- no dependencies. I had to spend a time hooking up JavaScript functions to allow the browser APIs to fill-in for the Operating System. But otherwise it just worked. -- Something I didn't think I would write, but is rapidly becoming invaluable, is Puffins' retained-mode GUI system. Rapidly building cross-platform GUI applications, following a modern, responsive design, without using electron, is pointlessly hard. -- Puffins is tiny. It's written in C99, a language tiny enough to learn inside-out. Debug builds from scratch are currently ~5s on my laptop. The codebase is concise enough that I can manually read it to audit for bugs. -- We made computers up. The only reality we have to contend with, is hardware. I think its basically up to us how complex software needs to be. We need to fight to invert our relationship with the platforms we support. Big tech fucking suck at what they do anyway. Don't underestimate what you can learn if you care about doing something well. I know this all sounds naive and idealistic, but it worked for me. If I knew what I was doing, or took anyone's advice, I might not have tried it. Thank you, I love you, lets go fix stuff!