I abhor having to learn a complex system/framework when such things as technology is a moving target and there is always another system/framework waiting to break-ground, were all the kool new-kids want to be. I just want to get my work done, go home and enjoy my life.

I personally wouldn't know where I stand, because I am not sure what simple and complex tools are, esp. if this is supposed to be a clear dichotomy. Does "complex" refers to internal complexity or complicated UX? Are some tools simple when doing simple stuff and annoyingly complex otherwise? Is the complex orchestration of 100 simple tools different from using 10 more complex ones? What are the complex tools "A" guys are shooting at (IDEs, scriptable text editors like Vim/Emacs/etc - damn, there was a point I was reading emails with Emacs -, Git, Rails)?

So, for me it's sort of an in-between thing. I do have a number of tools in my tool chest of which I would claim that they do at least an ok job at being easy to start using and helpful when the going gets tough. However, for the work I am currently doing the ramp up time was pretty awful again …

Oh, and I'm not a mathematician but a practitioner of almost 30 years experience. My professional roots are in banking and (micro-)economics.

Count me in for the A group, please. :-)

Also, Emacs is complex, but not complicated due to okayish modularity.

If this is true, it will cause an apparent skew: older (extant) tools are simpler than newer tools (which have not been through the same crucible of cross-generational adoption).

The question is not complexity vs simplicity. It's a question of comprehension across time. As we get older, most of us come to appreciate code that is written such that we can understand what it does with minimal effort. The overall cyclomatic complexity may actually be quite high, but the code can be very "simple" in that it's obvious what each modular part does and why. When we're younger, we tend to focus on just getting to the objective, by whatever means necessary. This approach is effective until we come back to that code a few short years later. This is true not only of our own code, but of components and libraries that we use.

So, if we rephrase the survey to "do most programmers value "simplicity" (i.e. clean, readable code) as they gain experience?" the result is likely unsurprising.

Single use tools are nice when your domain is mostly static. You have a problem and a single-purpose tool that solves it. Life is good.
Then you have another problem which is 2% different.
Do you build another tool from scratch?
Do you duct-tape extra functionality to the first tool?
Where do you stop?

As an engineer, I think I like flexible stuff with simple wrappers and sensible defaults so they all look simple from the outside, so A.

In my experience people who believe B rarely know very many tools to the depth they consider adequate. There's a basic law of conservation of attention at work here.

More to your point, ever since I started programming for real I would first try to use the simplest tool available and only when that fails go and dive into the more complex tool.

Too many "Mathematicians" make software programming tools that are internally simple and beautiful, but otherwise has atrocious usability. Maven's and Gradle's "configuration by convention" is great if you're in the mindset of the original developers, but otherwise has bad discoverability of its workings if, by accident, you deviate from the (non-obvious) conventions.

I don't mind pushing down the stack the user-centered design, even if it makes the code more complex, because it even makes development more usable (user and programming conceptual models match better). Compare Git and Mercurial for example: Git was built "Mathematician-style" bottom-up and is barely usable or extensible, while Mercurial was built top-down and is vastly more usable and easier to extend.

Ultimately, I guess I'm B. I'd rather embrace complexity for the sake of a more usable product for end users than choosing tools that make programming easier for me but creates a worse product. I'd rather be that SQL database guru than the "agile" NoSQL programmer that makes bad products in no time. I'd rather be the engineer that's fully aware of the ugliness of our current computing environment and shipping quality products than the mathematician living in a beautiful theoretical bubble producing nothing of use. Call me crazy, but I embrace complexity so that end users don't have to, even if my job becomes more difficult.

But in reality it may be the case they may feel a bit ashamed for not being proper "computer scientists" etc.

Maybe the ditinction should have been worded like this:

Mathematician: I hate all of those complex tools. Actually, I hate all the tools and I want them to die except for the few that I am already familiar with.

Handyman: I am not especially fond of complexity, but having gazillion tools (event the ill-cocieved ones) out there is a good thing because I can always find a tool that I can mutilate to do the task at hand, however weird and obscure it may be.

However, in this particular case, when I said "complex" what I really meant was "more complex that it neccessarily has to be".

And of course, handyman vs mathematician should be seen as a continuum. I think no handyman really likes ugly solutions, and mathematicians do care about output a lot, just that people have more or less marked preference towards process and/or output.

However, I'm feeling you are mischaracterizing B so that less people are likely to identify with it. I think people who are in B don't always feel like tinkerers, but rather that their main objective is to save time to be able to produce more.

Sure, you need to invest time to master complex tool. But when you do, you can apply the tool to a wide array of situations, and you can usually minimize you spend doing assembly.

Whereas mathematicians accept to expand more effort to build something they feel is elegant and simple, handymen just want something that works. It doesn't matter if the solution could be expressed more elegantly, if some parts are redundant, the design inconsistent or the abstractions clunky. As long as it gets the job done while expanding a minimum of effort, so that the handyman may go on building other stuff.

In the end, I think that is the key difference: mathematicians care more about the process, whereas handymen care more about the output.

In this must-see talk (https://www.youtube.com/watch?v=FvmTSpJU-Xc), Alan Kay divides programmers along two axis: "idea tools" vs "instrumental" (which could be "mathematicians vs handymen") and "inner vs outer" (depending on who influences the programmer's choices); so your idea has some credence :)

I feel it's slightly more involved - software complexity often gives us just headaches (1st thought - using XML as configuration format, something I always considered being some sort of masochism), but I believe some problems are just complex and require complex software. It's very much domain-dependent.

It's interesting what you wrote about learning new frameworks and technologies being not as exciting as it used to be - just couldn't agree more. As a side-effect, at some point you just become more hype-resistant :) New technology to save the world? OK, let's wait 2-3 years…

And given all the complexity of the technologies around, it's more and more difficult to cope with day-2-day tasks without a little bit of (over?)specialization…

Programming for 12+ years. Definitely A!

And yes I really despise model complex tool sets - hide the problem and stop you making process - bare bones editor and web page

How about a twitter handle to get the answers?