In what way were the developers expected to "master" k8/helm? In the sense of actually making contributions to the k8/helm setup, or simply using an existing k8/helm setup to provide a development environment? Was there any "expert" person on the team that everyone could ask about k8, or was everyone simply supposed to pick things up on their own?
(asking because my own team is currently moving in this direction, and I'm curious about the pedagogical challenges we might face)
Ima be facetious here and suggest that the above is meant in the sense that K8 is the ultimate leaky abstraction and you have to "master" it first before even starting starting to achieve anything with it.
And Helm is just closing the cycle of Samsara - if you really want to base your operations on string templating, just use bash lol. Or hand-written forms on paper, still faster and you still get a better idea of what's going on.
There's also the problem of many developers nowadays just not having the hacker mindset/actual high-level abstract thinking/attention span, so instead of seeing the whole of K8S as the pointless kludge it is, they only see the interface - yay, YAML, I know that language! (usually they know it from everyone's favourite "dead" tool, docker-compose; which is a gem) - and they go on to fight with it tooth and nail, with corresponding feelings of "achievement" and "mastery".
I think the "10 years PHP/Java -> 3 days Go" thing from granduncle's cousin post is meant to point out this particular paradoxical situations.
But it could hurt people's feels to say it like that so let's just let Google do all our thinking for us instead. We truly live in a gilded age of computing.
Anyone who is either insecure about their own skills, or so proud of their skills in their area that they can't face being a beginner in another area, will struggle and come up with reasons not to learn it. And they'll tell their nontechnical colleagues or managers that the idea is overengineered, or they'd add more value elsewhere, until it happens or they leave.
(asking because my own team is currently moving in this direction, and I'm curious about the pedagogical challenges we might face)