HN repeatedly calls it the best talk on testing, and many say it changed how they approach tests, mocks and the meaning of a unit.
Topics › Software Engineering & Languages
The best software practice, open source & careers videos, according to Hacker News
151 videos about software practice, open source & careers 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 a classic, near-mandatory talk on how programming tools and paradigms stagnated and which older ideas deserve revival.
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 repeatedly names it among the best programming talks, loved for its craftsmanship message that complex tooling can hide simpler solutions.
Recurs in threads about RSI, accessibility and voice coding as the go-to demo of a custom spoken command language.
HN treats it as a must-watch classic for writing Pythonic code, though somewhat dated for modern Python.
Offered in nearly every Agile or Scrum complaint thread as the authoritative take on what agile was meant to be versus what it became.
HN's standard reference when typing speed, ergonomics, or alternative input comes up, for its live demo and the open-source steno ecosystem.
Recommended repeatedly as a funny, informative talk on the economics behind programming languages and open source.
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 treats it as a classic, must-watch talk for any discussion of company values, and especially for its takedown of Amazon's leadership principles.
Regarded as a brilliant live-coding talk that teaches WASM and interpreter writing, with several calling it among the best conference talks they have seen.
HN regularly names it among the best programming talks ever, praising the storytelling, the demos and the ending.
HN commenters call it better than the Clean Code book, a must-watch for engineers that changes how they read and write code.
Repeatedly recommended in mental health threads for its honest storytelling that resonates with developers.
It is the go-to recommendation whenever someone asks about voice coding or RSI-friendly programming setups.
HN recommends it as an entertaining, well-delivered talk full of stories that shows the value of historical context and long comments in code.
HN commenters repeatedly share it because it is an eye-opening look at screen-reader use, and because at about 6:30 it addresses how inaccessible Hacker News itself is.
HN recommends it as an insightful look at the people side of open source maintenance, especially in Elm and maintainer-burnout threads.
HN commenters pass it around as an eye-opening first-hand account of patent trolling and the Texas courts that favor it.
HN regulars recommend it as a career-shaping talk on code review, humility and collaborative development.
Whenever notebooks get criticized, HN commenters point to it as the standard rebuttal from a prominent practitioner.
HN keeps pointing to it as a thoughtful vision of programming for non-programmers and as background on Eve's motivations.
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 cites it in discussions of language evangelism, community dynamics and zealotry, as an accessible account of how a good language can die for non-technical reasons.
HN cites it as the example of a better alternative to whiteboard and fizzbuzz-style interviews.
Cited in threads about teaching kids and beginners to code as research-based evidence that explicit instruction beats pure discovery.
HN programmers admire it as a clean, clever demonstration of emulator design and as the standout of a favorite programming YouTuber.
HN recommends it whenever a failure is blamed on human error, as a clear case study in looking for the systemic second story.
Recommended as the argument for code colocation and delaying abstraction.
Strongly recommended as a gripping case study whose lessons carry over to engineering management and safety.
HN recommends it for historical perspective on software ideas and for dispelling myths such as the origins of waterfall.
HN recommends it for the toybox intro and for Landley's candid account of software licensing and why he created the 0BSD license.
HN recommends it for changing minds about whether programmers can be called engineers, and for its take on how waterfall was misread.
HN links it as the authoritative correction to common misuse of the term technical debt, straight from its originator.
HN commenters recommend it as a practical illustration of what Org mode and literate programming can do for documentation.
HN people point to it as a rare chance to watch skilled developers write real code live, pair programming and explaining as they go.
HN points to it in discussions of programming as a creative craft and of how to write clear software.
HN recommends it in literate programming threads as a rare look at applying the idea to a huge, complex codebase, though some find it meandering.
HN commenters strongly recommend it as a thoughtful talk on tech worker ethics that has not aged.
HN treats it as a phenomenal demonstration that voice-driven development is viable and as an eye-opener on accessibility-unfriendly coding habits.
It is the go-to reference in debates about whether open source maintainers are owed compensation, and commenters say it is worth watching even for non-Rails developers.
Cited as a realistic, well-run example of a technical interview, both for candidates preparing and interviewers calibrating.
Commenters point to it as a clear take on why functional languages stall outside niches, and its lessons are seen as applying to any technology trying to go mainstream.
HN recommends it as a sober critique of agile, though one commenter found it mixed.
Linked often in hiring-process threads for the anecdote about Google's committee refusing to hire itself, as evidence interviews are noisy.
Recommended in C versus C++ and embedded threads as the expert view on adoption and persuasion.
HN commenters recommend it as a first-hand argument for building your own lean agent harness instead of relying on bloated, vendor-controlled ones.
HN recommends it as a Python talk with lessons that apply to any programming, especially chunking to manage complexity.
Held up as a rare success story of GPL enforcement against a Chinese hardware company, and admired for the effort.
HN people recommend it as the best way to understand what async machinery actually does under the covers.
HN recommends Cantrill's integrity rant when discussing corporate ethics and companies that act on principles.
HN lists it among its favorite programming talks and fantastic technical speeches.
Recommended to beginners asking how to start in web development as a compact survey of the toolscape of its time.
HN recommends it as the best concise introduction to a practical framework for structuring documentation, the basis of what became Diataxis.
HN points to it as an authoritative overview of the kernel's email-and-git workflow and its development rate.
Cited for watching Carmack code fluently and for the fast iteration cycle of Racket-based VR scripting.
HN commenters recommend it as a good talk on ethics in software engineering, and Cantrill himself cites it as capturing his views.
HN suggests it for coders curious how an outsider approaches coronavirus biology, though it is described as unscientific.
HN recommends it, especially to developers losing their sight, as a concrete demonstration of coding with text-to-speech.
HN commenters recommend it when asked how to learn better or keep improving.
Recommended as an entertaining story of a joke side project growing out of hand, brought up in threads on emoji and side projects.
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.
Recommended in estimation and sprint debates as a well-reasoned account of where waste is and isn't in agile.
HN recommends it in debates about software engineering rigor, agile, and formal methods.
HN commenters recommend it as a demonstration of SerenityOS's hackability and fast iteration across all layers of the system.
HN links it as a charming defense of bodging and of AutoHotkey, and as the go-to example when custom keyboards or hotkey hacks come up.
HN recommends it as a well-done history of Skunk Works, popping up in SR-71 threads.
Cited in debates over Elm's direction and open source health, with some praising its points about metrics and others finding its tone toward unhappy users hard to watch.
HN cites it as a firsthand account of how dysfunctional large IT projects can be, with about 50 contractors and no one in charge.
HN people recommend it as an evidence-based counterweight to opinion in software engineering debates.
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 loves the Browser hacking series for its clear debugging method of reducing bugs to minimal reproductions, which people say influenced their own testing.
Recommended as a funny parody that resembles agile as practiced at large companies.
HN commenters point to it as a convincing primary-source interview showing Zig's cohesive design vision and the creator's level-headed reasoning.
Recommended in solo-developer threads for its insights on shipping small projects with simple stacks and AI tools.
Recommended in debates over whether software is real engineering, as a well-argued case that building is cheap relative to simulating.
HN commenters cite it as Crockford's first-hand account of JSON's origins and of the no-evil license anecdote.
Cited as the go-to evidence that rudeness drives contributors away and that toxic people must be removed from projects.
Linked in licensing threads as a short, funny story about the 'no evil' clause and IBM's request for an exception.
HN recommends it for the idea of giving data instead of asking for it, and ties it to zero values and exception-free design.
Recommended as a clear description of how Kanban works and a practical alternative to sprints.
HN points people to it to understand Elm's design philosophy, such as favoring simplicity over type classes, when they question its choices.
Pointed to as a non-promotional, realistic long session of an experienced engineer working with AI on non-trivial code.
HN shares it as a concise critique of OOP from a respected systems programmer.
HN recommends it as an entertaining first-hand engineer account of what went wrong with healthcare.gov and how it was fixed, including that no one owned the whole site.
HN recommends it as the best account of what is wrong with npm's governance and why alternative or decentralized registries are hard.
Cited again and again in GPL licensing debates as the primary source for Linus's objections to GPLv3.
HN commenters invoke it whenever a company relicenses, forks, or announces an open source plan, and enjoy Cantrill's energetic, opinionated delivery.
HN points to it in monorepo and refactoring discussions as a great account of large-scale changes at Google.
HN commenters cite it as a funny and candid first-hand account of the guilt and burnout of a prolific open source developer.
HN recommends it as an entertaining talk on how working memory shapes code and how to reduce cognitive load.
Shared in outage and accidental-deletion threads as a relatable, well-told horror story.
HN holds it up as a vivid example of focused game-jam productivity, and it has been used to demystify programming for students and inspire tools for recording coding sessions.
A classic recommendation among JavaScript talks and for reading real library code to learn patterns.
HN recommends it as a comprehensive walkthrough of the build-your-own-BitTorrent challenge and as an introduction to CodeCrafters.
HN points to it as an entertaining, insightful talk about the nature of programming, with memorable lines about programmers and a refreshing slide style.
Cited in Scala and language-marketing discussions for its accurate account of Scala's pain points and its argument that a language's pitch must address a real developer pain.
Recommended as a practical, approachable build-it-step-by-step introduction to writing compilers, light on theory.
HN uses it as the key reference in arguments about Micay's conduct and GrapheneOS leadership, with some defending it and some urging skepticism.
Strongly recommended as an inspiring hour on how id worked, often linked in programming-practice threads.
Shared as a joke about JavaScript culture and tooling, usually without much explanation.
HN commenters cite it for the history of open source at Sun and Oracle, and for Cantrill's explanation of licensing choices.
Recommended in TDD and unit-testing threads as a balanced debate among three prominent developers that avoids dogma.
HN commenters use it in Ada discussions, including for Dewar's remark on how much costlier bugs are when found late.
HN uses it as the reference for whether software is really engineering and how it differs from other disciplines.
HN points to it when discussing AI-generated bug reports and vibe-coded pull requests burdening open source maintainers.
Pulled out in threads about declining software quality, though some commenters distrust Blow's claims about game and web development.
HN uses it as the reference for Linus's stance on rudeness and respect in debates about civility and gratuitous negativity.
HN refers to it in career and promotion discussions, including its warning about doing glue work too early in your career.
HN points to it as a fun, substantive exchange between two experienced practitioners on TDD's value.
HN mostly cites it as a source for Karpathy's framing of programming in English and his generate-then-verify workflow, with a few critics finding it hype.
HN points to it as an example of Notch's famous live-coding sessions, which drew many early Minecraft fans.
Cited for Joel's account of how Stack Overflow's design and community thinking were figured out from the start.
HN points to it as a pre-Wordle look at Wardle's thinking on designing online spaces, and as a brief postmortem of r/place.
Whenever HN asks whether you can program with steno, this is the go-to demo showing it working.
HN recommends it during the Muse Group acquisition controversy for its funny, pragmatic take on usability and open source stewardship.
HN cites it as a first-hand account of Microsoft's QA cuts and reliance on automated tests in threads about buggy Windows updates.
HN points to it as a look at developer infrastructure at large scale, with speakers covering source control and CI test selection.
Which of these have you already seen?
Connect YouTube and HackerTube AI hides what you've watched and ranks the rest for you.