What does fantastic programmers do differently than the average one?

I have worked with a couple. A first in zoology who moved to code and wrote games in assembler, and also complete compiler systems for minified versions of the languages of interest: Algol, Fortran, C -He also tinkers in hardware at all levels and can re-frob a radio into a theramin from the principles of how circuits work, or can make a magnetometer based 3D action glove from bits in his toolbox. Another who coded C compilers for a living before GNU destroyed the marketplace. A third who uses FP (Haskell) to reason about systems as types, before even considering code to mutate those typed objects.

The first thing is, they all tended to have a really strong grounding in mathematics, around logic, statistics and related subjects. They had underlying conceptual models grounded in the formalisms of a maths discipline.

The second thing is that they had very high functioning reasoning skills. If then was very strong in their ability to see inherent linkages between specific and general, to take an abstraction and apply it, or to find a mapping to that concept in another domain, work in that domain, and map back into the field which applied in the first instance.

The third thing is that they seemed to go from solution hypothesis to code very naturally: they didn't hesitate to follow a code path, there was no sense of "suck it and see" -To me, this is the bit which makes me really wonder WTF was going on because my own code is littered with "this failed" attempts to get to the functional outcome.

So, there's a lot of maths, a bit of process in abstract reasoning and a giant ocean tanker of confidence.

I have watched these people sit for 6 hours exploring how to use assembler to shave two instruction cycles off a task. The focus required to model the behaviour of the system and do this in a pre-omptimising compiler world, in the tools of the machine, were amazing.

The characteristics that I think contribute are extreme attention to detail, patience, ability to extrapolate from examples encountered to fine-grained concepts, and lots of practice either on the job or via other transferrable field or hobby. Having a strong sense of how machines work, as in being able to guess which tradeoffs will pay could be a power-up. Typically, a person who wants to learn for its own sake and enjoys hard challenges like a game.

Being able to adapt and relate, draw analogies from different situations and subject areas can be a big boost in ability to come up with outside-the-box solutions. I think most of this sums up to thinking abstractly most of the time, rather than when necessary, or 'architect'ing. When something doesn't work, it didn't merely not work, it didn't work because... of some specific aspect or misconceptualization.

Subdividing a problem can be done many different ways. We want to separate concerns, but which ones, in what order and by what means. Keeping both higher-level and lower-level concerns in mind simultaneously speeds filtering of possibilities to something that has a good chance of working out.

Another good one is knowing what's fair game to modify when coming up with a solution is larger than one might think. Beyond the code, there's toolchains, data formats, even UX or documentation could be part of the answer.

Edit: I can't stress enough the importance of naming things. If you're bad at naming things, it could be you don't know or aren't even choosing the things consciously. Often, you start out needing a name for something but put in the time to think "what is it, why is it, is it more than one thing?" when you pick out names. I think practicing good naming probably gets you moving along the right path. Keep things as simple as you can, don't add to cognitive load by naming similar things with arbitrary differences in their names.

Extraordinary artists and technicians are not necessarily the most skilled with the tools. Sometimes they just filled a void and did something new.