I would add one very useful hint which was not mentioned in Paul's videos:
place the word "debugger" (without quotes) anywhere in your script to set a breakpoint.
I use it dozens of times a day -- it's critical for writing and understanding JS.
Since some folks write JS that has to go through a "build" process, it's easier to set a breakpoint in the debugger than to go back, modify the code, and "re-build" to get a breakpoint.
If you are worried to modify your code because of the long build process then the build system probably needs rethinking - make sure that only the files that were modified are rebuilt, configure your text editor so that it runs build script on file save.
To each there own as to how setting breakpoints works best for them in their workflow--my only reason for commenting was to let people know there were other ways to set breakpoints than adding "debugger" lines all over their code.
The debugger also lists all breakpoints set through it, which lets you easily jump to them.
For complex/single page applications, the `debugger` pseudo-keyword is not quite that good.
If I'm working with the code in a text editor, it's usually easier for me to find the code block in the text editor and type 'debugger' rather than root around in the dev tools.
In the WDT, there's a keystroke which you should be able to find (it's command-L in Safari)