From what I can tell of the quote, it looks to be just the ability of an engineer to successfully code a
new program? Does it touch on any of the other roles of a computer programmer, such as the ability to break a large task into smaller, incremental deliverables, arrange those deliverables in a way that allows parallelism, communicating with the rest of the team to actually make use of this parallelism, and before doing any of this actually verifying that the thing you’re planning to implement is
really what the customer needs? And of course, such work is usually done within an existing system that you have to navigate and modify in a way that remains maintainable (for example, writing the right types of tests, and creating the appropriate types of abstractions). I would be stunned if one’s ability along those axes plateaus within just a couple years of experience.
I guess, I’m just skeptical of this because I recently switched jobs from a place where nobody seemed to know what was happening to one where everything seems to be very well-polished. At
both places, people generally are similar in their ability to write code that does a specific thing, but there’s a night/day difference in how they do these other things. And I’m hesitant to say that it’s because they just fundamentally aren’t good at those things, because that can’t explain how I was also miserable at those other areas but seem to be learning how to do them now that I’m in the right environment. In other words, I feel like my ability to meaningfully contribute to an organization as a computer programmer is increasing with experience, and I can see quite clearly that the people with more seniority at my present job are generally capable of more effectively navigating the problem space than are my coworkers fresh out of college.