I'm going to push back on your push back. There are situations where comments are necessary e.g. commenting on the intent of the code, warning of consequences or clarifying the purpose of the code (I would refer to Bob Martin's Clean Code for examples on these). However when writing production code on your own projects / other projects you should get into the practice of writing code that can be understood without comments. This is for a number of reasons: Comments are just another piece of code that needs to be maintained. I've seen many situations where the code and comments didn't match because the developer changed something and forgot to update the comments. It promotes lazy variable / function naming: instead of writing down what the functionality does in a comment, you should try to think about how to write the code in a way where the comment isn't needed. It adds a lot of noise. When I'm reviewing or working on code, I don't want to be looking at comments. I want to be looking at code. "Trying to figure out a complex bit of uncommented code takes much more time." You have picked up on one of the key elements of clean code - managing complexity. If you're looking at some code, and you don't understand what's going on it usually means that the code isn't written cleanly and the correct abstractions haven't been used. Writing legible code is difficult but it's an incredibly important part of software engineering. I would recommend reading Bob Martins Clean Code and also a philosophy of software design by John Ousterhout.