Jonathan Blow - How to program independent games - CSUA Speech
Why Hacker News recommends it
HN recommends it as a talk whose advice on simplicity and avoiding unnecessary work applies well beyond games.
What it is
Jonathan Blow speaks at UC Berkeley's CSUA about how to program independent games. He argues for keeping code simple, avoiding unnecessary work, and shipping.
Recommended by 9 HN commenters across 9 different months, 2015 to 2026.
What Hacker News said
Strong rec bajsejohannes · 2016-10 · on “Ask HN: What's your favorite tech talk?”
Jon Blow's "How to program independent games": [this video] It's about much more than games. To me, it's about identifying and not doing unnecessary work. The second half of this video is a Q&A session, which I would skip.
Strong rec psyc · 2017-01 · on “Ask HN: Which developers do you closely follow?”
Every time I get stuck on a project, I watch this video. It's about games, but IMO a lot of it applies to software projects in general, especially MVPs. How to ship something that works before it collapses under its own complexity. I think the bit about remembering to optimize for developer effort is gold. [this video]
Strong rec Stwerner · 2018-04 · on “Ask HN: What is your favourite tech talk?”
Really excited to go through all the other talks listed here I'm not familiar with! Three talks that I tend to reference a lot and have had a huge impact on the way I think about software: The Soul of Software: Avdi Grimm - [LINK] The Humane Representation of Thought: Bret Victor - [LINK] How to Program Independent Games: Jonathan Blow - [this video]
Strong rec tompark · 2021-02 · on “Making Games on Your Own as an Engineer”
TFA has some good points. I'd go even further on the situation where you quit your job to work on an indie game -- if you ever find yourself doing this, and you've never built a game by yourself before, you'd better have several years of runway. For many years one of my favorite talks about indie games development was Jonathan Blow's speech at UC Berkeley CSUA (2011) ( [LINK] ) Initially I loved his main message during the talk: "You have to be brutally effective to finish a project in a reasonable amount of time." But there's a part in the Q&A that later grew to be even more poignant to me: [this video] > Q: You said you worked on many projects before Braid which didn't quite get completed. What
Recommends kelukelugames · 2015-02 · on “‘Braid’ creator sacrifices his fortune to build his next game”
I've followed Jonathan Blow for a while. He has a reputation for being condescending. If you follow him a Twitter then you might come to the same conclusion. But he has given some amazing talks. [LINK] <-compares games to televison [LINK] [LINK] [this video]
Recommends nulltype · 2015-09 · on “The Witness: the creator of Braid talks about his fiendishly difficult new game”
For anyone interested in just programming, he has a great talk here: [this video] about "how to program independent games". Much of the advice seems to apply to other programming projects too.
Recommends arriu · 2020-10 · on “Ask HN: Good C++ code bases to read?”
I've always encouraged people to check out Jonathan Blow's talk on this topic ( [this video] ). He points out many reasons why this type of code would actually be the optimal version when weighing other factors. Simple code is easy to write, maintain, and optimize later. Despite the code looking messy, I find it easy to understand and navigate. A counter example of truly confusing code, which kind of does similar things, would be something like this: [LINK]
Recommends lackbeard · 2021-01 · on “Ask HN: What does mastery look like in software engineering?”
Example masters: John Carmack, Jeff Dean, Bram Cohen. What do they do? I think they're all extremely effective at getting things done. So be smart, hard working, and laser focused on shipping. A long time ago I saw a good talk by Jonathan Blow wherein he made a point that really resonated with me. The point was that to get good at programming you need the experience of shipping a lot of programs and thus you should optimize your career around shipping as many good programs as you can. Contrast this with the common advice of being an expert in databases, or distributed systems, or OOP, or testing, or something like that... Edit: found the talk: [this video]