(NOTE: Becoming a faster developer isn’t necessarily the same as becoming a more productive developer. Becoming a more productive developer is better. Speed isn’t everything!)

Following up on my post about typing speed, QWERTY/Dvorak/alternate layouts, and the idea that your keyboard layout probably has little to do with your performance (although it might have a little to do with your happiness), I wanted to think about what makes a fast programmer. People tell me I’m fast. I know people who can pull programs together even faster. We touch-type, for sure, but that’s the least of it.

A huge part of development speed is experience. If you’re familiar with a programming platform, the error messages, the structure, the way things work and the way things are named, you can learn new concepts and write correct code much faster than a newbie can.

What if you’re faced with a new framework? You’ll still get a speed boost if you can relate the concepts to other things you’ve learned. If you can figure out the control structures you need and the debugging techniques you can use, then it’s mostly a matter of translating to the new framework and picking up any quirks or local idioms.

So let’s break it down further. What are small, specific skills that can help a developer get really fast?

• Touch-typing: Still practically a given. You need to be able to think about your code, not about typing code. If you aren’t yet a touch-typist, sit down and work on that.
• Speed-reading: This comes in handy everywhere. Much of programming is reading: reading requirements, reading other people’s code, reading documentation, reading logs and debugging output. This is probably more useful than typing at a gazillion wpm. You need to be able to quickly spot the significant parts. Learn how to skim.
• Working with complex structures: The better you get at understanding complex structures or logic, the faster you can come up with more effective solutions, and the less time you spend going back and forth. You don’t have to do it all in your head. Find systems that work well for you (notes? mindmaps? diagrams?) and use them.
• Problem decomposition: Breaking big problems down into smaller testable steps can help you make quick progress and keep things manageable. This is also one of those skills that can give you lots of leverage on time. If you can get really good at spotting the core of the problem and figuring out the key parts of the solution, you can get something into place much faster. It’s also a useful skill for testing code thoroughly.
• Good development practices: Source code control, testing, and all sorts of other development hygiene practices means less time spent fixing avoidable mistakes.
• Collaboration: If you can get someone else to do the things you’re really slow at so that you can focus on the things you’re really fast at, the team can get much faster. This also includes documenting your work so that people don’t have to reinvent the wheel.

What would you add to this list?