It's basically doing step by step print lines for you. If you have easy access to a bash prompt here's an example (for clarity, the lines leading with $ are what I typed into the shell. The lines without are what is output'd):
$ set -x
$ echo `expr 10 + 20 `
++ expr 10 + 20
+ echo 30
30
$ set +x
$ echo `expr 10 + 20 `
30
You see how the first example broke down what happened bit by bit and the + noted the depth of interpretation for the line? This basically helps debug narly scripts ... which if they're narly enough ... just rewrite them in a "proper" language.
What's that old google adage ( https://google.github.io/styleguide/shellguide.html )
If you are writing a script that is more than 100 lines long, or that uses non-straightforward control flow logic, you should rewrite it in a more structured language now.
From the article:
IMO, developers should be given enough enough to get themselves in trouble. However there's a team that owns and enables those processes.
I've always thought of it like a team who owns an API. That API team owns the api, but if another team wants to use said API, cool, here's some documentation for it (env configs, OAuth2.0 onboarding, distrolist, future features, etc.). Maybe, depending on the company, there's a little more "ceremony" around how much the new team will be using the API just from a load perspective. But overall a team is allowed to digest the API with some guidance.
IMO, this is what should be happening with DevOps/DevSecOps/Operations. They enable the developers to follow some general cookie cutter guidelines with the ability to request adjustments. However, the permutations in what a person can do in operations are so much higher than just a well defined API service.
In my own career, I've found that "ace in my back pocket" is being able to handle a lot of my team's DevOps and general automation of tasks. But when I've coached and mentored folks usually there's a somewhat clear split between the developers who are interested in learning DevOps and those who just want to stay feature-devs.