HN treats it as a top-tier programming talk for learning refactoring and for the wrong-abstraction principle, recommended repeatedly over a decade.
Topics › Software Engineering & Languages
The best software architecture & design videos, according to Hacker News
171 videos about software architecture & design that Hacker News commenters keep pointing each other to, ranked by how many separate months they were recommended. Part of Software Engineering & Languages.
HN treats it as the canonical talk on software complexity, shared constantly and recommended to every programmer regardless of language.
HN repeatedly recommends it as a talk that changed how people model data, with ideas that apply well beyond Elm to any typed language.
HN repeatedly names it the best resource on API design, a staple answer to any 'how do I design an API' question.
HN commenters cite it as the talk that convinced them of immutability and functional programming.
HN repeatedly recommends it as a fantastic demonstration of procedural, OOP and FP approaches to the same problem, and of functional core and imperative shell.
HN people recommend the SICP lectures as a deeper, livelier route into the book and a formative course even for seasoned programmers.
A staple on must-watch lists, recommended as a starting point for Kay's thinking and for why software is often poor and ahistorical.
HN treats it as the standard one-hour teaser for the book and recommends it for its deep-modules thinking before buying or reading the book.
HN recommends it as an engaging overview of programming history and an argument for professional standards, citing the agile manifesto section and the claim that software has advanced little since the 1950s.
HN's go-to link in typing debates and for talk lists, and several call it their favorite programming talk even for non-Clojure users.
HN repeatedly recommends it as the definitive explanation of why Java evolves cautiously and why compatibility matters in language design.
Frequently recommended as an influential talk on decoupled, testable architecture, though some commenters push back on Martin's TDD advocacy.
HN treats it as the go-to explanation of ECS, valuable even for people who don't use Rust.
HN returns to it constantly as permission and method for thinking deeply before coding, and as an antidote to always-working anxiety.
HN recommends it as a talk whose advice on simplicity and avoiding unnecessary work applies well beyond games.
HN recommends it as the canonical presentation of 'functional core, imperative shell' and a practical answer to unit versus integration testing.
HN treats it as the definitive explanation of Conway's Law and links it in almost any thread about org structure shaping software.
It is one of HN's most frequently recommended programming talks, cited whenever people debate complexity, simplicity and abstraction, and valued well beyond Clojure.
HN returns to it in every versioning and API stability debate as a challenging, contrarian talk worth watching.
It is the go-to talk HN points to for data-oriented design and hardware-aware performance thinking, despite Acton's blunt style.
HN recommends it as the one long programming video worth watching, a provocative and influential take on C.
HN returns to it as the go-to critique of OOP, recommended for explaining the costs of abstraction better than most written arguments.
HN recommends it as a key Hickey talk on system design that changes how people think about distributed state and interfaces.
HN returns to it repeatedly as the canonical argument for simplicity and against premature abstraction, and several commenters say it changed how they write code.
HN calls it the famous talk for understanding why React rejected separation of concerns by technology and for newcomers puzzled by JSX.
HN repeatedly recommends it as the talk that made data-oriented, REPL-driven bottom-up design click.
HN returns to it constantly as a witty, still-accurate diagnosis of why software is bloated and messy, and as a go-to recommendation in any thread on modules, package managers or software quality.
HN recommends it as an alternative or companion to 'Simple Made Easy', and quotes its ideas about simplicity, complexity and 'hairballs' in discussions of frameworks, JSON and data design.
HN commenters recommend it for its source-based history of OOP, though some dispute its account of Alan Kay.
HN commenters call it better than the Clean Code book, a must-watch for engineers that changes how they read and write code.
HN repeatedly cites it as a thought-provoking talk on reducing software complexity and on the state of computing research.
HN people recommend it as an eye-opening talk whose domain-modeling ideas carry over to other languages and make a strong compiler feel like a coding partner.
Cited constantly in threads on microservices, composability and the Unix philosophy as a compact explanation of why small interoperable pieces win.
HN calls it one of the best technical talks and the clearest explanation of decorators, generators and context managers.
HN commenters in memory management and language design threads cite it as the best explanation of group lifetimes versus per-object ownership.
Go-to reference in GTK versus Qt debates, valued for a candid account from experienced developers who tried both toolkits.
Recommended as a practical demonstration of how functional thinking improves design without going off the deep end.
HN uses it in debates about what OOP originally meant, since Kay's message-passing view lines up with Erlang's processes.
HN repeatedly recommends it as a balanced, beginner-friendly overview of SQL versus NoSQL, and some teachers assign it to students.
Recommended whenever versioning, semver, monorepos and backward compatibility are debated, for its nuanced treatment of dependencies.
HN treats it as the original and definitive explanation of transducers, recommended whenever the concept comes up.
HN points to it as a practical way to separate business logic from I/O, which reduces mocking and underlies the functional core, imperative shell idea.
Cited as the classic rant on maps versus objects in discussions of data modeling and OOP.
HN commenters recommend it as the definitive explanation, from a language designer, of why multiple dispatch makes Julia's composability work.
HN commenters, including TigerBeetle people, recommend it as the explanation of a methodology for building defect-free, high-assurance software.
HN commenters credit it with persuading them to adopt React, and cite it for the argument that HTML and JS cannot truly be separated.
HN recommends it as an enthusiastic demo of spreadsheet-like reactive notebooks, which commenters think new notebook projects should copy.
HN commenters point to it as a sharp, example-driven critique of OOP and Clean Code style, often alongside Brian Will's other anti-OO videos.
HN commenters recommend it, alongside Rich Hickey's talk, for its precise definition of simple versus easy and its implications for code design.
Seen as the definitive explanation of why traditional concurrency is hard and how Clojure's model addresses it, with some commenters crediting it with changing their careers.
HN commenters treat it as a thought-provoking talk on invention versus innovation, and cite it in discussions of software complexity and startups.
Treated as a foundational talk, cited constantly for Kay's views on object-oriented programming and for rethinking software practice.
HN points people to it as Lamport's own case for thinking and writing a spec before coding, and as an entry point to TLA+.
HN cites it as the primary source for the claim that Alexander deprecated patterns, and as a prescient talk for programmers.
HN recommends it as a talk that changes how you think about system design, and links it whenever constraints, abstraction or least power come up.
Recommended as one of the best explanations of why Clojure and a functional, immutable approach to state exist.
HN recommends it as an incredible talk whose testing principles apply beyond Ruby.
HN fans call it one of Kay's best talks and recommend it for rethinking why programming paradigms have barely changed.
HN points to it as thought-provoking material on the tradeoffs and costs of abstraction, especially in frontend tooling debates.
HN points to it as the original talk that explains the motivation behind React, Flux and Redux, and that sold some commenters on React.
HN cites it whenever people discuss rebuilding the web platform or what a better browser architecture could look like.
Recommended as a clear, charismatic starting point for understanding Python concurrency and the GIL.
HN commenters point to it as the best practical introduction to Alloy and to lightweight formal modeling.
HN cites it as one of the best talks on data-oriented design, applying struct-of-arrays and compact data layouts to a real compiler.
HN developers recommend it as the talk that changed how they model systems, and as a clear intro to event sourcing's motivations.
HN commenters love it as a witty and insightful tour of design anti-patterns, applicable to DSLs, OOP and API design.
Recommended as the argument for code colocation and delaying abstraction.
Seen as the origin of the IMGUI idea that inspired Dear ImGui, recommended to anyone curious about immediate-mode UI design.
A frequent citation in debates about SOLID and Clean Code, representing the performance-first side of the argument.
HN recommends it as a terrific talk on APL readability and on the idea of idioms over libraries.
HN treats it as the canonical, approachable example of domain-driven design with types and 'make invalid states unrepresentable'.
HN recommends it for historical perspective on software ideas and for dispelling myths such as the origins of waterfall.
HN points people to it as the clearest account of why Datomic is designed the way it is and of the problems with conventional database architecture.
HN treats it as the classic talk on why Deno exists and on lessons from design mistakes in a widely used platform.
HN recommends it as the best beginner-friendly introduction to monoids, monads and other FP vocabulary.
The standard link for explaining the concurrency versus parallelism distinction and the motivations behind Go's concurrency model.
HN links it as the authoritative correction to common misuse of the term technical debt, straight from its originator.
Recommended as the case for blocking code and virtual threads over monads and async/await.
HN commenters recommend it as the lead ClojureScript developer's own account of Om's evolution, one-way data flow and single-state design.
HN recommends it as a funny, smart and well-constructed talk on abstraction, duplication and object-oriented design.
Recommended in incremental computation and reactive UI threads as the best conceptual overview of Incremental and incr_dom.
HN recommends it in testing-strategy debates as the classic case for fewer integration tests and more small, well-contracted unit tests.
HN recommends it as a sober critique of agile, though one commenter found it mixed.
HN commenters point to it as an alternative take on the data-fetching problem GraphQL addresses, and as a clear argument for when RPC or graph models beat plain REST.
HN engineers recommend it for its core insight that limiting concurrency naturally yields request-rate limits, and for its link to queueing theory.
Commenters say it changes how you think about types and the STL, and makes a case for simple modern C++.
Recommended in DRY versus duplication debates for its visuals and its case that copy/paste can beat a wrong abstraction.
HN recommends it for Kay's blunt critique of today's computing and standard CS curricula.
HN commenters cite it whenever JavaScript classes, `this` or inheritance come up, as the clearest case for classless OOP from Crockford.
HN lists it among its favorite programming talks and fantastic technical speeches.
HN commenters point Rubyists and the Smalltalk-curious to it as an approachable introduction that shows the Smalltalk system browser and Pharo environment in action.
Recommended as the foundational talk on content-centric and named-data networking, and for its internet history stories.
HN people recommend it as a fascinating history lesson showing that the field keeps rediscovering ideas from the 1960s.
Recommended whenever the STL mindset or avoiding raw loops in C++ comes up, as an enlightening talk on expressive algorithms.
HN commenters recommend it as a level-headed, practical take on design patterns without Java-style verbosity.
HN commenters recommend it as a thorough treatment of replacing conditionals with polymorphism and why flags and deep ifs can be code smells.
HN commenters cite it as a level-headed counterpoint to ECS zealotry and a good intro to game architecture beyond ECS.
HN commenters point to it as a good talk on how one person built a major free, open-source chess server with few resources, and on the cheating problem.
HN recommends it as a good overview of modern C patterns, including in threads about learning C.
HN recommends it in debates about software engineering rigor, agile, and formal methods.
HN uses it as the canonical example of rapid application development and object-oriented tooling productivity, though many note it is biased marketing.
The go-to reference in monorepo and trunk-based development discussions, recommended as a firsthand account of how Google manages source control.
Often brought up as an honest account of microservice sprawl, including the fact that nobody at Uber knew exactly how many services existed.
HN recommends it as the best starting point for understanding the Wasm Component Model and WASI direction, straight from its designer.
Recommended as the introduction to C4 when people ask how to visualize and communicate software architecture.
HN cites it as a concrete, worked example of data-oriented design and as an alternative to OOP in performance-sensitive code.
HN people point to it as an excellent, inspirational talk on Rust GUI architecture, and it led many to the Druid project.
HN readers cite Kay's talks for his views on programming languages as user interfaces, thinking beyond logic, and why people struggle with complex systems.
Recommended as a formative talk on architecture that argues against putting the database at the center of a design.
HN cites it as a formative talk on what OOP really is, and on why teams write code that slows them down.
HN recommends it as a concrete, worked example of the case against heavy OOP rather than abstract argument.
HN commenters recommend it for showing the tooling possible when schemas and APIs are treated as code.
Shared as developer humor, with commenters insisting any Dylan Beattie mention must come with this song.
Recommended as a clear introduction to structured concurrency and as an explanation of subtle asyncio bugs that Trio avoids.
Recommended in debates over whether software is real engineering, as a well-argued case that building is cheap relative to simulating.
Pointed to as a thought-provoking talk on structuring large systems, including outside Clojure.
Recommended to people who call Rails bloated, as an argument that its size comes from features you eventually need.
HN cites it as a statement of React's early design philosophy of keeping APIs small and understanding JavaScript itself.
Frequently cited for the claim that Photoshop's codebase could shrink dramatically with generic programming.
Which of these have you already seen?
Connect YouTube and HackerTube AI hides what you've watched and ranks the rest for you.