But this problem with docs and code getting out of sync is a real one, and my personal experience (because I can be in-the-bad-way lazy) is
that the docs suffer if I don't do inline POD.

You are definitively right here.
My personal (bad?) solution to this problem
is to write documentation for the user aspect of
a module only - and for this I find the "doc writing
code sweep" approach quite OK, since the user interface
should not change often anyway.

For the rest, I use comments. All in all, I mostly try
to write "self-documenting code". But alas, I am not
the one to ascertain if I succeed in this.

The worst problem with all this, IMHO, is that there
is really no other way to document the interface to your
function in the code than by clever paramater naming.
And even that is in vain for return parameters. And that
in a language that can have an arbitrary number of them,
and without types. This is a really weak point in
Perl (no way to express function signatures with
return types in the code).

What I found in practical work is: you really need to read
the code you call. If something does not work as expected,
and you are sure your code is not the problem,
go and read the code you call (with a nice debugger this
is much easier than one thinks).

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other