Debugging without breakpoints - "tricks of the trade" ?

Since I'm fairly new to the automation industry world and PLC programming, and I come from PC software development with some microcontroller experience, now working with PLCs which do not support breakpoint based debugging is giving me a hard time when it comes to finding errors.
I am "spoiled" by having debuggers available, so to say ;-)

Specifically I am using S7-1200 series PLCs and TIA portal V11, and do everything in SCL,
but I guess there are more general tips that you could give me:

What would you folks give as advice to someone coming from regular computer to PLC programming?
In terms of how to go about finding programming errors.
And also, how to construct programs in a way that does not make it unnecessarily hard to track program defects?
I'd guess that you can make it easier or harder depending on how programs are structured, and I lack the experience to do it the best way.

Thanks in advance

I haven't worked with S7, but it probably supports subroutines. You may be able to use conditional branches to help debugging.

Allocate a few DBs to store debug data every scan. Use a FIFO or circular queue for each variable you wish to log. Instead of stopping the program, stop the logging.

I use several methods, I am not very familiar with S7s but many PLC have the ability to trend on a tag, I build what I like to call traps by doing such things as using latches that perform no function except to latch when a certain condition happens or use the move command to store a value into a word that is only written to when a condition I want to capture happens,doing things like those two examples is very helpful. Also you can program using state variables this can be used much like your break points. The state variable will tell you what part of the sequence you are stuck in. Data loggers are always nice to go back and look at the state a variable was in at the time of the problem. I have the oposite history as you because I was first an electrician that learned PLCs then PC programming. I kinda switch gears between the two when programming a PC I use break points, message boxes, and all those standard tricks but when I am on a PLC I tend to think more like an electrician. While you must think sequentially with both I think in the world of PC programming you start at the top and work your way down with each line being affected by the one above it. In PLC programs each rung or small group of rungs perform a function independant of the rest of the program. A PLC program is really just a GUI with each instruction being a call to whatever function you are trying to use.

I would like to add one more thing, in computer programming you probably used time driven events quite alot, as you do PLC programming you should probably consider trying to use function driven events. example look for a limit switch closure rather then a timer to determine an event has completed. there are exceptions to this but as a rule this will keep you out of timing issues as the real world variables strike.

An interesting comment about using inputs rather than timers. I once had to figure out why a machine was extending two cylinders AND indexing at the same time on Cycle Start, but only on Cycle Start, resulting in a jam about 25% of the time. It turned out the programmer had used timers, and had created a race condition.

I know this is not applicable to you since you currently use the S7-1200 but the older S7300/S7400 actually supports breakpoint debugging. Link to FAQ

Other than that WinPLC analyzer and PLC Analyzer are two great tools for finding and logging sporadic problems. The new 1500 series have some of that functionality built in

If the error is serious enough to cause a SF, you can force the CPU to stop (by not having OB121 loaded). Then you can investigate the stacks and jump to the place in code that caused the error.
Not advisable on a running plant or machine, but ok for when you run the program on PLCSIM.

The new S7-1500 should have a trace function built in.

Debugging a running machine by just looking at the changing bits and values in realtime can be a nightmare. Some kind of tracing or trending is a real godsend. Recently I have used to take video screencaptures of my HMI (due to no tracing in S7-300). Crude, but it helped a lot.

Some interesting things here!
Video capturing HMI, that sounds like a lot of squeezing of status displays onto a page, but I'll keep it in the back of my mind