Skip to content
Hallway
0:00 / 0:00

#danabramov#dry#wetcodebase

Dan Abramov The wet codebase

eswarnichtsmehrfrei

878 subscribers • 1 video on Hallway

YouTube
  • Recommended by 3 people: 3 on Hacker News.
  • Presented by Dan Abramov
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

26K views5 years ago3 recommendations

Software designTools and practiceRefactoring and legacy codeDesign patterns

Dan Abramov uses visual aids to demonstrate how premature abstraction and over-adherence to DRY principles can lead to complex, hard-to-unwind codebases.

The uploader added no description.

Why it's here

3 people recommend this

What people say. Highly recommended for its clear visual explanation of why premature abstraction is worse than code duplication.

Moments people linked to

halfcaton Hacker News • Recommends

On “Don't DRY Your Code Prematurely”

The visualizations in Dan Abramov’s talk “The wet codebase” 1 really burned this concept in for me. Seeing what a premature, wrong abstraction looks like visually was eye opening. 1 link to this video
View on Hacker News

shadowfoxxon Hacker News • Recommends

On “I don’t buy “duplication is cheaper than the wrong abstraction” (2021)”

…(This is kinda true in life, too. Like when people say, "Its econ 101 or bio 101." etc. What seems like a statement about 'common' knowledge is actually an indication of how shallow your knowledge is!) Specifically related to this topic is a talk by Dan Abramov called, "The Wet Codebase" - He says it better than I can sum up and has visual aids : link to this video Other have pointed out code that is similar in function vs similar by coincidence and I think that thought alone is worth chewing on.…
View on Hacker News

gosukiwion Hacker News • Recommends

On “I don’t buy “duplication is cheaper than the wrong abstraction” (2021)”

I like Dan Abramov's "The Wet Codebase" ( link to this video ) -- I've been guilty of doing just what he says in his talk at first, removing all duplications and making the codebase DRY. But then I came to like "prefer duplication over the wrong abstraction", as Sandi Metz puts it. Sometimes it's good to wait to have more data to make an easier and more informed decision.
View on Hacker News

halfcaton Hacker News • Recommends

On “Algorithms we develop software by”

Dan Abramov talks about WET (write everything twice) 1 as generally a good approach, primarily because you often don’t know the right abstraction up front, and a wrong abstraction is way worse than a copy/paste. He has some good visuals that illustrate how incorrectly dependent and impossible to unwind wrong abstractions can become. 1 link to this video
View on Hacker News

throwitaway1123on Hacker News • Mentions

On “OOP is not that bad”

…social media has exacerbated this problem by rewarding inflammatory hot takes. You won't get nearly as many views/upvotes/likes for a sober take that says "technology X is well suited for this narrow use case" as you will for a hot take that says "why technology X failed", or "why everyone hates technology X". You might enjoy this link: link 1 link to this video…
View on Hacker News

u/Rhythmic88in r/typescript • Mentions

On “Narrowing down a subclass type without using "instanceof of Subclass" directly.”

Cool, glad it helped. I'm curious to hear more about why you want the additional abstractions? Like `createApiError` to me seems kind of overly abstract maybe to be excessively dry ?. Why not just import the specific error create functions that one util function needs and then define different unions of errors for specific utils or purposes? I'm sure my way can be improved, I don't feel super confident on this topic. My endpoints each have their own union of errors that they might respond with rather than a union of all possible errors in my api because when I discriminate I want to only see the errors codes that are actually used for that endpoint so no one thinks they need conditions…
2View on Reddit

u/Rhythmic88in r/typescript • Mentions

On “Narrowing down a subclass type without using "instanceof of Subclass" directly.”

Cool. Yeah I’ve done similar things just needing to see it work and prove I can do something. Even if it’s not what I end up using it increased your skills so you can do something advanced later more easily. I’ve fallen into the trap multiple times though of trying to make something too abstract for convenience. ‘Once I finish this I can use it for so many things which will make things easier and save time. ’ then down the road it grows in complexity and/or I start feeling like it was overly abstract and confusing, trying to do too much in one place and I refactor to back to something simpler. This video helped me ease up on that a bit link to this video
2View on Reddit