how do you debug the code?

[gnuarm]

You can write loads of code then set about debugging it.
Set breakpoints and create watch variables to see what is happening.
LED's on output pins and use of an oscilloscope if timings are important.

I tend to use incremental debugging.
I write a small module of code then fully debug it before going onto next part.
Its much easier to debug a small piece of code.

That's one of the fundamental ideas behind programming in Forth.  It uses "words" (the Forth term for subroutines) which should be tested before moving on.  They are typically small, so easy to debug one at a time.

[Psi]

I tend to use incremental debugging.
I write a small module of code then fully debug it before going onto next part.
Its much easier to debug a small piece of code.

Same. 
I write a little code, compile, run, check, tweak as needed. Then move on to the next block.
The size of the block I write before checking depends on how I feel at the time. I need to be able to hold the entire thing in my head.
I only use the debugger when something doesn't make sense.
Usually that ends up being a memory leak or corruption which doesn't occur when I use the debugger on it. Which only reinforces my view that the debugger is annoying and to never use it.
hehe.

I've seen some real wizards at using the debugger though,  it's an awesome tool once you master it.

[paulca]

+1 for logging. 

Flash memory for the log strings is probably the only cost.

You can, if you wish use a MACRO instead of a function, say:

DEBUG_LOG("Trying to Init UART2");

Which has a build time conditional flag to turn it on, or off.  When it's off the code for the logging isn't even compiled.

Log is W5.  Who, What, Where, When, Why?

Always put yourself into the position of some poor bugger tasked with fixing your code late at night, hunched over a laptop on a data centre floor.  What would they like to see in the logs?

Using a debugger often helps you too much and makes you leave out useful logging in tricky error prone sections.  If you had to have debugged it without one, you probably would have added debug diagnostics in them which would have helped others later if it had more bugs.

(I got angry a few weeks back because I had a framework failing with an un caught error like, "File is a directory" without telling me which one.  I looked at the code and got very angry.  The code was a mess, over complicated non-sense, it was also littered with about 60% commented out debug logging code.  Commented out.  It was very clear that, that section of code was error prone and fragile, so why the hell did they comment out all the logging and not add any error handling at all?  Argh!

Of course the downside on MCUs can be that the UART doing the debug logging is using up too much demand for "real time" in it's event handlers.  If you are trying to process timing critical streams/buffers in your main code, the debug UART code needs to be written very carefully.  No Serial.println("....");  and blocking calls.

In UART coms I have found the debugger is only helpful on the first fire.  As soon as you finish with that ITRS debug, the state will be corrupted the buffers overrun etc. etc.

[AVI-crak]

Debugging is boring. In one form or another, it is always a search for a program failure. An occupation as necessary as, for example, making money every day, especially when you are hungry.
It is much more interesting to polish the code to the ideal version.
You can turn on the optimization from "-O0 to "-Os" or "-Og", and calm down with a sense of accomplishment. Or you can change the algorithm so that it performs the same functions, but at the same time works 10 times faster, or takes 100 times less space.
Polishing can be done indefinitely, as long as there is a code for this.

I use the online compiler https://godbolt.org/ for small functions. It is not designed to run programs. It's for crazy people - who have already looked at their code 1000 times in step-by-step mode, and remember every instruction in assembler. There, any change gives an instant result.

[PlainName]

Debugging is boring

I would suggest that needing to debug is annoying, but finding and fixing a problem can be satisfying in the way soduko or wordle or mosaic can be. Or, indeed, polishing the turd until it looks shiny and goes like shit off a shovel, if that's what floats your boat.

Generally, debugging is a pain because you were intending to do something else and instead got a reminder that you're not so clever after all.

[gnuarm]

Debugging is boring

I would suggest that needing to debug is annoying, but finding and fixing a problem can be satisfying in the way soduko or wordle or mosaic can be. Or, indeed, polishing the turd until it looks shiny and goes like shit off a shovel, if that's what floats your boat.

Generally, debugging is a pain because you were intending to do something else and instead got a reminder that you're not so clever after all.

One of my early jobs was on the test floor of an array processor company.  At that time, it was essentially a supercomputer, now it wouldn't even be a floating point co-processor. 

I really liked the work.  Every machine was a murder mystery that needed to be solved, even if it had more than one death and villain.  Pretty cool when you think of it.  Often the people in test have to be smarter than they guys who design the stuff.  I recall a schematic for the part of the machine with custom ECL gate array chips had a block with no indication of what was inside, just a note that said, "Who knows what this does?" 

I'm not always that intuitive, and could get wrapped around the axle on some problems only finding the problem after multiple blind alleys.  But that's typical for a murder mystery, right? 

One guy on the floor had been a bus boy in a restaurant nearby that the head guy hired.  He took notes on everything he did, and managed to become one of the best guys out there.  He barely spoke English even.  I was very impressed. 

I work for myself now.  So I do the design work and then support the contract manufacturer to get the units working.  I don't do much debugging myself, but now I get to try to make the debugging as easy as possible.