まさにこの質問のように、プログラミングの速い人の意見をいろいろと聞いて、自分にあったものをどんどん試してみることです。

ネット上でもいろいろと語られているページがあって参考になります。

精神的な内容

http://d.hatena.ne.jp/teruyastar/20080308/1204977907

ツール的な内容

http://maruta.be/intfloat_staff/116

日々の努力的な内容

http://pgyougo.seesaa.net/article/110452306.html

よく使う構文やモジュールをテンプレート化して、CLCLに登録しておき、いつでもエディタにコピペできるようにしています。

表現力が高く簡潔に書ける言語をつかう。

できるだけ書かない。

(既存のコードの)流用、入念な設計・レビュー、テスト設計

段取りをしっかりやるほど、実際のコーディング・デバッグ時間は減るはず。

よく寝る。

飽きたらまた気分が乗るまですっぱりやめる。

エディターのカスタマイズ。

使用環境、目的に応じて、カスタマイズすれば、かなり効率が上がります。

エディタの事を好きになる。vimとかEmacsとかね。

簡単なものを たくさん書く。

きれいとか汚いとかは、あとで読み直したり書き直したりするときに整理すれば良い。

仕事のプログラミングではそんなこと言ってられないから

趣味プログラミングで数をこなせば良いんではないでしょうか。

コードを書くマシンを常に持ち歩きます。

単位時間あたりに書けるコードの量が少ないのならば、コードを書く時間を増やせばいい、という考え方です。

ふとアイデアが湧いたときにプロトタイプを書くまでに時間がかからないというのも大切だとおもいます。CPUなどのパフォーマンスをあまり必要としないので小型で非力なラップトップなどでもじゅうぶん活躍してくれるとおもいます。

あとは他の方が仰っているように、コードを書く道具を吟味したり、そもそもコードを書かない工夫をしています。

ライブラリをつくっておいたり、関数化とかクラス化しておけば、次に同じのがでたら書かなくて済むよ。

もしそこで収まらないようだったらリファクタリングをかけるぐらいで、なんとかできるようにつくっておく。

スケルトンとかフレームワーク化しとけば、書かなくてもいいし、テストも最小限ですむし、もしなんかトラブル要因みつけたら横断的に修正できるよ。

できるだけ書かないに賛成。

できるだけ書かなくて済むように準備しておく。

レビューにどんどん参加しましょう

他人のあらはよくわかります。

経験のある人のいうことも聞きましょう。

で、帰ってから自分のコードを見てみるといいです