How often should I be running code and debugging it verses trying to spot errors before they occur?

Are you testing it out incrementally as you run your code, even if it's just with print-debugging (print the current values of whatever variables are in play to the console)?

This helps you find errors faster.

Similarly, breaking out longer chunks of code into smaller methods lets you test each individual piece.

It doesn't really matter if it's lazy to use a debugger if that's what it takes to solve a problem. Ideally you're catching bugs as they happen and verifying the correctness of your program such that when an error occurs, you know that it's most likely contained in the last few lines you wrote. But this isn't always possible.

Similarly, it's not always the case that the error is easy to find via the debugger.

This may also be a good time to learn about unit-testing, if you're not using that already.

All of the solutions here, though, basically boil down to "Break your code out into smaller parts, then test each of those parts, and also make sure you're checking things as you go along rather than at the end."

Depends how much time you are debugging. If the vast majority of the time is spent debugging, then you need to run you code more often. If you only have a couple minor bugs, then keep doing what you are doing. Just make sure to refactor after all of the debugging.

Lazy is good!

A good programmer would never do by hand what a computer can do for you!

There's no point in looking at your code for syntax errors. That's what the compiler is for! Actually, that's what a good syntax-highlighting code editor is for first, and compiler second.

Good programmers realize that it's impossible to write a sufficiently long or complex program correctly the first time. It makes far more sense to plan ahead and assume you'll be spending time debugging.

For that reason, make your program testable right from the beginning. Add log statements to your program but make it easy to disable them later when everything's working. Don't delete them, just make them do nothing until you need them again later.

A lot of programmers use test-driven development. It's not a technical strategy, it's a psychological trick - by writing the tests first, you force yourself to think of the corner cases, and then you'll know when your program is actually done because all of the tests will pass.