Oliver Powell put this amazing original list together in 2016. While I didn’t appreciate the gravity of the list at the time, the talks have actually changed how I think about programming. Each of the presenters is not only incredibly intelligent but they have some serious credentials and achievements behind them. They in essence have much wisdom to impart. For example Rich Hickey, the creator of Closure, is brilliantly articulate and thought provoking.

I have started to sprinkle in other talks that have deeply impacted the way I think about software and complex systems. For example, Bryan Cantrill from his Sun Microsystems fame most renown for DTrace, is perhaps my favourite computer scientist to watch. All of his talks are bursting with passion and wisdom.

Rich Hickey on Simple Made Easy


Simplicity is the ultimate sophistication - Leonardo da Vinci

Incredibly profound. Rich debunks many fads software developers jump into without thinking about too deeply.

  • Simple is NOT easy, and easy is NOT simple
  • Simple is One fold/braid, One task, One concept, One dimension (NOT One instance, or One operation)
  • Simple is about lack of interleaving, not cardinality
  • Easy is Near, at hand
  • Simple is HARD
  • Complecting; the act of making something complex and tangled, often through the act of EASY decisions
  • Refactoring and TDD do not aid in deep understanding on a distilling simplicity. They are like slamming your car into the guard rails on the roadside.

Complecting; To interleave, entwine, braid

Complex abstractions vs simple abstractions:

Complexity Simplicity
State, Objects Values
Methods Functions, Namespaces
vars Managed refs
Inheritance, switch, matching Polymorphism a la carte
Syntax Data
Imperative loops, fold Set functions
Actors Queues
ORM Declarative data manipulation
Conditionals Rules
Inconsistency Consistency

Rich’s simplicity toolkit:

Construct Get it by
Values final, persistent collections
Functions Stateless methods
Namespaces Language support
Data Maps, arrays, set, XML, JSON (NOT objects!)
Polymorphism a la carte Protocols, type classes, interfaces
Managed refs Clojure or Haskell refs
Set functions Libraries
Queues Libraries
Declarative data manipulation SQL, LINQ, Datalog
Rules Use declarative rule systems (NOT embedding conditions in our raw language)
Consistency Transactions, values

Designing simple constructs:

  • Abstract definition; to draw away
  • Seeks answers to who, what, when, where, why and how
  • What? Declarative contract of operations (with polymorphism tool lang gives you), small cohesive sets, don’t complect with How. By strictly separating what from how, is the key to making how something else’s problem (e.g. database or logic engine you figure out how to solve this problem).
  • Who? Entities implementing abstractions, build entities from injected and granular subcomponents, smaller interfaces, way more subcomponents
  • How? Implementing the actual logic. Connect abstractions and entities using polymorphism constructs. Abstractions should not dictate how. Implementations should be islands.
  • When and Where? Stenuously avoid complecting these with anything in the design. Often seep in via directly connected objects (e.g., A directly invokes B, A must know about B now and also when B is ready to receive a message). Use queues extensively to break this coupling. Use queues RIGHT NOW.
  • Why? Policy and rules of the application. Hard. Often scattered in logic everywhere. Find a declarative or rules system.

Information is simple:

  • Don’t ruin information.
  • By hiding it behind a micro-language (i.e., a class with information specific methods)
  • Mashing information in objects thwarts generic data composition (i.e., ruins the ability to build generic data manipulation)
  • If you leave data alone, you can build things once that manipulate data and re-use them all over the place.
  • Packing data into objects ties logic to representation, complecting
  • Represent data as data; start using maps and sets directly, not writing a new class for each new piece of information!

Simplicity made easy:

  • Choose simple constructs over complexity generating constructs (see toolkits above)
  • Create abstractions with simplicity as a basis
  • Simplify the problem space before starting
  • Simplicity often means making more things, not fewer (i.e., rather have more straight things hanging down simply, than fewer strands all twisted together).

Mike Acton on Data-orientated Design


Jonathan Blow on Programming Aesthetics learned from making independent games


  • Avoid optimization (and wasting time thinking about it). You don’t usually need it in most cases.
  • Use Arrays for everything. Data structures are about optimisation.
  • Don’t build generalized systems. They are worse than hard-coded ones.
  • Deleting code is better than adding code.
  • Prefer big top-to-bottom straightforward functions, instead of function calls

Eskil Steenberg on How I program in C


This is a talk I (@eskilsteenberg) gave in Seattle in October of 2016. I cover my way of programing C, the style and structure I use and some tips and tricks. Fair warning: There is a fair bit of Programming religion in this talk.

Rich Hickey on Hammock Driven Development


Presentation breakdown and notes

Many gems, here’s one:

  • Problem solving is definitely a skill. Polya wrote this amazing book called, ‘How to Solve It’ in 1945 which is about how to practice and what the techniques of solving math problems, in this case. It’s a terrific book, full of great insight and if you’ve never read it, go onto Amazon right after my talk and order yourself a copy.

Brian Will on Why OOP is Bad


Abner Coimbre on What Programming is Never About


Scott Meyers on CPU Caches and Why You Care


Jeff and Casey Show on The Evils of Non-native Programming


Jeff and Casey’s Guide to Becoming a Bigger Programmer


Hadi Hariri on The Silver Bullet Syndrome


Bryan Cantrill on Fork Yeah! The Rise and Development if illumos


Some great history about Sun Microsystems. Perhaps my favourite quote (copied from news.ycombinator):

As you know people, as you learn about things, you realize that these generalizations we have are, virtually to a generalization, false. Well, except for this one, as it turns out. What you think of Oracle, is even truer than you think it is. There has been no entity in human history with less complexity or nuance to it than Oracle. And I gotta say, as someone who has seen that complexity for my entire life, it’s very hard to get used to that idea. It’s like, ‘surely this is more complicated!’ but it’s like: Wow, this is really simple! This company is very straightforward, in its defense. This company is about one man, his alter-ego, and what he wants to inflict upon humanity – that’s it! …Ship mediocrity, inflict misery, lie our asses off, screw our customers, and make a whole shitload of money. Yeah… you talk to Oracle, it’s like, ’no, we don’t fucking make dreams happen – we make money!’ …You need to think of Larry Ellison the way you think of a lawnmower. You don’t anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it’ll chop it off, the end. You don’t think ‘oh, the lawnmower hates me’ – lawnmower doesn’t give a shit about you, lawnmower can’t hate you. Don’t anthropomorphize the lawnmower. Don’t fall into that trap about Oracle.

Rob Pike on Concurrency Is Not Parallelism


James Mickens on JavaScript


Liz Rice on Containers From Scratch


James Mickens on Why Do Keynote Speakers Keep Suggesting That Improving Security Is Possible?