As a software engineer of 20 years standing, mostly working on safety-related stuff (SF-PD), I'd have to say that your boss may not the person you want to be your example. Lack of comments is a sign of either a self-taught amateur coder who's never learnt how to do the job properly, or an inexperienced engineer. Or perhaps an engineer who simply doesn't have the time - deadlines and expediency can do horrible things to your code! ;) It's definitely an anti-pattern for every competent software engineer though.
Your boss might be a very good coder, but it sounds like he's not a good software engineer. An engineer uses collective group experience to avoid the pitfalls that other people have already been caught out by. Effective commenting is part of that collective group experience for software, in the same way as stress analysis is part of the collective group experience for mechanical engineering. What counts as effective commenting is more fluid though, and it's definitely something you get from experience.
The most basic thing is that comments should not say what a line of code does. There are times when comments to say what a function does are superfluous too (especially in C#). Over-commenting can be just as ineffective (and a pointer to lack of experience) because you can't find the important stuff in the dross. As a novice, you may still be working on figuring out the "what" of the code, and for that you just need to read and understand what he's done.
The important thing for comments though is that they say WHY a line of code or a function does what it does, where this might not be obvious. Do you need to set up module X before module Y? Is it important to check a return code to see whether a file was already open, or are we consciously ignoring the return code because this has been checked somewhere else? The "why" of the code will be relevant to everyone, regardless of experience - and it'll be relevant to him as well in 6 months time, when he's forgotten about the good reason for doing something a particular way. Commenting isn't just for other people, it's for helping you in the future as well.
If you want to avoid annoying your boss, ask smart questions. Focus on asking about the "why", and try to work out the "what" yourself (unless it genuinely is obscure). No good boss will mind being asked questions if they aren't the kind of things that you could have found from R-ing TFM. And no good engineer will mind being asked to do something that'll make another engineer's life significantly easier, at little cost to them. (Just don't ask him to backfill comments on the entire codebase! ;)