If they mostly are telling other people what to do to make the other people write better code, then yeah, they can be productive to the work of the company. In a good job, I will save more time by tweaking other peoples plans than any direct execution I do. There is a reason the best management is management by walking around, talking to people, finding it what is actually going on.
That’s a manager then, not a software engineer/developer role if your whole job is directing others and not doing any coding yourself, and I’d posit that if you are doing that for too long, you probably shouldn’t be tweaking anyone else’s code eventually since you will lose touch with the system if you aren’t coding and your advice shouldn’t be at the program level anymore.
Not if your job is only to make people better programmers, not responsible for product deliveries but responsible to code quality, code brevity, long term maintainability, that sort of thing. If you keep pairing with people and pointing out better ways of doing things, ways of doing things that they might have considered impossible but have some hackish solution of a category they haven’t used before, or of building things towards your desired long term plans but not specifically asked for by product/customers, the job is only code and coding, but also enculturation of a group into a common vision that can make for very high performing groups of developers.
I have never seen a job like that where someone doesn’t code a bunch themselves and they are still a useful member of the team in the long term. I’ve hired a lot of engineers of various seniorities and also never hired anyone in the role you described and don’t see why I would. I expect the principle engineers or senior engineers to provide guidance but also to code.
