My friend works at a well-known tech company in San Francisco. He was reviewing his junior team member's pull request. When asked what a chunk of code did, the team member matter-of-factly replied "I don't know, chatgpt wrote that"
From the point of view of these sorts of developers they are being paid to make the tests go green or to make some button appear on a page that kindasorta does something in the vague direction of what was in the spec, and that's the end of their responsibility. Unused variables? Doesn't matter. Unreachable code blocks? Doesn't matter. Comments and naming that have nothing to do with the actual business case the code is supposed to be addressing? Doesn't matter.
I have spent a lot of time trying to mentor these sorts of devs and help them to understand why just doing the bare minimum isn't really a good investment in their own career not to mention it's disrespectful of their colleagues who now need to waste time puzzling through their nonsense and eventually (inevitably) fixing their bugs... Seems to get through about 20% of the time. Most of the rest of the time these folks just smile and nod and continue not caring, and companies can't afford the hassle of firing them, then you open LinkedIn years later and turns out somehow they've failed up to manager, architect or executive while you're still struggling along as a code peasant who happens to take pride in their work.
Sorry, got a little carried away. Anywho, the point is LLMs are just another tool for these folks. It's not new, it's just worse now because of the mixed messaging where executives are hyping the tech as a magical solution that will allow them to ship more features for less cost.
Copy / download some random piece of code, monkey around to change some values for your architecture and up we go. It works! We don't know how, we won't be able to debug it when the app goes down but that's not our problem.
And that's how you end up with bad examples or lack of exhaustive options in documentations, most tutorials being a rehash of some quickstart and people tell you "just use this helm chart or ansible recipe from some github repo to do what you want". What those things really install? Not documented. What can you configure? Check the code.
Coming from the dev world it feels like the infrastructure ecosystem still lives in a tribal knowledge model.
> people tell you "just use this helm chart or ansible recipe from some github repo to do what you want". What those things really install? Not documented. What can you configure? Check the code.
I mean, this is just wrong. Both Ansible roles and Helm charts have normalised documentations. Official Ansible modules include docs with all possible parameters, and concrete examples how they work together. Helm charts also come with a file which literally lists all possible options (values.yaml). And yes, checking the code is always a good idea when using third party code you don't trust. Which is it you're complaining about, that DevOps people don't understand the code they're running or that you have to read the code? It can't be both, surely.
> Coming from the dev world it feels like the infrastructure ecosystem still lives in a tribal knowledge model.
Rose tinted glasses, and bias. You seem to have worked only with good developer practices (or forgotten about the bad), and bad DevOps ones. Every developer fully understands React or the JS framework du jour they're using because it's cool? You've never seen some weird legacy code with no documentation?
Not really. I'm mainly in code maintenance so good practices are usually those the team I join can add to old legacy projects. Right now trying to modernize a web of 10-20 old add-hoc apps. But good practices are known to exist and widely shared even between dev ecosystems.
For everything ops and devops it looks like there are like islands of knowledge which are not shared at all. At least when coming with a newbie point of view. Like for example with telemetry: people who worked at Google or Meta all rave about the mythical tools they got to use in-house and how they cannot find anything equivalent outside... and yes when you check what is available "outside" it looks less powerful and all those solutions feel like the same. So you got the FAANG islands of tools and way to do things, the big box commercial offering and their armies of consultants and then the OpenSource and Freemium way of doing telemetry.
Very strongly disagree, if anything it's the opposite. Many people read the knowledge shared by others and jump to thinking it's suitable for them as well. Microservices and Kubernetes got adopted by everyone and their grandpa because big tech uses them, without any consideration if its suitable or not for each org.
> At least when coming with a newbie point of view. Like for example with telemetry: people who worked at Google or Meta all rave about the mythical tools they got to use in-house and how they cannot find anything equivalent outside... and yes when you check what is available "outside" it looks less powerful and all those solutions feel like the same. So you got the FAANG islands of tools and way to do things, the big box commercial offering and their armies of consultants and then the OpenSource and Freemium way of doing telemetry.
The latter two are converging with OpenTelemetry and Prometheus and related projects. Both ways are well documented, and there are a number of projects and vendors providing alternatives and various options. People can pick what works best for them (and it could very well be open source but hosted for you, cf. Grafana Cloud). I'm not sure how that's related to "islands of knowledge"... observability in general is one of the most widely discussed topics in the space.