Have you ever found a software bug and then went back to add printf and other debugging capabilities later?
I think we’ve all done that. However, that approach is way too late. There is one true maxim in software:

Your software has bugs

Given this, the best approach is likely to add debugging capabilities first, then add the actual code later. There are plenty of advantages for this:
1) You’re much more likely to add the debugging prints if you have easy to use debugging functions
2) Issues will happen almost immediately once you start writing code. You will get to writing working code faster if you have a consistent debug method

In Windows/Linux, printf and similar functions are one way to go. Please note that using a good debugger in itself is critical, however, it’s sometimes easier to see
a chain of events happening when it prints. Make sure to use the line number Macros in C whenever possible since they’ll let you know immediately where the error is.

In embedded systems this becomes a bit more tricky. Embedded debuggers provide the ability to use printf across JTAG and this is quite good sometimes, but it might be better to use a separate UART connection. Another good option is that if your system has any kind of flash storage (such as SD card) then print the log information there. This is useful in the long term when you’re not paying attention and everything comes crashing down. You can then have a look and get a better idea of what is going on.