A personal canon of tech talks and blog posts

If someone asks me "what's on your mind when it comes to building software?", this page is my response. I was inspired by Sandy's thinkylinks and Bret's five-star list. Brendan said it best when describing his personal canon:

These are the things that influence my work and thinking; the things that I return to and share with others again and again.

MOST RESONANT a

• Magic Ink, Bret Victor, 2006
  
  As a novice developer, I used to sling widgets around until my software looked ok. Then Magic Ink shook me: graphic design is a prerequisite to interface design. I ought to master the static display of information before adding interactivity. No wonder my software looked amateur. Ever since then, I've been digging into the worlds of design and user experience (UX) and human-computer interaction (HCI). I want to call myself a designer now, or at least design-informed. It's all been quite eye-opening.
  
  I look back on the essay with doubts: Aren't standard GUI widgets more usable than bespoke dataviz, especially with e.g. modern datepickers? Can maps and timelines actually fit on smartphone screens? At least I'm equipped to answer these design questions now.
• Metamuse podcast, Mark McGranaghan & Adam Wiggins, 2020-2023
  
  This Ink & Switch production scratches all my itches at once: toolmaking, development, design, and creative work. So many good HCI breadcrumbs to follow. I particularly enjoy episode 42 on personal tools, 59 on infinite canvases, and 28 on games.
• Simple Made Easy, Rich Hickey, 2011
  
  
  • simple = one fold, independent, not complex like a knot
  • easy = nearby, convenient, not hard to understand
  • a simple (untwisted) architecture is flexible, buying opportunities; not trying to drag an elephant around
  • easy can be bad; easy could mean gem install some-hairball, which is a trap
  • consider the semantics of language features, like positional args versus keyword args, and imperative code versus declarative code
  Now, whenever I code, I think "is this the simplest, least twisted architecture?" And whenever I give tasks to people, like in a README or a UI, I think "is this easy for people? Should it be easy?" This all falls under the umbrella of friction and usability, which are always at the front of my mind.
  
  Also, Hickey's obsession with definitions reminds me that words mean different things to different people. Now I'm careful to clarify even basic terms.
• An app can be a home-cooked meal, Robin Sloan, 2020
  
  "Home-cooked" is a great metaphor. Be free! Be independent, be satisfied. Make personal software. Avoid other people's problems and bloat. This is this hobbyist way.
• The Curse of Knowing How, or; Fixing Everything, raf, 2025
  
  I feel both the urge to rewrite every piece of annoying software, and also the acute awareness that I only have so many cares left to give. I'm learning to make peace with clunky tools, to ration my cares. There's a lot at play here: perfectionism, personal software, growing older, letting go.
• Choose Boring Technology, Dan MicKinley, 2015
  
  Boring means stable, unsurprising, and productive. Can I handle the cost of adopting an immature tool? Spend innovation tokens wisely. "How to be old, for young people."
• The Grug Brained Developer, Carson Gross, 2022
  
  
  • "apex predator of grug is complexity. complexity bad. say again: complexity very bad"
  • "sometimes grug go too early and get abstractions wrong, so grug bias towards waiting"
  • "grug, like all sane developer, fear concurrency"
  • "nobody imposter if everybody imposter"
• Tech Burnout - A Retrospective (archived), Lewis Campbell, 2022
  
  This one is an interesting mix of mental health and tooling. I'm interested in protecting my brain because it's my most valuable programming asset. Burnout has a terrible way of ruining brains for months or years. How can I avoid burnout? How can I recover?
  
  The good news is that brains can heal, but the bad news is that the road to recovery is not well-paved. Leaving the stressful situation (with extended leave or unemployment) along with basic personal care (sleep, diet, exercise, friends, etc.) will stop the damage. But how do I start working again? How do I ease into low-stress work?
  
  I think an understated bit, which Campbell mentions, is how developer tools play a role in this process. Clunky tools might trigger deep stressors — maybe with an excessive workload, lack of control, or sense of unfairness. Good tools might tell your brain "wait, programming actually doesn't have to be so painful after all," and I think about that every time I'm using a particularly painful or painless tool.
• The Web’s Grain, Frank Chimero, 2015
  
  I try to design websites and applications that go with the grain of the web, not against it. This means understanding the medium and playing to its strengths: vertical scrolling rather than horizontal, fluid viewport layouts rather than fixed breakpoints, hyperlinks rather than faux-links, etc.
• Command-line Tools can be 235x Faster than your Hadoop Cluster, Adam Drake, 2014
  
  Drake shows the power of knowing the right Unix incantations. This was an early motivator for me to get comfortable with command-line tools. As someone else said, "computers are fast if you know what you're doing."
• Roads and Bridges, Nadia Eghbal, 2016
  
  A history of open source, covering all the watershed moments (fiascos) up to 2016. This context is necessary to understand modern open-source drama and building software at large. There's dependency issues, maintenance issues, financial issues, social issues. The system is unsustainable.
• Chesterton's Fence, G.K Chesterton, 1929
  
  "Don't remove something until you know why it's there," and the rarer corollary, "don't add something until you know why it's not there." How do I find the context to inform changes? On a small scale, I think about documentation, decision logs, and onboarding. On a larger scale, I think about software historians, webdev churn, and graybeards.
• Thinking bout linting, Brian Brennan, 2020
  
  Elm, Rust, and Shellcheck teach a language while validating it by giving helpful error messages. This is the bar I set for language tools. Imagine if your C compiler described what was broken, why it was broken, and how it could be fixed. Imagine if your HTML/CSS/JS processor warned you about cross-browser quirks.
• Front-of-the-front-end and back-of-the-front-end web development, Brad Frost, 2021
  
  Front-end development is an overloaded term. More important, though, is how ballooning responsibilities and layers of abstraction contribute to burnout, imposter syndrome, and a host of other issues. See also Coyier's great divide ("Two front-end developers are sitting at a bar. They have nothing to talk about.")

HONORABLE MENTIONS a

• The Birth & Death of JavaScript, Gary Bernhardt, 2014
  
  Interesting to see Bernhardt's prophecy play out over the years. The web remains the most convenient way to run software. How far will Wasm go? I want to build in this space.
• Discovering Python, David Beazley, 2014
  
  Locked in a vault with Windows, Python, and a notebook, how do you grok 1.5TB of source code? Be just as proficient as Beazley. Makes me wonder how would I fare offline.
• The AWK Progamming Language, Aho, Kernighan, & Weinberger, 1988
  
  A fantastic piece of technical writing. I was first enticed by the chart on page 136 (who knew AWK could plot cool ASCII charts?) Then I finally read the book and wrote a few AWK scripts.
• CS50 Lecture 0, David Malan, 2018?
  
  CS50 excited me as a novice programmer. I admire how CS50, especially Lecture 0, stays engaging while covering so much material. It's rare to find such a polished curriculum along with such a practiced teacher.
• It Was Never Going to Work, So Let’s Have Some Tea, James Mickens, 2015
  
  Mickens is like Hannibal Buress doing PowerPoint standup for sysadmins. I don't think I learn anything from his keynotes, but I'm always entertained.
• My Kind of REPL, Ian Henry, 2023
  
  Unit tests are a hassle with little reward. Inline snapshot testing is a clever way to remove the friction.
• A Tour of the Acme Editor, Russ Cox, 2012
  
  Acme is an elegant, programmable text UI.
  • Everything is text, and any text can be executed
  • Define your own commands and plumbing
  • IDE as an integrating development environment, bringing your tools together (not a kitchen sink application)
  I feel like I could give up my vim workflows (!) and be right at home with Acme if it weren't for all the mousework. I remember watching this demo and thinking "huh, Plan 9 is actually worth trying; let me look into their ideas. What other UI paradigms never became popular?"
• Live React: Hot Reloading with Time Travel, Dan Abramov, 2015
  
  Time travel debugging is a cool feature, even if you don't care for React. This is the power of view = function(state). I also enjoyed Abramov's interesting life story leading up to this talk.
• The Mother of All Demos, Douglas Engelbart, 1968
  
  Like the Citizen Kane of tech demos and HCI: way ahead of its time, but a wee boring today. Mouses and hypertext are not exciting anymore... but they had multiplayer cursors and videochats 50 years ago!?
• The Most Beautiful Program Ever Written, William Byrd, 2017
  
  Byrd spends his life geeking over Lisp. Every now and then, I listen to him and remind myself of the joy in lambda calculus, in programming languages, in computer science. One day I'll try a Lisp and understand what he says.
• Hackety Hack, why the lucky stiff, 2009
  
  I like how _why insisted on keeping programming fun and approachable. What a masterful buildup to the final card game. Rough audio quality, unfortunately.
• War story: the hardest bug I ever debugged, Jacob Voytko, 2025
  
  Just another bug story, but noteworthy because it was the first time I heard debugging described as a binary search.
• The Day of a new Command-Line Interface: Shell, Bjorn Stahl, 2022
  
  It's crazy how 3+ layers of tooling (Ghostty, tmux, vim) simultaneously emulate the same grody protocol, and how we tolerate the awkward UX of interleaving stdin with stdout and stderr. Stahl shows what happens if we redesign everything from the ground up. See also libghostty.
• The web is already multiplayer, Tom MacWright, 2025
  
  Reminds me that webdev is an inherently difficult problem, not just because of bad tools or incompetence.
• The big idea (behind Unison), unknown?, 2023?
  
  What if source code was stored as syntax trees instead of text, with every node identified by its hash? It reminds me of the pleasantness and correctness of functional languages, but this time baked into tooling and infrastructure. What if someone actually makes it viable? I will be following Unison with great interest.
• You Don't Have to be a Developer, Nathan Contino, 2022
  
  Reminds me to consider programming-adjacent jobs, not just programming-only jobs. Code monkey is an increasingly fragile and upsetting role. See also "don't call yourself a programmer". I can choose a different persona: writer who codes, designer who codes, entrepreneur who codes, tradesperson who codes, struggling artist who codes...
• The Ideal Candidate Will Be Punched In the Stomach, Scott Smitelli, 2025
  
  Ouch. I haven't worked in soulless big tech, but I can empathize with these burnout conditions.