You can't solve individual problems faster(unless they're familiar problems, which doesn't make you an "overall better" programmer, just better in that problem domain). Every programmer tends to fall within a certain range of time-to-solutions when they encounter a novel problem for the first time. Innate ability is, in the end, not something worth worrying about because it's also not a "universal", it applies to particular problems just like domain knowledge. What you can do is create a workflow where you have fewer incidental problems, and so you end up being faster and more accurate in your coding all the time because you just don't run into trouble.
1. Can you write less code? Not just code-golfing, although that is worth experimenting with(see Arthur Whitney's code. Make an honest attempt to "get it" without just giving up). You'll have to develop your own metric, but some combination of - lines of code, new names declared, branch points, nesting, subroutine length, etc. can usually tell you if you're progressing.
2. Can you use fewer language features? There is an ingrained tendency in many programmers to jump onto everything new in fear of being left behind, and then use all of it at once on a project where it's wholly inappropriate, becoming "that guy" who constantly reveals compiler bugs. But the features that last over multiple generations are the key: People shipped good software with it before, and they'll do so again, so if you stick to a conservative subset and roll your own abstractions otherwise, you can use familiar techniques everywhere, but enjoy an incrementally smoother experience with the newer environments. (Of course, at the extreme end you also become "that guy" who is coding everything like it's the 1960's, but at least that means that you are probably productive in some way, if not really up to speed.)
3. Although I dismissed familiarity in specific problem domains above, diversity of experience with specific problems is better for your overall abilities, because the natural grain of problems exposes different styles of coding.
4. Do you know your tools? Not just "I can use my text editor and compiler," but rather, have you tried to deeply evaluate all the technology available? If you can use a simpler toolset, that's usually better, because something simpler is easier to extend or replace. Something that is deep and intricate and complicated is bad, because it becomes an edifice. True of the code you write, of your coding environment's configuration, and of the tools you work with, be it editing, builds, source control, etc. If you rely on a debugger for everything, then you're at a disadvantage when you don't have it. So you have to adapt to the situation.
5. Do you put the data first? This is the flip side of the "edifice" remark - your code never lasts, but your data does, and, less frequently but perhaps even more importantly, protocols and formats you invent for passing around data also last. If you're taking good care of the data, everything else become possible. But if you tangle it up in a way that makes it hard to work with, everyone gives up.