korrents

← Topics

When does an abstraction help, and when does it hurt?

Top voices on simplicity: Sandi Metz, Casey Muratori, Martin Kleppmann, Naval Ravikant and 7 others.

They argue over when to share code, whether the classic clean-code rules help, and what hiding the details costs.

17 dated claims from 11 people · 4 views · most recent 25 Sept 2026

The views

What is a view?

Our reading of what a group of claims have in common, one level above a korrent: a korrent is our reading of what somebody said, a view is our reading of what several korrents share. The claims are printed under it, so the sentence can be checked against them.

Nobody is filed under a view — claims are. A person is named here because a dated claim of theirs sits under it, and somebody whose claims sit under two views appears under both.

  1. Duplication is cheaper than the wrong abstraction, so wait for real examples before sharing code

    Peter SteinbergerTobias LütkeSandi MetzCasey Muratori

  2. The rules taught as clean code make programs worse, and slower

    Casey Muratori

  3. Every abstraction leaks, so somebody has to know the layer below it

    Martin KleppmannFlora GuoNaval RavikantPhil Hagelberg

  4. A higher level of abstraction moves the difficulty somewhere else; it does not remove it

    François CholletAddy Osmani

A viewour reading

Duplication is cheaper than the wrong abstraction, so wait for real examples before sharing code

6 claims filed here, newest first — each in the words of whoever said it.

Show all 6 claims

An abstraction chosen wrongly at the start means a team can never make its software great, however good that team is.

  1. Tobias Lütke Co-founder and CEO of Shopify Just imagine you use very bad software and um the team that started the project decided early to use Xamarin and then they never had a chance of making this as good as all the other things you really appreciate on your phone due to this decision no matter how good they are. ACQ2: How to Live in Everyone Else's Future (with Shopify CEO Tobi Lütke)youtube.com · 18 Sept 2025 · 0:11:11 into the videoAll korrents from this video
    Just imagine you use very bad software and um the team that started the project decided early to use Xamarin and then they never had a chance of making this as good as all the other things you really appreciate on your phone due to this decision no matter how good they are.

    Watch from 0:11:11 plays here

    ↗ACQ2: How to Live in Everyone Else's Future (with Shopify CEO Tobi Lütke)youtube.com

    18 Sept 2025 · video · 1h 48m · spoken · machine transcript

Duplication is cheaper than the wrong abstraction, so code should not be made reusable before there are real examples of what the reuse has to do.

  1. Sandi Metz Author of Practical Object-Oriented Design in Ruby and 99 Bottles of OOP duplication is far cheaper than the wrong abstraction The Wrong Abstractionsandimetz.com · 20 Jan 2016All korrents from this piece
    duplication is far cheaper than the wrong abstraction
  2. Casey Muratori Game and engine programmer Like a good compressor, I don't reuse anything until I have at least two instances of it occurring. Semantic Compressioncaseymuratori.com · 28 May 2014All korrents from this piece
    Like a good compressor, I don't reuse anything until I have at least two instances of it occurring.

Existing code exerts a powerful influence: its presence argues that it is correct and necessary, and sunk cost keeps teams inside an abstraction that has stopped fitting.

  1. Sandi Metz Author of Practical Object-Oriented Design in Ruby and 99 Bottles of OOP Existing code exerts a powerful influence. Its very presence argues that it is both correct and necessary. The Wrong Abstractionsandimetz.com · 20 Jan 2016All korrents from this piece
    Existing code exerts a powerful influence. Its very presence argues that it is both correct and necessary.

When an abstraction turns out to be wrong, the fastest way forward is to inline it back into every caller and let the duplication show what the right one is.

  1. Sandi Metz Author of Practical Object-Oriented Design in Ruby and 99 Bottles of OOP Once an abstraction is proved wrong the best strategy is to re-introduce duplication and let it show you what's right. The Wrong Abstractionsandimetz.com · 20 Jan 2016All korrents from this piece
    Once an abstraction is proved wrong the best strategy is to re-introduce duplication and let it show you what's right.

Parameters and conditional branches accumulating inside shared code are the diagnostic that the abstraction is wrong.

  1. Sandi Metz Author of Practical Object-Oriented Design in Ruby and 99 Bottles of OOP If you find yourself passing parameters and adding conditional paths through shared code, the abstraction is incorrect. The Wrong Abstractionsandimetz.com · 20 Jan 2016All korrents from this piece
    If you find yourself passing parameters and adding conditional paths through shared code, the abstraction is incorrect.

A viewour reading

The rules taught as clean code make programs worse, and slower

3 claims filed here, newest first — each in the words of whoever said it.

The steady stream of "we had to rewrite the whole thing because it was too slow" engineering blog posts is the proof that deferring performance to hotspot optimization does not work.

  1. Casey Muratori Game and engine programmer They've got blog posts of we had to rewrite this whole thing because the performance was bad. If it was always hotspots that made your performance bad, you'd never have to rewrite the whole thing. So, we know that that doesn't work anymore. Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com · 26 Aug 2026 · 0:40:18 into the videoAll korrents from this video
    They've got blog posts of we had to rewrite this whole thing because the performance was bad. If it was always hotspots that made your performance bad, you'd never have to rewrite the whole thing. So, we know that that doesn't work anymore.

    Watch from 0:40:18 plays here

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com

    26 Aug 2026 · video · 1h 53m · spoken · machine transcript

Show all 3 claims

The specific rules taught as clean code are simply bad programming practices, and they get worse when you apply them together.

  1. Casey Muratori Game and engine programmer If you look at those things, they're kind of just bad programming practices. I I don't really know how else to say them. They don't mesh well when you put them together. Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com · 26 Aug 2026 · 1:18:34 into the videoAll korrents from this video
    If you look at those things, they're kind of just bad programming practices. I I don't really know how else to say them. They don't mesh well when you put them together.

    Watch from 1:18:34 plays here

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com

    26 Aug 2026 · video · 1h 53m · spoken · machine transcript

Code is procedurally oriented rather than object-oriented: objects are just constructs that emerge to let procedures be reused.

  1. Casey Muratori Game and engine programmer Code is procedurally oriented, and the "objects" are simply constructs that arise that allow procedures to be reused. Semantic Compressioncaseymuratori.com · 28 May 2014All korrents from this piece
    Code is procedurally oriented, and the "objects" are simply constructs that arise that allow procedures to be reused.

A viewour reading

Every abstraction leaks, so somebody has to know the layer below it

5 claims filed here, newest first — each in the words of whoever said it.

Higher-level abstractions do not abolish low-level knowledge; they concentrate it in the smaller group of people who build the abstractions.

Leaky abstractions, Conservation of complexity

  1. Martin Kleppmann Computer science researcher at Cambridge But, somebody still has to build those lower-level abstractions and from lower-level components. Somebody's got to implement the cloud services. Designing Data-intensive Applications with Martin Kleppmannyoutube.com · 22 Apr 2026 · 0:32:17 into the videoAll korrents from this video
    But, somebody still has to build those lower-level abstractions and from lower-level components. Somebody's got to implement the cloud services.

    Watch from 0:32:17 plays here

    ↗Designing Data-intensive Applications with Martin Kleppmannyoutube.com

    22 Apr 2026 · video · 1h 25m · spoken · machine transcript

Show all 5 claims

With AI, work is moving up the layers of abstraction, but the more context someone has about how things work under the hood, the better equipped they are to debug and build resilient things.

Leaky abstractions

  1. Flora Guo Founding design engineer at Paradigm as of March 2026 And I think with AI we're also moving up the layers of abstraction. So we're not writing every function by hand, like no one's doing that. But the more context that you do have about how it works under the hood, so how React works, you know, how our props being passed through, we're much better equipped to actually debug and build things that are resilient. Flora Guo - How to accelerate your design career with AIyoutube.com · 25 Mar 2026 · 24:15 into the videoAll korrents from this video
    And I think with AI we're also moving up the layers of abstraction. So we're not writing every function by hand, like no one's doing that. But the more context that you do have about how it works under the hood, so how React works, you know, how our props being passed through, we're much better equipped to actually debug and build things that are resilient.

    Watch from 24:15 plays here

    ↗Flora Guo - How to accelerate your design career with AIyoutube.com

    25 Mar 2026 · video · 46m · spoken · machine transcript

It always helps to have knowledge one layer below your abstraction, because you get closer to reality.

First principles, Leaky abstractions

  1. Naval Ravikant Co-founder of AngelList You can take this all the way down, but it always helps to have knowledge one layer below because you’re getting closer to reality. A Motorcycle for the Mindnav.al · 19 Feb 2026
    You can take this all the way down, but it always helps to have knowledge one layer below because you’re getting closer to reality.

All abstractions are leaky, so code an AI writes for you will have mistakes.

Leaky abstractions

  1. Naval Ravikant Co-founder of AngelList And all abstractions are leaky. So when you have a computer programming for you—when you have Claude Code or equivalent programming for you—it’s going to make mistakes. A Motorcycle for the Mindnav.al · 19 Feb 2026
    And all abstractions are leaky. So when you have a computer programming for you—when you have Claude Code or equivalent programming for you—it’s going to make mistakes.

Because programming requires forgetting, developers should weigh the costs of their abstractions and who those abstractions leave out.

Leaky abstractions, Trade-offs

  1. Phil Hagelberg Programmer known online as technomancy Programming, of course, is forgetting, but we need to at least try to be aware of the costs of the abstractions we choose and consider who it is that ends up being forgotten. in which the word column has several meanings, none of them architecturaltechnomancy.us · 25 Jul 2022All korrents from this piece
    Programming, of course, is forgetting, but we need to at least try to be aware of the costs of the abstractions we choose and consider who it is that ends up being forgotten.

A viewour reading

A higher level of abstraction moves the difficulty somewhere else; it does not remove it

2 claims filed here, newest first — each in the words of whoever said it.

The difficulty of software engineering is probably essentially constant across abstraction levels, because human cognition adapts to new tools.

Leaky abstractions

  1. François Chollet Creator of the Keras deep-learning library and the ARC-AGI benchmark I think the "difficulty" of software engineering is essentially constant no matter what abstraction level you move to, because human cognition adapts to new tools until it can fully utilize itself. @fchollet on Xx.com · 25 Sept 2026
    I think the "difficulty" of software engineering is essentially constant no matter what abstraction level you move to, because human cognition adapts to new tools until it can fully utilize itself.

Building a system that does the prompting for you is not a break with software history but the next rung on the same ladder of rising abstraction.

  1. Addy Osmani Engineering leader and author who spent 14 years at Google And it's effectively the next step of, you know, every phase of of software evolution is just like a rising tide of abstractions. This is the next abstraction. From Chrome DevTools to AI Engineering, with Addy Osmaniyoutube.com · 19 Aug 2026 · 1:06:42 into the videoAll korrents from this video
    And it's effectively the next step of, you know, every phase of of software evolution is just like a rising tide of abstractions. This is the next abstraction.

    Watch from 1:06:42 plays here

    ↗From Chrome DevTools to AI Engineering, with Addy Osmaniyoutube.com

    19 Aug 2026 · video · 1h 32m · spoken · machine transcript

Read, and under none of the views

On the topic, but saying something the views above do not cover.

Using an AI system to write code is delegating a task to a non-deterministic agent, not using a new layer of abstraction.

Leaky abstractions

On the question and under none of the views: it argues an agent is not an abstraction at all.

  1. Rakhim Davletkaliyev Programmer and teacher; writes on software But we should not lie to ourselves and call it an abstraction in the same way that a programming language is an abstraction. It is a delegation of a task to a non-deterministic agent. AI is not another abstraction because god plays dicerakhim.exotext.com · 8 Sept 2025All korrents from this piece
    But we should not lie to ourselves and call it an abstraction in the same way that a programming language is an abstraction. It is a delegation of a task to a non-deterministic agent.

On this topic, not yet placed

Matched by wording, not yet read into a view. The archive grows on its own, so this is where new claims wait for somebody to read them.

The full chronology, with every quote: simplicity as a timeline · person by person, side by side · all topics · Something wrong? Tell us