I suppose I could be called DevOps, and I've always seen that as part of the job - making the infrastructure as easy for the devs to work with as possible. They've got their own specialities to worry about; infrastructure shouldn't be one of them. I've heard the role called somewhat derogatorily "helpdesk for devs", but that is part of the job, and I embrace it. I also embrace "yaml wrangler" - it's not my favorite thing to do, but it does sometimes need wrangling. I suppose I've always seen the role as a generalist one who has some understanding of the overall system, and how to glue (or duct tape) it all together.

I've been called a Systems Wrangler before. It was pointed out to me that I love to wrestle with a new unfamiliar system, "taming" it to work with our stuff.

I think I prefer that to some other choice descriptors that have been applied to me! ;) "Git Whisperer" is another one that is amusing to me, considering the difference in meaning between "Wrangler" and "Whisperer". Does that mean Git requires a subtle approach?

Part of this work used to be called toolsmith, but it doesn't quite cover the job description.

devops and dx share the same spirit of reducing friction

at my job i can't stop leaning toward them because I can count in blood the amount of energy, time and money wasted on the thousands papercuts stacked over time

one needs to find a balance of fluidifying the daily logistics involved, it amps up joy and reduce stress.. leaves more time for problem solving and creativity.

sadly most devs / managers couldn't care less about that

I've a similar background, and have worked recently w/ a handful of teams with atrocious, self-imposed developer experience. I think that applying concepts like SLOs and error budgets to relevant developer-centric activities can really help focus the team and other stakeholders well before the experience passes some threshold of terrible.

This is practically a tenet for me now:

If you tolerate painful problems you are capable of fixing, you're a masochist. If you expect others to tolerate them, you're a sadist.

I often work with people who are more than happy to have someone fix problems. But I also work with people who don't just denigrate such work, but are obstructionist. You're expending energy to stop other people from making the system better. There's something deeply wrong with such people.

> You're expending energy to stop other people from making the system better. There's something deeply wrong with such people.

One explanation is emotional attachment to a system/technology/solution/process they helped put in place. If someone wants to improve it by heavily modifying or God forbid getting rid of it, they will fight back because they feel personally attacked for it. It is wrong, but it happens a lot.

I don't know if it would help or not to mention that the existing system helped to get the company to where it is today, when delivering the "now is the time to get rid of this" pitch.

Acknowledging how long the existing system has been live would hopefully be a reminder that you're not trying to erase their achievement.

It will help, but the receiving party has to be reasonable enough (or "emotionally mature" enough) to fully grasp it. It's usually not the case with people that go nuclear on these topics.

I haven't quite had 'nuclear' but I know what you two are talking about. "But we would have gone out of business 3 years ago if that weren't written!"

Yes. Three years ago. And it's not three years ago.

"What brought you here won't bring you there". As cheap psychology as it might sound, it's actually true most of the times.

> You're expending energy to stop other people from making the system better. There's something deeply wrong with such people.

Lurking somewhere inside everyone is a sublimated death wish.

In my experience workstation setup scripts can be a waste of time to implement and maintain in certain contexts; like everything it depends.

I completely agree. In my experience what, what works is:

1) Development containers. They're not for every situation, but if they suit your situation (prebuilt base images, private repo, long build times that can be split out into common layers, probably remote dev with a good IDE that natively supports them, i.e. a Jetbrains IDE), they're amazing. They completely remove the need for "works on my machine" as you deploy a multi stage built app from the same base container image.

2) Single "5 step" setup page. The setup guide should be: Install git/p4, install toolchain with versions, log in, clone, `make build`/`cmake --build` / `npm run dev`. Depending on what you work on, "run dependencies in a container" (database, grafana/prometheus, log agent) might be there too. Everyone who is onboarded follows these steps, and their first two tasks, in your teams issue tracker are "fix anything that didn't work in setup guide", and "make a PR", both of which should happen on day 1/2.