In project after project I was noticing that I didn't have much time for commenting the code. So what I decided to do was "make it count for something." I kept my comments to a minimum. I'd talk about what the purpose of the module was, or if I created a class framework, generally describe what its purpose was. I'd put a comment where I thought what I decided not to do was important. I might say, "This is the reason I'm doing this, in case you're wondering." Lastly, if I did something that was highly unusual from the run-of-the-mill code for the type of application I was creating, I would write a comment about it, sometimes very large, explaining "the method behind my madness."

Other than that, if there was a piece of code that was complex, I'd put brief comments about where the end of a function was (so that if you're at the bottom of the function, you can see where you are instead of having to scroll up to see the function signature), where the end of "if's" and loops where (for long, embedded code). Of course, in hindsight, one could say if your code is overly complex like this, that's a signal to refactor and simplify it. True enough, but that's if you have time for that sort of thing. It's my understanding that employers tend to not see the value in refactoring still.

The only way in which I think my commenting strategy could've been improved would've been in the main module to talk about, "This is the purpose of this whole thing," and talk about the features and why they're there. I wrote up some documentation like that once (outside the code), and it was a realization to understand, "Oh, yeah. Someone new who's never worked at this company before would benefit from understanding what this thing is, and why it does what it does." I regret I didn't do more of that.

So, rather than explaining the code, my general strategy was I assumed some things about the reader. I tried to target my comments to things I thought a programmer who understood the gist of what the product was about might be confused by.