Well, I think I'm not slow, but the work I'm given tends to fill the available time.

Regardless, I oftentimes hear "Gee, you did that quick", but it's not from being a fast coder, it's from coding less.

I think the main way to code less is to think like a DSL. If you can't get the code generated for you by a preprocessor, then write a code generator. It doesn't have to be fancy. The objective is, if you are given a single stand-alone requirement, to minimize the number of *source* code differences needed to implement that requirement. Ideally, that number is 1. If you can get it down around 3-6 on average, that's pretty good. (It's not just that you're writing less. The smaller this number is, the smaller is the number of bugs you're putting in, and that *really* saves time.)

To do this, I recommend doing [performance tuning][1], because then you will find out what coding practices lead to the greatest slowdowns, and they also lead to bloated code. In particular, excessive data structure and event/notification-style programming. Those things alone contribute massively to code volume.

Much code volume these days is due to the user-interface, especially if it is dynamically flexible. I stumbled on a way to do that part, called [Dynamic Dialogs][2], which has a tough learning curve but shrinks the UI code by roughly an order of magnitude.

You'll have to find your own way on this, I'm afraid, but best of luck.

 [1]: https://stackoverflow.com/questions/926266/performance-optimization-strategies-of-last-resort/927773#927773
 [2]: https://stackoverflow.com/questions/371898/how-does-differential-execution-work