[Olreich]

Abstraction is not a panacea. It's often the root cause of significant technical debt. Abstracting as late as possible is often the best course of action, as it give you more information about how to abstract from the initial implementation.

[kodah]

Most people think it's the people that are special or underperforming, but my view is probably a bit more contrarian. I think that some environments work in such a way that only a few can succeed while others make success possible in a network effect or on more manageable scale. I don't think that environments that produce the former really mean to; rather I think it's the leaders that are unable to craft incentive systems, pool resources, or effectively communicate that end up creating these kinds of ecosystems. It's really a fundamental misunderstanding of the people part of the job, which turns out to usually be the hardest.

[mirekrusin]

I disagree. You should work on bottom up abstractions, base yourself on first principles. Amending abstractions built like this are cheap and straight forward. This is opposed to top-down, gluing already made monstrosities.

[29athrowaway]

Yes, that's why it takes effort to learn how to properly create abstractions that solve more problems than they cause.

[pksebben]

I would add to this; that a certain amount of bad abstractions are preferable to underdoing it. The learning from failure (when there's sufficient investment in the outcome) is far more valuable than avoiding inefficiency.

Learning better ways is a process - so long as you remain robust in the face of failure and grow from it.

[janstice]

Improper abstraction does usually lead to significant technical debt, but if you are lucky you can bank your short-term successes and leave the tech debt to someone else.