All else being equal, the fastest code to write is the shortest, simplest code. By being physically shorter there are fewer keypresses (although actually pressi

All else being equal, the fastest code to write is the shortest, simplest code. By being physically shorter there are fewer keypresses (although actually pressing the keys is something I do for a very small percentage of the time spent), and by being simple you will find it much easier to keep track of what's going on where, and you will spend less of your cognition keeping track of it all and can spend more solving the actual problems. This will often involve moving your fingers away from the keyboard and forcing yourself not to type anything until you have adequately solved the problem, be it inside your head or on a sheet of paper or whatever helps you think. Some people do find that tapping out some code helps them think, but be very careful; if it's part of your pre-coding problem-solving, do not allow your initial problem-thinking code to mutate into your actual code beyond the fact that both of them exhibit a solution to the problem. The odds of your first draft, pre-coding solution-exploring code being the best structure and layout and style and so on, are so slim. The fastest code I write to solve tricky problems tends to involve an hour or more of thought and drawing and tinkering and examining the existing code and tracing values and running the debugger, and finally a few minutes of typing. Sometimes, if I'm very lucky, I simply delete a line or two of existing code at the end of a half-day's examination and thinking. I then sit back and have a minor fit of hysteria at what would have happened if I had tried to solve that problem by typing first.