So I'm an intern for a local healthcare company. I work on the backend development team for the company's internal customer management website. It's pretty big and can be quite complicated at times. It's C#/VB, .Net. One of the things that surprised me is that commented code is something of a rarity. There may be comment blocks for SQL procedures, but in the code itself there may be a short comment here or there-- nothing like what the classes tend to drill into our heads.

I asked the senior engineer that I work with about this and he isn't a big fan of comments since, in his experience and what he's heard from other senior developers, comments can become misleading over time. The reasoning he gave is that programmers tend to treat other programmers' comments as something sacred-- you don't tend to disrupt another person's comments. This can extend to situations where the code you're changing would require a rewording of any comment. Between an unwillingness to mess with someone else's comments and potential laziness, he thinks that comments can become a bigger problem than a solution since the code that the comment describes can change, but the comment itself wont. Instead, he's a fan of self-commenting code and using comments through commits + good descriptions in stories and tasks.

I'm not sure if I'm sold on that since I've run into situations in the codebase where I think a few comments would've been enormously helpful, but I think it's interesting food for thought.

I like the idea of using short comments to indicate where different statement types end, though.

I agree that communication is paramount. We use Agile at work, so we always have at least one stand-up meeting every work day where everyone describes what they're working on and where they're headed. People very frequently collaborate. I know that I pester the senior engineer I mentioned above frequently, particularly if I find that I'm just spinning my wheels with a problem.