Well I'm no dedicated software developer, but I sure as hell am gonna disagree with you on that one XD
maybe that's why you're not a dedicated software dev
Good code should absolutely still be commented. If there's one thing i've learned over the years, it's that what seems obvious today will most definitely not be obvious 3 years (or even 1 year) down the track. I open up old programs, sometimes in languages I haven't touched in a while, and it's like
I tend to modularize my approach so I can chop/change things if needed without tons of reworking. And on top of each section, I comment briefly what I'm doing with that section in a general sense. If it's part of a large/complicated program, I'll also include what it's doing/enabling in the big picture.
Honestly all depends on how you architect your program and how you name your methods/functions & variables. If you name your methods/functions and variables clearly enough, they self-document what the code is doing and you don't need to read through unnecessary comments about what exactly the code is doing if you're clear in the first place.
You're talking more about overall documentation, which is fine to do (documenting your methods/functions in regards to what it does, the parameters, and what it returns). I'm talking more about in-line documentation, which should be kept to a minimum if possible (reduces the amount of reading necessary later on down the road when looking through a program).
example:
Code:
<summary>Sums two numbers together.</summary>
<param name="a">First value</param>
<param name="b">Second value</param>
<returns>Sum of two values</returns>
public int Sum(int a, int b)
{
//sum a and b
var c = a + b;
return c;
}
The XML Summary doc is fine, as that describes what the method is doing, and in the case of Intellisense for VS, will also describe what the method does while you're typing it out and give all the necessary info & meta data that was given in the XML.
The inline "sum a and b" however, is unnecessary (and yet I've seen inline documentation like that). It's clear already what's happening, and thus only clutters up the source and makes it harder to read the actual code.
I know that's a pretty basic example, but it's scalable to larger applications as well - if you break it out well enough into smaller methods that are single-purpose (and reusable!), then the code documents itself.
I didn't agree with Clean Code practices at first, and in the beginning I did indeed add inline comments. But as I gained more experience I saw the benefits of Clean Code and saw exactly how useless those inline comments really were when I architected my application in a proper way.
Basically...if you're adding so much logic in a single function that you require inline comments...you should probably start breaking it up into multiple functions.