Very fast. Let me explain.

I work in 2 modes: (A) At the computer and (B) Away from the computer.

When I'm in Mode A at the computer, I'm cranking out lines of code,
testing, revising, testing, revising, etc. This process must be very
fast. Several hundred lines of code (or whatever) in less than an
hour. A complete cycle in less than a couple of hours. My guideline is
that if I'm not working that fast, then I must not be prepared to work
that fast, so I don't deserve to be at the computer. I should be in
mode (B).

Mode B is generally much slower. Reviewing code, specs, or notes.
Refactoring code. Laying things out with pen and paper. When I have
enough work clearly laid out, I know it's time to get back to the
computer and return to Mode A.

The most important thing for me in Mode A is to see results, any
results, quickly and often. It doesn't matter how correct anything is,
just as long as it's progress (or sometimes, reverse progress). I like
to think of programming as making incremental progress in micro jumps,
evaluate where I'm at, and go for the next micro jump.

Some of the best advice I ever got was from a prolific artist friend
of mine who claimed, "I paint every day." So I started coding every
day. But that wasn't enough. Now I make progress every day.

There are many definitions of progress. Sometimes I copy a few hundred
lines of code, make a few changes, spit out a new app, and then start
applying micro changes. Other times I decide that I need to see
today and find a way to get there. Things don't always work out as
planned, but that's OK. As long as tomorrow's starting point is beyond
today's, I'm satisfied.

That's my definition of fast. Not sure that was what you were asking,
but I hope that paints you an accurate picture.

* * *

Follow up response to "I've never seen anyone able to design something
away from keyboard that doesn't change significantly once it's
written"

It does change once it's written.

The idea is to get a clear work plan on a "close enough" design. I
estimate that my first cut of anything is maybe 50% or so.

The idea is also to avoid sitting at the computer all day and then
being disappointed with how little I accomplished. Activity !=
accomplishment.

A little more background...

First term freshman year, 90% of science students took Chemistry I. On
Mondays and Wednesdays, only 50% of the seats in the dining room were
taken for dinner. Chem Lab started at 1:00 p.m. and dinner was at 6:00
p.m. So, most freshman chemistry students took more than 5 hours to
complete their lab work.

This never made sense to me. I took Chemistry I second term freshman
year. My lab partner and I made a pact to never miss dinner. We did
everything we possibility could to expedite lab time. We did all the
reading, planning, and reviewing other people's results before we
entered the lab. We even wrote our reports in advance, filling in the
results as we went. Our longest lab took 2 1/2 hours. Our shortest
took 1 1/4 hour. (We also both got A+.)

I still practice that methodology today. My computer is my lab and my
bed or sofa is my lab prep. Preparation takes as long as it needs.
Labs go fast. If they don't it's because I wasn't prepared enough when
I started.

Original thread: http://news.ycombinator.com/item?id=1544338