While some people really don't get it I'm pretty sure that most people could learn how to program with some competence.
The only metric I've found to measure programmer competence reliably is how big a project you can manage to complete. Some people get stuck at around 100 lines, others in the thousands or tens of thousands, some can keep their rudder straight across 100's of thousands of lines.
The latter takes extreme self discipline and organization.
Gzip-bytes of source FTW.
Implicit in the notion of completing a project is the certainty that the project manager will change their mind, usually after you have written 95% of it. If you copied & pasted those hundred thousand lines, you will have to change something in at least 100 different places. At that point, you'll give up in despair, proclaim the change impossible, and have the PM cancel the project in a fit of frustration. Thus, not complete.
LOC actually sorta makes sense in this context.
Clever trick to measure the real information content of code using gzip too.
But beyond the practical, what you're really measuring is the ability to break down a large problem, solve individual pieces, reason about how those interact, and iterate. That is the critical intellectual muscle that makes programmers reliably great.
I remember a few projects I abandoned when their size outgrew my ability to comprehend them. It took multiple attempts with new methods to break through certain complexity barriers. I could not write a program longer than about 500 lines until I had learned the practical use of subroutines and data structures. I could not write a program longer than a few thousand lines without a sense of taste when it came to objects and modules. And I could not write a program of significant size until I reliably turned out code that could be comprehended at a glance after months or weeks away, as my own throughput guaranteed it might be that long between visits to disparate parts of the codebase.
This went on for weeks, maybe even months.
Then a friend told me the magic words: "structured programming". I went to the library and read a book (I forgot the title, I think it was by Wirth).
Within 3 days I had it up and running.
That is what logic tells you, but I've seen smarter people than me, which couldn't get it even after years of trying. (I helped a few with labs while studying.)
You shouldn't have too much grit.
You characterization about handling program size fits well with my own development. Interesting point.
Overheard statement "You know when I was in college I learned C. I just can't get the hang of these objects, so I try to avoid them". The guy who said this is now 34, and has programmed python for 4 years.
A guy who would copy and paste 100 line blocks of code, and then occasionally thing "oh yeah, i need functions", and then finish out the current function by passing 12 parameters of state to current_function_2(). If you combined the func, func_2 and factored out the 100 line blocks it would be reverted with a commit: "stop making this so complicated".
There was one guy who insisted that using templates was only for web frameworks, to use them to write system/config files (done frequently due to 3rd party daemon limitations) was an abuse of the templating system, and we should just use inline prints. The program was to be called with prog > /etc/conffile.
One guy who decided that threads were so tricky, that he was the arbiter of thier use. My idea of a job queue and worker threads was "too abstract and hard to debug", so we stuck with the "tried and true" one thread per job method, all spawned at once.
I could go on, but you're all prolly bored now :)
tl;dr: i worked with the guys the article was written about