Fast coders know their languages, frameworks and tools like the back of their hand. They eat docs for breakfast, have a knack for memorizing it, and an even stronger knack for making sense of it.
There's no shortcut: read the docs from the front to cover.
Not necessarily every single last page of it. But do make sure that you know and understand what is available and what is possible; well enough that googling typically occurs when you have a reasonable idea of what you're going to find already but don't have the specifics off the top of your head.
3rd-party libraries are a slightly different story, of course: you can't reasonably be familiar with every single one of them. What you can and should know, though, is what your languages, frameworks and tools are capable of and adequate for. This allows to be able to quickly locate any third-party library you might need, and quickly evaluate their suitability and quality.
Another important aspect is the lack of distraction: when given the opportunity to do so, faster coders tend to keep stuff like email and chat off, and get to work hours at a time without interruption.
Fast coders know their languages, frameworks and tools like the back of their hand. They eat docs for breakfast, have a knack for memorizing it, and an even stronger knack for making sense of it.
Sounds like a job add at the Startup From Hell.
Fast is a subjective term. How would you quantify? LOC/hour ? Words per minute?
There is no such thing as a "fast coder". You could differentiate from "mostly beginner" and "somewhat experienced" but that's about it, and even that is subjective.
I find "coder" a demeaning term and prefer programmer or developer.
Do you know a programmer that recommends himself as a "fast coder" ?
(Other than a job starved dev, in a low income country, to a low budget - low quality dev shop ?)
As DHH says, the main factor of velocity is feature negotiation: shaving off the 20% of stuff that takes 80% of time.
There's no shortcut: read the docs from the front to cover.
Not necessarily every single last page of it. But do make sure that you know and understand what is available and what is possible; well enough that googling typically occurs when you have a reasonable idea of what you're going to find already but don't have the specifics off the top of your head.
3rd-party libraries are a slightly different story, of course: you can't reasonably be familiar with every single one of them. What you can and should know, though, is what your languages, frameworks and tools are capable of and adequate for. This allows to be able to quickly locate any third-party library you might need, and quickly evaluate their suitability and quality.
Another important aspect is the lack of distraction: when given the opportunity to do so, faster coders tend to keep stuff like email and chat off, and get to work hours at a time without interruption.