Rather than tell you how fast I code, I'll hopefully provide some insight in to how to become someone who codes quickly:
1. Coding environment. Part of this is the physical space around you, distractions, mental state, etc., but you can probably figure this out best for yourself. The other part is inside the computer. You need a good editor, and you need to be comfortable in it. Vim, emacs, or an IDE. Whatever it is, it needs to really understand the language and libraries you're using (code completion, syntax highlighting, build/run/debug integrated, documentation integrated (emacs has M-x man, vim has K)), and if your language supports it, have a REPL at hand too. The most important thing here is knowing that, no matter what you want to do (move text, change variable names, start a debugger, set a breakpoint, etc.), you don't need to think about it. Your hands and your machine need to become an extension of your thought process, to the point that you think something about the code, and it happens, with as little overhead as possible.
2. Familiarity with language/libraries. If you're spending over 20% of your time looking up documentation for language features or the standard library, you're never going to code as fast as you want to. If you're a C programmer, spend more time with K&R, A Book on C, and sections 2 and 3 of the UNIX manual. If you really invest the time to memorize your language and common libraries, you can cut your development time down substantially. Of course, to do this, the best thing you can really do is just to spend a lot more time coding slowly, so go do that now.
3. Project preparation. Before you sit down to code, you need to know what it is you're coding (unless you're doing exploratory programming, which, while wonderful, requires even more of #1 and #2, and will never be "fast coding" per se). Sit down with a whiteboard or a pad of paper, or just sit and think if you have a good memory, but plan out what you're going to code. Here, YMMV a lot. For some, it's very important to have classes, interfaces, functions, etc. planned out before they code. Others need to plan out the UI to great lengths first. Personally, I think about data flow and constraints and let the function organization emerge (and then stress for a long time about the UI anyway). You should play around with how much preparation you need to do, but you definitely need to do some preparation.
4. Knowing when to stop. Apart from looking up documentation, I think I waste the most time making the code more and more optimized or more and more beautiful (read: unnecessarily clever). If you really want to code fast, you have to let go. When it works, it works, and you can stop for the moment. You can always clean it up later, abstract things away, refactor code, whatever, but you'll be more satisfied if you say "okay, my project works now, I'm going to go have a snack/smoke/nap".
1. Coding environment. Part of this is the physical space around you, distractions, mental state, etc., but you can probably figure this out best for yourself. The other part is inside the computer. You need a good editor, and you need to be comfortable in it. Vim, emacs, or an IDE. Whatever it is, it needs to really understand the language and libraries you're using (code completion, syntax highlighting, build/run/debug integrated, documentation integrated (emacs has M-x man, vim has K)), and if your language supports it, have a REPL at hand too. The most important thing here is knowing that, no matter what you want to do (move text, change variable names, start a debugger, set a breakpoint, etc.), you don't need to think about it. Your hands and your machine need to become an extension of your thought process, to the point that you think something about the code, and it happens, with as little overhead as possible.
2. Familiarity with language/libraries. If you're spending over 20% of your time looking up documentation for language features or the standard library, you're never going to code as fast as you want to. If you're a C programmer, spend more time with K&R, A Book on C, and sections 2 and 3 of the UNIX manual. If you really invest the time to memorize your language and common libraries, you can cut your development time down substantially. Of course, to do this, the best thing you can really do is just to spend a lot more time coding slowly, so go do that now.
3. Project preparation. Before you sit down to code, you need to know what it is you're coding (unless you're doing exploratory programming, which, while wonderful, requires even more of #1 and #2, and will never be "fast coding" per se). Sit down with a whiteboard or a pad of paper, or just sit and think if you have a good memory, but plan out what you're going to code. Here, YMMV a lot. For some, it's very important to have classes, interfaces, functions, etc. planned out before they code. Others need to plan out the UI to great lengths first. Personally, I think about data flow and constraints and let the function organization emerge (and then stress for a long time about the UI anyway). You should play around with how much preparation you need to do, but you definitely need to do some preparation.
4. Knowing when to stop. Apart from looking up documentation, I think I waste the most time making the code more and more optimized or more and more beautiful (read: unnecessarily clever). If you really want to code fast, you have to let go. When it works, it works, and you can stop for the moment. You can always clean it up later, abstract things away, refactor code, whatever, but you'll be more satisfied if you say "okay, my project works now, I'm going to go have a snack/smoke/nap".