Respect for others is a basic character trait that good programmers have. Your default position should be "what can I learn from this person?", however old they are, and not are they qualified to do my job, but are they qualified to do their job.
The technology may have changed but many of the problems surrounding it hasn't. Requirements are still flexible, estimates are still hard, and the real world still doesn't map to computers that well.
On a technical level data from external sources is still not to be trusted (in any sense), the bug still isn't in the compiler and that new technology still isn't going solve all your problems.
Speaking as a manager the toughest things are understanding what you don't know (or did know that's no longer right) and letting go. At most you're going to spend 5 or 10 hours a week hands on. That's never going to be enough to keep pace with the guy spending 40 hours plus a week coding, however big your head start.
You need to deal with that, move on and let the kids get on with what they're good at. Challenge them about what they're doing from time to time politely, just to make sure they're not bullshitting you (and hey, you might learn something) but you need to trust them.
As a young programmer, the thing to understand is that looking at it from the perspective of the specifics of the technology is wrong. The specifics simply aren't that important for two reasons.
First, over the next 20 years you're going to come into contact with new stuff and you're going to find that each extra thing is easier to learn than the last thing. And as that happens, you're going to see that what you did before, even though it's different, is still helping you. You can probably see it already, just in a couple of years, just from your first couple of languages or technologies.
And most of that's never going to change - those concepts, those foundations, that basic understanding. And that's what your manager - assuming he has been there and done that - has and why even though he has no idea what a singleton or a factory is, why he still has something useful to add.
Second, most of the problems aren't in the technology, they're outside it. You shouldn't be looking for your manager to solve technical problems for you (after all if he could why would he need you?). You should be looking at how he makes it easier for you to solve them.
It's easy to just look at the trouble he dumps on your desk, but sometimes you need to think about how much trouble has never made it into the same room as you because he squashed it at the door, and understand that it's not about how we solve the problems, it's about working out which problems we actually solve.