Finding Bugs

So I was working with a buddy on a program he wrote in Assembly, he had nearly the whole thing complete, and before he's able to actually test it, he did one of the smartest things I can recommend if you can't actually test the code until some future date.

HE ASKED SOMEONE ELSE TO TAKE A SECOND LOOK.

Better then just asking someone else, asking someone else who has a better, even if it's slightly, knowledge of the subject, can see things that you might not see.

Now sure sitting in front of the computer with the board next to you and assembling, loading, running, then going back to debug can gain you some invaluable troubleshooting experience. I won't lie to you, learning how to attack a problem can be invaluable, but one of the biggest key's to do that follows.....

The key for the second person here, is to guide the programmer to the problem spot without giving away the answer if they know it.

Why so? By forcing the person to look at the code EXPECTING a problem they're going to start analyzing each and every line, Is it the right command here, did I set that up right, did I move this pointer to the right spot. EVERY LITTLE DETAIL should get scrutinized by the programmer. And that is good, they'll learn TONS and begin to see the big picture here.

Once you code something up, re-read it, re-read it again, now compare it to your design.

Wait a second I snuck something in there didn't I?

It comes back to design huh. IF every piece of the code you wrote can be traced back to a design element you wrote, you can break the problem, if there is one into a tiny piece, and that's a huge factor when you're working with 1k+ lines of code in assembly.

It might not seem to make sense working with a 50 line piece of code, but if you can force the habit it will make you a better programmer. I promise!