In this style of programming, you sketch initial design, program, test,
program, test, program, test
and then step back. 
See what the program looks like, write down some interesting program or design choices you made, maybe refactor the design to match the program, or the program to match the design.
I also like to talk it over with someone, explain it on a whiteboard. Listen to your own explanation, because often you will come up with better names and concepts when you explain.
Also discuss coupling and cohesion, likely extensions and so on. 
This sets up a nice rhythm where you do programming, but don't get lost in the details.
Do this often, say once or twice a week, and your code remains crisp.
Don't spend too much time either in the Pause or in the Programming.


This could be considered a milder version of PairProgramming; although it might help even there, because the pair might also know ''too much'' about their program and lose perspective.

-- AamodSane
-----

This could be a useful way to figure out exactly how to DoTheSimplestThingThatCouldPossiblyWork.  

''Yes, but don't take too much time - try something simple and let it teach you.  As much as I believe in PausefulProgramming, I've learned to believe in immediate experimentation even more.''

Are there any other habits that lend themselves to figuring out what the simplest thing is?

-- JohnHeintz

How about SoftlySoftlyCatcheeMonkey and RefactorMercilessly?

Writing a UnitTest first helps, because your goal is only to solve the current problem in the cleanest possible way. Rewriting code until you can't think of anything else to do with it encourages simplicity thinking, too. PairProgramming helps, because you can't continue unless both partners understand what is going on. FloatingPairs also helps, because you can't spiral off into a private TwinLanguage. LiterateProgramming helps because you are forced to look more carefully than ever at your code.