For me personally is the debugger only helpful when dealing with badly documented foreign code, to figure out WHERE and HOW things happen, not necessarily what goes WRONG.

I.e. tests and logging are missing, and I can't figure out the flow by looking at the code.

(I also use the Perl-debugger as kind-of REPL to test code snippets, but that's not debugging)

To my chagrin are most of my colleagues trained from early on to develop with the debugger, because our tool of choice - Komodo - makes it very easy to set a breakpoint at the fringe of the actual code and step thru and see watch expressions.

Furthermore is F5 set to run inside the debugger, it's F6 for an independent run.

It's so interwoven, that they don't even know how to use perl -d and its commands. The keep talking about "Komodo's debugger", literally as if Active-State hacked an independent solution.

This, plus continuous automatic perl -c in the background with underlining of compilation errors (mostly forgotten my declarations) leads to a kind of "try and error" programming mentality.

Before I started for that client, newbies were told to copy-paste a "working" script and adapt it to their needs, Komodo would just help them underlining problems and help "debugging".

It's quite hard to convince them that the proactive use of test-suites and logging leads to better results.

It's basically a question of return of investment...