This dynamic is part of why I feel like programmers should really just stop resisting the pull to move into management. You might think about programming as the most amazing thing ever, to be agonized over with a fine-toothed comb and the 'best tool for the job' elevated to a nigh-religious consideration, but to your employer, it's one line item on a budget.
It might be 'easier' in a certain sense, and possibly a way to optimize for your paycheck, but 'resisting the pull to move into management' for me is about wanting to do high quality engineering, having a sense of professionalism and pride in my work, and feeling good about what I'm doing at the end of the day, even if my management doesn't understand it fully. If I'm a "line item on a budget", I want to be the best damn line item I can be. I am an engineer.
You can do high-quality engineering in management. You're just doing it with other people's code, as well as your own if you choose to continue programming.
What activities would you expect to be doing in such as scenario? For me, if I was doing it "with other peoples code" rather than "with other people", I would expect to be doing things like large scale architecture, developing tools such as domain specific languages, and investigating new technologies for possible adoption, setting the stage for the rest of the engineering team to write good code and solve hard problems. I would consider this engineering, and "working with other people's code." I would feel some secondary 'ownership' of the rest of the teams code in this scenario.
On the other hand, if I was working "with other people" as in a managers potions, the most technical things I would expect to do would be making hiring decisions, considering the skill sets and training needs of a team, and helping a team make good technical decisions, as well as other less technical manager duties. I see this as a separate management role, that doesn't really involve engineering, and working "with other people" rather than the code they produce. Importantly, I would NOT feel much ownership in their code in this scenario. I would feel ownership in their success coding, but not in the product itself.
You could, possibly, do some of each although I find the two work styles severely interfere with each other, so focusing on one at once is far more effective. If you are an amazing person you might get away with sneaking in some engineering time while being an passable manager as well. If I was in a managerial role, I would focus on that to allow myself to be more effective, and get my engineering satisfaction elsewhere.
Note that some large tech companies recognize this difference, and have explicitly create two distinct promotion tracks, one through management, and one through engineering.
I feel it is a tragedy that many companies feel that "engineering is the thing you do first, they you get promoted out of it into management to continue your career," and structure their org chart with engineers at the bottom.
I think this comes from people who enjoy and are good at management not recognizing that there are people who are not like them, and building a hierarchy that reflects their world view. If more companies realized that there are people who want to be good engineers throughout their career and could relate to them better, more amazing engineering would happen, and it would be well managed too.
