2 HN users recommended this talk1 month2023–2024score 1
Years with an HN recommendation, 2007–2026
HN draws on it for practical decision-making and problem-framing techniques that apply well beyond Clojure.
Rich Hickey's Clojure Conj 2023 talk on design in practice, covering problem statements, decision matrices, choosing precise words and making decisions in a team.
“A good approach to making decisions in a team context (also works for personal use) is explained by Rich Hickey here” (HN, 2024)
Rich Hickey has a section on using good words, on not using nicknames, in his (as ever wonderful) Clojure Conj 2023 talk Design in Practice, [this video]
Hickey on choosing good words and avoiding nicknames
A good approach to making decisions in a team context (also works for personal use) is explained by Rich Hickey here: [this video] The talks is called "Design in Practice" but is really about making decisions.
I experienced this in Scrum planning, daily standups, and other rituals were done with Excel shared via Zoom (or similar) meetings. The Scrum Master would ask each team member a question (e.g. estimation, etc.) and then fill the Excel while online, wasting everyone's time. Same with planning, there will be some basic template for a sprint, and it will be filled with the estimations/Jira tickets during the online meeting! Given said that, there are some valid uses for shared spreadsheets in Product/SDLC. One method I used is specific for data engineering projects: the product fills Excel/Google Spreadsheet with the example input, output shapes in the form of tables, and the developers asking question while they arriving to common spec. Another is called Decision Matrix (almost as old as Periodic Table;), which was recently popularized by Rich Hickey in his talk Design in Practice[1,2]. Another valid usecase for shared spreadsheets is Use Cases table. --- [1] [this video] [2] slide #31 [link]
Rich Hickey's decision matrix approach in design talk
Reminds on Rich Hickey ranting about touch screens in cars [1] in Design in Practice: > We do not have feature X" is never a valid problem statement. If you need proof of this you only need to look at a modern car which has a touch screen where no one said, "I need to slide my finger on some random piece of glass to a precise point to set my blower in my car while I am driving." No one has ever said that, right? But somebody did say, "We need touch screens because young people will never buy our cars." This is what happens when you are not talking about the problem. [1]: [this video]
Hickey argues problem statements must not be missing features
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
Plays via YouTube's privacy-enhanced embed
4 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Citations, criticism and jokes
Read more