... aside from finishing, of course. Thinking up the original idea, planning, building, refactoring, showing your project off, etc. For me, it's definitely refactoring.
Damnit, I was gonna say "finishing". ;-)<p>Aside from that, it's the incremental refinement that happens after you have a basic architecture, a useful app that puts stuff up on the screen, and a small userbase. Changes are usually pretty easy at that point (if you did the architecture right), and there's the instant gratification of writing a feature and having people immediately use it.<p>I find that most projects follow a "ski jump" happiness curve. Thinking up the initial idea is a lot of fun, as are the first few planning stages. Then you come up against all the little details that are absolutely necessary to build something useful, yet not really fun to deal with. By the time you're about 2/3 through with building it, it looks hopeless. Then you start cleaning things up and figuring out an architecture that reconciles all the different concerns. If you haven't made <i>too</i> many tradeoffs by then (or skipped the step entirely), the launch and refinement process is kinda fun.
What lures me to programming is an obsession with progress. While I've learned to appreciate the process of programming, the elegance of properly done code, and the seeming lack of limitations, seeing day-to-day, week-to-week, yearly progress is huge for me. I like looking back and saying 'wow, my robot/program could not do this two weeks ago'. Maybe it's just because I am vain!
In bottom-up design, the most fun part is implementing the lower strata.<p>Runner-up: when you've just blindly written 1000 lines of Haskell code, then you run it through ghc and it typechecks on the first try.
I'm definitely happiest when I'm in the middle of creating something I can't wait to see finished. The other really fun part is standing back and watching others use it. Every time I create something that's truly useful I'm as satisfied as if it was the first time I'd ever done it.
Each little well thought out part that works, and what I learn from novel situations that I've not dealt with before. Seeing progress and seeing the solution unfold as I explore the problem domain in greater depth and breadth.
CODING! My work must be 99% debbuging legacy code and documenting, or modifying code to work with the test environment, and only 1% actually coding something new and useful, but this 1% make it worthwhile.
The proof of concept stage, where you create something and show that your idea works.<p>That's where the 80/20 "rule" comes into play - 80% of the work is getting that last 20% right.