This argument is old and tired. Programming languages are rarely sufficiently expressive as to document the nuances, guarantees, and expectations of a particular block of code in the code itself. Type systems can help here, but they alone are not sufficient. An often stated rebuttal to the above is that the developer can comment the "complicated bits", and save time by skipping it the rest of the time. This is a flaw…
Additionally, commenting every bit of the code, especially as you go along, leaves one prone to forgetting the most important reason to comment: explaining the rationale for what you're doing. Explaining the design decisions in comments (and especially why you didn't do the alternative) is invaluable, and much more accessible to a maintainer (such as oneself a few months later) than an external design document.