Ouch....you and Mr. Martin are a pair harsh mistresses. Teachers be teachin' though!
Have you really worked in code bases so clean they don't need comments?
That's unicorn blood level stuff right there...
Not a programmer by trade, but have been in enough code reviews, scrums, and midnight hair on fire deadlines to appreciate good comments and clean debug output.
No, never, in fact I work literally as a software archeologist doing legacy code refactor and re-engineering, finding out what people tried to do 20 or 30 years ago and migrating code to C# so my job, in a way, is to convert those dump sites into parks. Mind you, our current system got about 5m lines of code so it's bordeline small/medium.
Comments don't compile so they are never up to date. Even function/method headers aren't updated, people just copy/paste them and you end up with the same explanation in several methods in the same class, or with new parameters that aren't even mentioned in the documentation. Not even talking about class diagrams, UML and other information, programmers hate them with a passion and will try everything to just fill the absolute minimum possible information. I have seen empty diagrams because "we remember the name of the classes" and "anyone wanting to join us will have to memorize it anyways".
In this case, why cryptically name the method
sw5_cutscene4 and add a comment about what it does instead of just calling it
carl_banging_whore_scene? If you see that identifier somewhere else you would know immediately what the method does instead of having to wait for a tooltip in the IDE to tell you what it does. You shouldn't assume you would always have an IDE with that capability available, sometimes you just need to ssh to a server and use
vi to modify something on the go where there are no tooltips, you just load one file so you don't even have the whole context. The only times comments are useful is when they mention why a certain approach has been chosen instead of a different one.
It's not hard to write "good" or "clean" code, it's just that many programmers don't know how to so they just copy/paste stuff instead of thinking before acting. The best documentation for developers is the living one, having a set of unit testing, if possible using TDD to write tests before starting writing the modifications. It's such a pleasure being able to write code and know immediately if you have just broken something else you didn't even know was linked to what you are writing I'm sorry for anyone who has never experienced that feeling. And yes, I've spent many nights preparing a release and having to cancel it at 5AM because we were just too tired to continue and just had to postpone them, or having to wake up at that time because of an upgrade gone wrong that had to be fixed before the client started using the system in a few hours. And because I hate them (plus I'm getting older to sustain them) it's that I try my best at coding.