Interesting, I've never had much experience with Forth but I looked into it after reading your post and I'm quite intrigued. I may start messing around with it a bit.
Win32Forth comes with a nice text editor that has a project manager. I don't use that part but others find it useful. It also has a way of finding the Win32Forth source code of any of the Win32Forth words as well as any word that you've compiled. Sometimes with deferred words it is more useful to see what was actually used. There is a 'see' decompiler.
As others will tell you, it has a steep learning curve to properly use it. Many of the bad habits you've learned in other languages will make poor Forth. Parameters are passed on the stack and there are a lot of stack manipulations words. If your righting good code, you won't be using more than OVER, DUP, SWAP and DROP. You must always think in terms of the steps you would use to do something, unlike most other languages that are out of order. Good Forth code reads like sentences, not formulas. This makes things easier to debug and understand.
I had a friend write some Hamming code. When he turned it into his manager that didn't read Forth, he returned it and asked where the code was, because the stuff he'd gotten was just the definition of what to do. When you get to that point, you'll know you are writing good Forth code.
Forth can amplify bad code to be even worse. Years ago, I helped a friend out at Seagate. It was a servo track writer written in Forth that wasn't working. It took me several hours to understand where in the code it was messed up, even after I knew what it was physically doing wrong in the servo writer. The fellow had written code like it was translated from BASIC.
One thing you'll rarely see in Forth implementations and that is any form of type checking. This is good and bad. Still, you are a big boy now. To make up for this Forth makes it easy for you to test your code for correctness as you write it. You can then easily tune it to the application your working on. If you add an integer to a floating point it will make a garage number. Forth almost forces you to test as you write. After using it for a while, you find that you already know what to test for. If you're using something like a counter that starts with an offset, as you write the code you'll start thinking about the exception cases to test for. That is the best time to test that piece of code, not after you've written 20 more pages of code. The language won't be in the way if you want to subtract 41h from the ASCII letter A. No more having to cast it with intent or, worse, having the language do it without telling you.