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.
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.
a) reduce reduce reduce. As much as possible, remove abstraction, remove layers, remove lines of code. A few things are useful to abstract, but for many abstractions, you optimistically trade the underlying complexity for a new layer of different complexity; and then it usually turns out you need to know the underlying layer too, so you actually have twice as much work.
b) I don't worry about getting things perfect (or locked down) the first time. Most things are poorly specified and will need changes, and it's easier to see what you really want, once you have something that's close. Usually, it takes two or three times doing the same thing before you get it right; in that spirit, don't stress over the first time. Also, the least amount of time you've invested in the first draft, the least ego you sacrifice to throw it away and do it right.
c) That said, use your experience to make more right choices than wrong ones, especially for things that are hard to change later. Consider how you will scale things: you don't need to make things scalable, but don't make it a dead end.
d) code re-use (as in calling existing functions) is nice, but don't be afraid of some near duplication: changing a core function "a little bit" to get it to work for your new case is a significant time investment. If you're not confident that the change will stick, copy and alter; you'll be more willing to throw the changes away if you need to after that.
Also, learn your toolset inside and out so that you are worrying about use case, not how to use the tools or specific programming language to solve your problem. If you are only solving a use case, and not learning the toolset then time moves much faster. I don't know any real numbers, but assume most devs know 50% of the toolset (language, IDE, debugger etc), then highly efficient devs know 85-90%. So they don't waste their time learning how to do something but rather spend their time learning which route to take to solve the problem correctly.
I have worked a lot in consulting, and either we create and share a common library with clients (which some refuse) or we use a snippet library to stop us from writing the same common code components. Better a snippet library than having a good memory which means you might miss things and have to repeat mistakes which costs you time.
Anyway, for "fast", think about what you are doing first. Write some psudo-code algorithm on paper first. To get into the flow, avoid distractions, and focus on one thing.
Pushing back a little on hard-to-implement use cases usually wins you more time than typing faster. ;-)
"Overtly generalized code is the root of all evil."