Dan Abramov The wet codebase

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] ▶ this video

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] ▶ this video

In my career as a software dev I've found one thing to be true - Every Paradigm I ingest that opens new windows of opportunity are great at first pass and as I learn more the more narrow the scope they can be applied. (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 : ▶ 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.

I like Dan Abramov's "The Wet Codebase" ( ▶ 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.

I agree with the general sentiment of your comment and I think there are several factors at play here. * The human brain is not capable of evaluating and re-evaluating every possible option amongst the plethora of technical choices developers are faced with. This forces us to develop certain coarse grained mental heuristics (prejudices and biases) to navigate technology, and even if these broad generalizations are roughly true initially, we tend not to re-evaluate them over time. This leads to stale biases (e.g. some library/language was missing an API 10 years ago, and someone formed an immutable opinion on it). * These broad generalizations lack nuance. I watched a talk recently by Dan Abramov where he calls these heuristics (I'm paraphrasing) a form of information compression [1]. That compression is lossy — it doesn't preserve the original context in which the heuristic was formed. * There's also some insecurity at play here too. Developers want to believe that they've chosen The One True Solution, and harshly invalidating the alternatives is one way to reenforce that fantasy. * And of course, 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] ▶ this video