I find this thread interesting because it's one of the few times I've seen a public discussion of programming style drill down to differences in skills or aptitudes.

When I've compared notes with friends, it often comes down to these, but I rarely see this discussed online.

For example, I find TDD to be either very high overhead or bad for correctness (for me) since I spent a decade working as a hardware dev who would often write one-off fuzzers, so I'm quick at those.

But TDDers seem to want a lot of small tests, which is an incompatible style.

Another example is, people with all of:

* Large working memory
* Fast typing
* Fast bulk editing (e.g., via emacs macros)

often don't mind high-boilerplate languages and often don't find "I could write that in 100 LOC in language X" compelling. They'll just write 500 LOC.

Contrast to sports: a decent coach will talk about the pros/cons of different styles/tools.

In software, most will claim that their style/tool is superior in all dimensions (or all that matter, anyway).

Programming is way behind sports when it comes to understanding techniques.

For example, compare

https://martinfowler.com/articles/developer-effectiveness.html

to

https://blog.paddlepalace.com/2014/01/coaching-tip-playing-the-seemiller-or-american-grip/

The former basically says an agile workflow is optimal (maximizes productivity); lists no downsides.

The latter discusses the pros and cons of a particular style, equal emphasis on both.

IMO, agile is highly unsuited for the kind of work I do, but that's not touched on in the article.

OTOH, the TT article tells you Seemiller is strong on D, esp. in mid against backspin, weak corners, weak backhand loop, easy to use funky surface. You know what you're getting.

In every sport I've played, coaches understand the pros/cons of various styles, even ones they aren't really fans of.

In software, I don't think advocates are even being deliberately disingenuous; I think it doesn't even occur to people to think about downsides of their style.