I voted yes, but it really depends on WHAT you are writing for code.
If you're writing internal functions nobody else is going to use, the code should be documenting itself -- in that way the same goes for comments. Smart coding reduces the need for comments, smart coding and smart commenting reduces the need for external documentation.
But if you're writing an API or library OTHER developers are going to use, or a tailored system for a client who may end up having other people work with it in the future, DAMNED STRAIGHT YOU DOCUMENT IT!
Goes back to another of those lessons I learned in the 1980's -- if you can't document it, you probably shouldn't have written it.
You write a function or method that other people are going to use, OF COURSE you have to document it. What it gets passed for parameters, what it can return for values... that's just common sense. EVEN if the function name and variables presented in the code are verbose, if it's a library, framework, or API it's not like everyone who is going to use it is going to dive headlong into the codebase to find each and every function they can use!
That said, you document CALLS, parameters, and what's returned... you don't go ape-shit documenting what each and every line of code does anymore than you would waste time commenting each and every blasted line.
Hence why every time I see derpitude like this:
return $result; // and now we're done
I have to choke back the urge to deliver a pimp-slap.