Once you stop programming, your skills will degrade like a musician who stops practicing, you'll eventually forget what its like to be a programmer like a parent forgets what its like to be a teenager. You'll lose your ability to connect with programmers, but hopefully by that time you are managing managers who manage programmers, or something like that.
Google can't fill these information gaps, and any manager who trusts Google over their engineers is probably a toxic one at that.
A musician will have his skill decline, but his appreciation and understanding of music probably wont. I think this is the key point. Yes, after 10 years, the manager won't be as able to code something in the project (nor should he) but he won't just magically forget what O notation or graph theory is all about.
I think a better analogy maybe coaching. Some coaches were players before coaching, while others weren't, but their understanding of the sport isn't linked to them actually playing the sport.
A coach would observe their players play everyday, and review their performance quite directly. Their bodies are not able to do it anymore, but they are "still in the game" so to speak. A bad development manager is often never looking at their programmers' code (or if they do, they might not understand it), only seeing and evaluating indirect results of their work. Even a good dev manager is not looking at their programmers' code very much, but at least they understand what is going on and are able to themselves in their programmers' shoes.
Organizational "visibility" is why it is so important for programmers to attend and speak up at meetings; the organization is incapable of valuing what they do directly. Also, "managing up" is the secret to getting things done with a non-coding boss.
But that is exactly the point I'm trying to make. A coach won't be able to do a dribble (soccer) or sprint for the header goal, the same way a manager shouldn't be writing the unit tests or OAuth login, but both are involved in their fields and don't magically forget the rules of the sport or what OOP is.
I'm not advocating that bad managers should learn through google, but if you were a good developer and didn't program for 10 years, if the time came to decide between TDD or BDD for the project (though that should be a Team Lead or CTO job, not a PM) he should be able to brush up quickly. Maybe not decide if you should use Shoulda or xUnit or whatever, but have a general picture of what the developers they are managing are talking about.
What do binary decision diagrams (BDDs) have to do with TDD (test driven development)?
If this manager hasn't been doing development for 10 years, he is a lot cause. But this doesn't have much to do with programming, just being involved in building software. But in cases where their experience isn't fresh enough, they will have a tendency to either be static (we will write our web project in COBOL, because that is what I used to use dammit) or be very trendy to a fault (I heard post modern node-oriented programming was hot, let's use that for our compiler).
Just like parents do not forget teenage years rather the experience of being a teenager is much different, so programming evolves and changes. But your point is still true, while non-programmers can appreciate the result, it is a job for professionals at thge top of their game.
Google can't fill these information gaps, and any manager who trusts Google over their engineers is probably a toxic one at that.