The trick is not to write code faster, but to write working code faster.

The sooner your spot a bug, the less effort it is to fix it - this is the primary thing which affects programmer performance.

It's not about how fast you type, or how fast your compiler is, it's about the speed at which you can identify bugs and fix them as you go.

Therefore, I'd suggest pair programming as a way to be faster - it really does avoid bugs. That and test-driven-development. Having two pairs of eyes makes it more than twice as hard for bugs to slip through (I think anyway).

Other tips would be

• Try to reduce your code-test turnaround time to a minimum - this obviously depends on your platform an tools. If you're working on a silly embedded system with lame tools, turnaround time could be quite signifcant (for example if you need to rebuild a system image and re-netboot the device), VMs or simulators can help here.
• If not pair programming, ask others for informal code reviews occasionally, but only at logical breaks in your (and hopefully their) flow. Do this in addition to your formal code review process you doubtless have.
• Keep it simple - don't over engineer. You ain't going to need it.