Aren't ability to abstract and experience sort of similar? I don't really consider the ability to write a generic function (instead of copy-paste) to be the same as the ability to abstract. To write a good abstraction you need to understand both the underlying system and the consumption pattern to avoid abstraction leaks, boilerplate, hiding of useful features, etc. You can't really be sure that you're writing a good abstraction without at least having some idea of what are alternative approaches and what are their strengths and weaknesses.
> Aren't ability to abstract and experience sort of similar?
No. They are distinguishable from each other. One may feed the other, but they are separate.
> I don't really consider the ability to write a generic function (instead of copy-paste) to be the same as the ability to abstract. To write a good abstraction you need to understand both the underlying system and the consumption pattern to avoid abstraction leaks, boilerplate, hiding of useful features, etc.
You are confusing abstraction with data and function hiding. In the article abstraction means the ability to meta program, translate one problem into a simpler generic problem, etc. This is a skill most of the industry lacks _in practice_. It is a skill that all 1% coders have, but it also doesn't make experience go out the window.
Experience is abstraction. You take what you've been doing for the last N years, and you develop a simplified understanding of that over many examples.
Heck, machine learning is basically abstraction as well, and it is something that arises naturally with intelligence. Good programmers must be especially good at it, but so do many other professions as well (even say doctors).
I don't feel that they're orthogonal - while one doesn't necessarily imply the other, they certainly seem correlated.
At least if I'm thinking for myself, my ability to abstract seems to have steadily increased over the years; PeterisP-10-years-ago was much worse at this and the changes were mostly driven by experience, seeing how all kinds of different systems are built, which kinds of abstraction tend to work out in practice and which seem nice at first but turn out to be horrible after a few years.
Then it serves as example of what not to do. That helps a lot too, mostly because your own abstraction is always super clear the moment you figured it out and understand it. It is when you are forced to read it after few years or when someone else invented it you realize how complicated and difficult it in reality is.
It seems we are talking about entirely different types of abstraction. Most code contains no abstractions (not talking about language abstractions which are something else entirely and can be incredibly deleterious to maintenance of the system).
