Of course, years later when I finally dug into SQL and interacting directly with databases, I had a much better understanding of their mindset and wish I would have learned earlier.

Now your mindset feels very similar to me - "I'll write my own shell scripts, thanks." So, to avoid making the same mistake twice, do you have any advice for what to read / learn to better understand your position?

Note: I've written plenty of shell, but the shell I've writen is way to hacky to use as a replacement for ansible.

Hopefully they were justified in their choice.

Most senior developers I've worked with who started with this mindset, be it about an ORM, a framework, or some library that they did not understand or wanted to spend some time to learn, ended up just proving that these abstractions were not completely useless after all. How? By recreating their own vastly inferior and headache inducing implementations.

I believe that there's an additional layer of skills between seniority and mastery. The former seems to be just about time and experience, whereas the latter adds a dimension of pragmatism and detachment. You become just a craftsman using tools with indifference to nimbly navigate complexity. You don't blame your tools, you just understand them, strengths and weaknesses. You know when to leverage them and when to ditch them.

That's also why I chose Bash to teach config management and deployment[0]. Do it in Bash, understand it fully. Then go a pick up a tool of your liking. Or not, if it actually does it job.

[0] https://deploymentfromscratch.com/

You obviously haven't looked at the code for some of the Ansible modules!

There are many things I don't like about Ansible and I don't think it's particularly robust, but it is an improvement over manually written scripts, most of the time, because writing robust scripts is not easy.

What I think "senior developers" are usually disparaging is using tools like ORMs without appropriate understanding of how they work, and thus being unable to recognize when they don't suit the task at hand.

I think in the long term, there may be a point where it will be more important to consider how the new collections are structured if you use ansible in a typical way, but right now at least, it seems like the new release plays nice with all my existing work.

That's exactly why it's good. It beat puppet, it beat chef, and saltstack fails to make inroads for the same reasons. They all make useless and difficult abstraction layers on top of what is essentially running shell scripts in loops over what's ultimately an ssh connection or a worse, proprietary version of one.

I won't defend some of the decisions Ansible has made over the years, but its simplicity is the key feature.

I started writing one about the time Ansible debuted because of some of its design decisions that I disliked. A bit later Docker dropped and I decided most of the whole category was approaching obsolescence already and stopped.

Given the above, and that a competitor would have to overcome Red Hat/investor money and mindshare, it doesn't seem there would be much of a demand for this. Ansible is arguably good enough for the niche it occupies.

The ideal tool is good in the general case, and still reliable in the edge case.

for i in $(cat listofips);do ssh $i “some linuxy thing” ;done

Why we keep reinventing wheels in infrastructure management and control beats me