What would your programming language look like if the Pointy-Haired Boss had to be able to understand it?
Lots of comments, very little actual code.
When I was in school, we had to have over 50% comments or the TA wouldn't even try to grade your program. The habit was a good one, and although I don't always get to the 50% I still put a lot of comments in my code.
That's a very bad habit, and one that you should break. Comments are evil. They are occasionally -- very occasionally -- a necessary evil, but still evil. I'll explain below.
Come to think of it, making your code understandable by the PHB is not a bad goal. If the PHB can understand what you are doing, the next poor programmer (which might be you a few months after you have forgotten the project) will have an easier job fixing something.
Absolutely, you want your code to be extremely easy to understand. In fact, that's the #1 goal, even ahead of doing the correct thing, because bugs are more likely to get fixed than unreadability, and in the long run they cost less. Comments are one way of achieving readability, but they're a crutch. Worse, they're a crutch with a built-in time bomb.
The problem with comments is that they're wrong, and they mislead the next poor programmer.
They're usually approximately correct (though rarely exactly correct) when written, but they tend inevitably towards inaccuracy as time goes on, because the code will eventually get changed, while the comments may or may not get updated to stay current. If maintainers assiduously update the relevant comments every time they change the code, then the comments stay (approximately) correct, but at the expense of requiring that additional effort by the maintainers. If someone doesn't bother to update the comments, it gets bad.
On the other hand, code that is readable without comments doesn't increase the maintenance burden and has the fantastically valuable characteristic of always being correct. Comments can be wrong about what the code does, but the code is never wrong. It may not do what is desired, but what it says is what it does (barring compiler and hardware bugs, but that's a separate problem).
I should clarify here that I'm talking about comments intended for maintainers. I have no issue with Doxygen/Javadoc/etc. comments that are used to generate documentation. They're just as error-prone, but they provide enough additional value -- in the form of the generated documentation -- that they're worth the risk and the cost. They're written, not for future readers of the code, but for future programmers who may be able to avoid reading the code.
Comments that are written for future readers of the code, however, are a code smell. They're not absolutely bad, but any time I see a comment embedded in code, it's an indicator that there's a good chance the author should have put some more time in, finding ways to make the code readable without the comment. Actually, I tend to write lots and lots of comments in my code while I'm building it, outlining the functionality I'm going to write before I write it, explaining why it's there and what it's goal is. But as I implement it, I read each section of code to decide if it's sufficiently clear that I can remove the comment. If not, I refactor until it is. In very rare cases I find that there is simply no way to make it clear without a comment, generally because there are very subtle constraints on the code which cannot be expressed in the code. Those cases are rare.
Often it's just a matter of taking a block of code with an explanatory comment at the top and factoring it out into a subroutine, with a well-chosen name that expresses what the comment used to say. If you find there's no such name that isn't a dozen words long, you need to go farther and restructure. In many cases you can eliminate comments just by adding some variables in which to place intermediate results of a calculation -- variables with well-chosen names that express what the business meaning of that intermediate result is, generally including its units, except where they're obvious (which is less often than you might think). Function/method names, variable names, class names, etc. are how you can make the meaning and purpose of your code clear without requiring comments.
I strongly encourage you to give this a try. Begin looking at the comments in your code as a bad thing, and look for ways to refactor the code so that it's just as clear (or clearer!) without the comments as it was with them. It made my code better (I used to be a heavy commenter), and I guarantee it'll improve yours as well.