Hacker News Reader

Once you've seen enough code, the right abstraction becomes easier to spot.

Applications are more similar than they are different. That's why we have the concept of design patterns since these occur with enough frequency that we should just give the abstraction a name instead of re-inventing it each time.

Problem today -- my observation -- is that many younger devs don't ever bother learning design patterns so we end up with 1) devs who aren't aware of common, existing patterns codified decades ago and then 2) think that the "wrong abstraction" is expensive partially because of a lack of knowledge of the "right abstraction" to use.

True enough. But in some companies, there's so much push that the wrong abstraction gets left in place as refactoring and rewriting get pushed down the priority stack and never happens. The way to circumvent this is to not declare the task done while it's still the wrong abstraction, but there's still a (present) schedule cost compared to just duplicating the code and tweaking it.

Right up until somebody else uses your wrong abstraction- and now it's part of the bedrock.