and it doesn't contradict the article. If you have always worked in one paradigm and think you are an expert in it, learning new development skills can make you see you were not that good in your previous area.
I consider the most reliable evaluation of expertise is working code. Something can be beautiful, but if it doesn't work, or doesn't solve the business problem, it doesn't count. If something objectively scales, I believe that the people responsible for building it are able to build that thing that scales.
If those people learn new things, they might learn how to do the job better. But maybe better isn't what the business needed. Maybe it would be better to invest that extra talent in something else, and hire people with the original skill level (who may be cheaper) to do the original thing.
This all might sound like an apologia for not learning new things, or limited developers who can only build a few things. In some ways, indirectly, I'm arguing against an unfounded arrogance or feeling of superiority which is driven by following the fashions of programming as a pop culture. But more of what I'm trying to get at is that the "best" isn't actually required, a lot of the time. And sometimes the best can be the enemy of the good; doing things the "right" way, according to an orthodoxy, can actually interfere with getting things done. And newcomers to orthodoxies can be - usually are - the most religious.
I've seen LOTS of beautiful code that doesn't work... in the real world, usually because it doesn't check the assumptions it makes. Is the data what is expected? Do the code's parameters span the space they should? Does the code inform the user of errors usefully and gracefully? Is it well documented, intuitive?
In my experience, when it comes to code, beauty and durability are natural enemies.
and it doesn't contradict the article. If you have always worked in one paradigm and think you are an expert in it, learning new development skills can make you see you were not that good in your previous area.