He basically splits the complexity of programming into two categories: accidental complexity and essential complexity. The accidental complexity you can fix, it’s the difficulty caused by tooling, programming languages, etc. The essential complexity, that is: the complexity caused by the problem your program is trying to solve, cannot be fixed. To quote the man:
The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract, in that the conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed. I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.
I don’t think it is - and I’m not saying that because I think I’m good, it’s because programming is just a different way of thinking
This different way of thinking is something that some people simply will never get, or not at the right level. I’m certainly not a great programmer but I know from experience I’m above average. I know a lot of programmers that simply cannot grasp things above a certain level of abstraction. These are college-educated programmers with years of experience. The easiest way to tell is that bad programmers turn simple problems into complicated code, and good programmers turn complicated problems into simple code.