[marginalia_nu]

There's aspects of personality I think. Let's use D&D terminology to make two caricatures.

* Wizards need to prepare their spells before they can be cast. They want upfront planning and design. They rely on rules and systematization. They prefer top-down design, breaking a large problem into smaller and simpler ones.

* Sorcerers cast spells at will. They're more volatile, but their flexibility is greater. They prefer to inundate themselves in the problem and experiment their way forward and to sort of mold the code like clay until it does what it should. They prefer bottom-up design, starting by constructing small pieces and moving on to growing a large solution organically.

Wizard programmers will think sorcerers are sloppy, undisciplined and out of control.

Sorcerer programmers will think wizards are overbearing bureaucrats stifling progress with unnecessary rules and plans.

I don't think there's a clear cut best approach here. I've known developers who were extremely productive in the long term with both approaches. It is probably fairly domain dependent. Wizardry is significantly more reliable when the domain is well understood, sorcery has a definite upper hand in a poorly understood domain.

I think the strongest programmer is capable of both styles. They're very different disciplines though, so this is hard. Wizardry requires capacity for patience and discipline, while sorcery requires a strong intuition for design and faith that the design will come together despite not knowing how in the moment.

[eqvinox]

Those strongest programmers you mention are clearly multiclassing minmax D&D players :D

(… love the D&D analogy. But very much agree with its meaning too!)

[marginalia_nu]

To be fair the strongest programmers are probably just gifted, outliers not just in reason and intuition but also people skills.

[makerofthings]

I love this idea, I think it’s going to make Monday easier. I wonder how much this is two types of people and how much it’s two ways of working that different people got used to.

[marginalia_nu]

My hunch is that when you started programming matters.

I'm more of a sorcerer, and I first started coding when I was like 6-7 and never stopped. A seven year old really doesn't have much capacity for upfront design, planning or reasoning, so I learned to design code intuitively. I feel a lot of people who didn't really get into coding until their late teens, university maybe, they tend to lean more toward using reason than intuition.

This is mostly relying on low-N observations though so no idea if it's true. Seems plausible at least.

(although as a counterpoint I'll admit I'm a bit of a cut first and measure later sort of person even outside of programming)

[vlovich123]

For what it’s worth I don’t think your age thing is accurate. As a counterpoint I started as a teen and still prefer to grow the code mostly organically and trust that a) I can make fairly robust decisions on the fly for durable decisions and the non durable ones don’t need as much thought. Even up front planning will miss design mistakes when review by multiple people.

[eqvinox]

It might be more relevant how you started programming. If you're playing with things, taking them apart, making them do odd things — it's likely you pick up a bottom-up understanding, messing with minor aspects at first. That lends itself to becoming a "sorcerer". Conversely, if you acquire a skill in pursuit of solving a specific problem (and matching how things are taught, mostly), you start top-down, becoming a "wizard".

[vlovich123]

Yeah that sounds like a more plausible hypothesis. Although the line is very blurred about how you defined “specific problem”. Everything I started programming with was specific problem I was having at the time (writing a media indexer to dedupe my music library, writing a presence simulator to fool those early “pay you for browsing your computer” adware) rather than just playing around for the sake of playing around. From one respective I was picking problems randomly and seeing if I could solve them so I guess that’s more playing around. But it’s not like playing around with graphics where you try to see what kind of effects you can create.