Back when Luke wrote Puppet, he himself admitted that he was a mediocre developer with a good idea. His premise was that most SysAdmins weren't developers and that they would be more effective with a DSL that wrapped a templating engine and an executor then really learning how to code to build their own tools.

This set just an ugly trend. Next came Chef, which was written by someone (Adam Jacobs) who was pissed off at Luke because he felt entitled to 100% of his time. This was an incredibly dramatic exchange, Puppet Issue #1010 (I can't seem to find any of the old tickets anymore). Adam was making bank off of Puppet consulting, Luke was barely scraping by.

So Chef came along, it was supposed to bridge the gap between Puppet and developers. It was also garbage, but after a few years you could sort of kind of do real development on it.

Then we got Ansible, meh. Salt Stack which was more for managing api driven saas infrastructure but had/has a lot of the bad architectural decisions made by Puppet.

Now we have Terraform, which is OK, but also garbage. On top of that there's the Terraform CDK, which sort of lets you code, but is really just a golang-like DSL that generates HCL or Json. We also have Pulumi, which like the TFCDK, is a golang-like DSL that .. generates HCL to be run by Puppet.

All of this garbage because Luke felt that Sysadmins couldn't code.

If I had a euro any time I heard a sysadmin tell me 'they can't code', only for me to see them write perfectly good Python... A euro for every time a sysadmin tell me they really want to program more, but they think they're underqualified to even start learning, even though they write higher quality, more maintainable and better designed code than most fresh CS grads I've met... But they're stuck writing YAML and HCL and maybe some shell scripts, because that's what the industry tells them they are qualified to do.

Years and years of gatekeeping 'real programmer' jobs behind silly algorithm trivia and CS degrees is to blame, IMO. Ansible-style DevOps is more of the same, pretending that programming is too difficult. So here, have this cursed undebuggable, untestable DSL that is totally not a bespoke programming language.

And if i had an euro for every sysadmin who told me "i'm not a developer, you do it", i'd be rich. "Sysadmin" includes Windows-only, GUI-only, ClickOps style admins, which still exist. Do you think they can or want to code? Heck, there are even networking admins that prefer to use GUIs over CLIs!

Not everyone can or wants to write code, even if some people underestimate their skills, some people are afraid.

Judging by how popular Powershell has become in these 'GUI-only' ecosystems: yes, a lot of them can and want to.

But I'm not saying everyone always should code. I'm saying that not only wrangling Ansible and Terraform is already programming, it's a difficult kind of programming (no tests, no debugger, usually directly on prod), and that we should stop pretending that it's not. That the industry should stop it with the self-fulfilling myth that sysadmins don't want to program by continuing to build 'DevOps' tools centered around lame DSLs. Give sysadmins real programming languages, libraries and guidance on how to program, not shrink-wrapped tools that pretend they're purely configuration driven yet implement a full-blown programming langauge on top of YAML.

One thing that really helped my teammates and friends was asking them to do code reviews of my work, and them realizing "hey, if I understand this, I can fix it, if I can fix it, I can write it!"

Another was Ruby. Sure, Ruby sucks, but it's easy, almost anything you did just worked. This was why Puppet was written in Ruby (Luke spent months trying to do it in Python, then when he tried Ruby he had a working prototype in 2 or 3 days). Ruby was a great transition language.

In others companies it means separate siloed DevOps teams and people, You need to raise request to do anything on your servers. Sometimes deployment mean getting DevOps team approval in process.

I also dislike DevOps terms because it is not specific enough on how you should organize Dev and Ops concerns.

I'm always upset when I see a installations that are created with pattern: "we need it to run and we doesn't care where system will be in next two years" (in trashcan, usually - or it will act as a jumphost for another scam/DDoS). And I see such systems everyday. And that dramas, when I ask a simple question like: "how it will be upgraded"? "What is your plan about dealing with manually-installed python modules that overwrites files from system-installed ones when system upgrade will be performed?" and so on, and so on...

Fortunately a separate "devops" team that really cares about infrastructure reliability usually evolves into a normal sysadmins in no-time and their priorities are usually different that rest of "dev-teams".

changes increase instability and unpredicatability in environments. and the people keeping them running 24/7 are usually the ones getting paged when shit hits the fan.

Long-term maintanability is especially hard, and the lower you get in the OSI model, the more painstakingly it becomes to replace things without major impact.

It does, but to be honest, when I studied computer science "not coding" was a big deal.

There were many people who simply didn't like to do it for whatever reason, and those weren't "theory people". There were meetups on how to structure your studies so you would get your degree with at least code to write as possible, and most of those people focused on getting jobs in operations later.

For some of them DevOps was cool, because it finally allowed them to learn to code in an area they were interested in, but for others it meant their low-code jobs transformed to developer jobs over time, which they didn't like at all.

I was intimidated when I learned but that was a little bit because my first language book was COBOL and I didn’t even have a working compiler.

The “good” sysadmins I learned from were all able to code, in fact many of them used to be developers themselves.

A good friend of mine suffers dyslexia and dyscalcula, and was just never able to jump past the standard unix shell scripting skillset, not for lack of trying. His understanding of Unix internals, TCP/IP, DNS and TQM-oriented process development is mind-blowing.

He just retired from a successful, 30 year career architecting and implementing secure messaging systems for several large banks. If you bank with Wells Fargo, Bank of America or Wachovia then you've probably communicated with your bank through systems he built.

And not just because of the language features, but also because of the community around it.

JavaScript isn't pretty, but it has a big community.

The Rust community today might be more helpful than the C/C++ community back in the days, so learning Rust might still be easier than an easier language.

I started with C and Java which I both didn't like much, but learning to code was a big wish for me as long as I know computers exist, so I worked through the problems.

Absolutely, i call myself adaptable Administrator ;)