The importance of a good font: I know this may sound trivial, but it's not. In some of the more standard fonts, x can look like z, 1 like l, i like j both of which may look like l, and various other nightmares. Picking a font to work in that doesn't have these problems not only reduces time in finding errors but makes it far less likely some errors will occur in the first place.

This is my favorite font; it's called Haeberli. Not only does it escape letter confusion, but it looks like something scrawled on the wall of a cave. When the emacs "syntax highlighting - colors" option is turned on, it looks like crayon. You know you've found a good font when it makes your professors wonder what on earth you're doing. :)

Incremental development: OK, so this one's neither new nor profound. But FDTD is confusing once you get to a problem of significant size or complexity, especially when you start dragging parallelism into the picture. So it's just easier to make one small change at time and test it before moving on; if something's wrong, you don't have to look far to find it. Or write a small test simulation to check out one particular section of code before putting it into the main source code.

Keep small pieces of test code handy: for trying out new concepts. Codes that are very small and run fast and that are short and simple to read make it easy to patch in a new piece and try it out quickly. ToyFDTD1 can be very handy for messing with memory allocation schemes or output formats. ToyFDTD3 is great for playing with boundary conditions.

Know when to modularize: Once your code becomes somewhat complex, it's time to modularize it into separate files to make it easier to keep track of and update. You'll know when you reach that point -- it's when you get sick of surfing through one big file to find the bit you're looking for and keeping track of variables makes you doubt your sanity . Small test codes are generally best kept in a single file. Modular code is demonstrated in ToyFDTD5.

Make friends with your debugger: Made friends with one particular debugger. It doesn't have to be the hottest thing out there, but pick a debugger and stick with it until you become fluent with it. Don't switch to a new one unless there's some feature you really need that your current one doesn't have. You can accomplish more by learning a basic tool thoroughly than by using a larger package for which you only know the simplest features.

Remember, this is a virtual lab: The field update equations in a code like ToyFDTD1 do simulate free space as a propagation medium. So if your results are showing something you didn't expect, it means one of two things -- either the simulation is correct and you didn't fully appreciate the physics involved, or you modeled something you didn't intend to. If the second of these is true, looking at the unexpected result and thinking about what physical entity, if modeled, might cause that effect could point toward the mistake. If the unexpected result is totally aphysical (like a signal propagating through 30 FDTD cells in 2 timesteps), that means you typed in something that branches over into the Cartoon Laws of Physics and you need to return to a Newtonian universe.
          (Been there, done that. My point source imploded and became a black hole. It looked really cool, if blatantly aphysical.)

Don't necessarily throw out your mistakes right away: It's good to know what certain kinds of mistakes do to the simulation. That way, if you see a similar effect again, you have an idea what the trouble is. And sometimes studying the results of a mistake will give you an insight into an effect you'll want to model later.