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, 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, 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.