I would disagree that general programming knowledge doesn't change. While most of the ideas currently on the forefront of software engineering were invented decades ago, many of them have only hit mainstream very recently. While pure functional programming isn't used very often on large projects, current best practices prefer a declarative functional style whenever possible.
While a "for" loop may not have changed, someone who has only coded C++ may not understand why it's often the wrong way to iterate over a collection in modern environments. They might not understand why you'd use function parameters instead of inheritance, or lots of tiny single-method classes instead of one class that handles every aspect of a data type.
While these may seem like simple implementation details, they can lead to different approaches to problem solving, and conflicts over programming style that you might need to mediate. For example, if one of your group's goals is test coverage, then it would be helpful to have done some TDD, and know what characteristics are more or less conducive to testing.
While none of these ideas is brand new, there are a lot of teams that have only recently started embracing them, and a manager who hasn't kept up is probably not going to be a very good fit on a team that has.
Especially this. Even worse: they might hear that functional programming is the new trendy thing, and for loops are passe. That you should always bury your control flow in a lot of small callback functions without the appropriate amounts of equational reasoning that must go with it, killing your ability to really debug your programmer. Or they might hear about TDD, and apply it in a very wrong way because they really don't get development very well. Actually, the only thing worse than a non-coding manager is a manager who tries to "keep up" without really being in the game.
A good dev manager is able to see the good over the fad.
While a "for" loop may not have changed, someone who has only coded C++ may not understand why it's often the wrong way to iterate over a collection in modern environments. They might not understand why you'd use function parameters instead of inheritance, or lots of tiny single-method classes instead of one class that handles every aspect of a data type.
While these may seem like simple implementation details, they can lead to different approaches to problem solving, and conflicts over programming style that you might need to mediate. For example, if one of your group's goals is test coverage, then it would be helpful to have done some TDD, and know what characteristics are more or less conducive to testing.
While none of these ideas is brand new, there are a lot of teams that have only recently started embracing them, and a manager who hasn't kept up is probably not going to be a very good fit on a team that has.