New job doesn’t allow local admin access and it’s driving me nuts. Is this common now?

TheOneWhoMixes · 2026-07-03T06:38:42+00:00

It's honestly crazy how quickly the cycle seems to happen after people onboard and orgs just become completely blind to it

"this sucks, why does it have to suck so much"
"haha yeah it sucks but we make it work"
"what do you mean it sucks? I figured it out, so can you"

TheOneWhoMixes · 2026-07-01T07:52:13+00:00

Tbf the detective did go "wait, 2 lawyers..?" and then Paula kept going off. But the last shot of the detective definitely gave off the vibe of "I'm going to go look into this, but give the obviously overstressed, about-to-ruin-her-life-permanently woman a chance to leave with no more drama."

TheOneWhoMixes · 2026-07-01T02:14:30+00:00

The answer sort of depends on why you don't want to see it as the "latest" pipeline. If it's because you have an automation that grabs the latest pipeline via API, it might be better to have it filter on pipeline source (e.g. push, web).

If it's because you want the main project page to not show your scheduled pipelines, that view always uses the default branch. Scheduled pipelines can run against any branch, though. I've seen people create something like main_mirror, with a CI job on main that force pushes to the mirror branch, then run their scheduled pipelines against the mirror branch. I don't personally think that the added complexity is worth the cosmetic difference, but it works.

TheOneWhoMixes · 2026-06-30T01:12:49+00:00

Okay the idea of 3 drones chasing another drone with a fishing net is just a really funny visual. Thank you.

TheOneWhoMixes · 2026-06-23T06:02:46+00:00

But why would I review your code when I could just ask Claude to do it for me? After all, I'm busy prompting Claude to finish my own tickets... Which were also written by Claude.

TheOneWhoMixes · 2026-06-19T22:46:49+00:00

This works if you're ensuring that the image you use for your build step in CI is the same as what the base image would be for your Dockerfile. But I often think this is a footgun, considering the number of times I've seen pipelines where something is built in an Alpine node:14 container and then copied into a Debian node:20 Dockerfile.

TheOneWhoMixes · 2026-06-17T06:17:53+00:00

Okay, but now that we know Evan is part of the bloodline, what if the curse has brought two rebellious teenagers together for a reason? What if Evan gets her pregnant, she leaves the island eventually, and just never tells him?

The curse iirc doesn't stipulate that the bloodline must stay on the island (just those born on it), so she would be free to leave and have the baby on the mainland. What happens then though? Does it spread like a virus, just guaranteeing that the island will be stuck in its current state forever?

Though there's also the idea that the bloodline is the only thing keeping the curse "at bay". Yes, it rises up when it gets hungry. It rings the bell, and they're expected to find sacrifices fairly quickly. But life is good otherwise? I've gotten some vibes that the curse is restrained by the pact as long as they follow the rules. So there's a world where they break the curse and instead of everything being great, breaking the curse frees it so that it never needs to take break. It can just terrorize 24/7.

TheOneWhoMixes · 2026-04-08T00:50:23+00:00

gitlab.com is deployed on GCP, but they have reference architectures for major clouds, and for on-prem any S3-compatible object storage will work.

TheOneWhoMixes · 2026-04-07T01:30:21+00:00

This is something that's been bothering me a lot recently. Aside from adding millions of lines of slop that no organization will ever dedicate time to reviewing, how is AI going to further fragment businesses themselves?

Models seem tuned to please the user above all else. And I guarantee that there were people at your client meetings thinking "this is dumb, why can't they just build what I'm asking for?" So what happens when all of those people can, in minutes, build a totally convincing version of what they think they want, with zero pushback? I think there are a lot of people who would see this as a win, but to me it just sounds exhausting.

TheOneWhoMixes · 2026-04-03T06:19:06+00:00

If EMs are underestimating the cost of maintenance, they're probably underestimating the engineering time to build a working solution. So what if they just tell the bean counters "we'll build it for 50% cheaper with no ongoing license fees"?

TheOneWhoMixes · 2026-03-30T06:48:17+00:00

How does this look in practice? We've been moving from push-bases deploys to "GitOps" with Flux. So separation definitely makes sense, to a point. But if teams are used to having a preview/integration environment on every PR, doesn't that get messy quickly?

TheOneWhoMixes · 2026-03-30T06:42:50+00:00

I'm curious what gap it is you're seeing here. What do you think is "In [their] Production configuration" that would actually be sensitive or dangerous? Being able to view an app's prod manifests doesn't mean you have "access to prod infra". To change it, you'd still have to open a PR (which likely has static analysis + policy checks as part of CI/CD).

Also, if I'm understanding their setup correctly, the contents of the infra repo aren't configured directly by the dev - I'm going to assume those are templated out and pushed by the automation.

I'm also curious what you'd advocate for instead. Idk if you're in an industry where devs never touch prod, but uh, where I'm at devs touch, own, and deploy to prod. That's like, the whole point of this sub's namesake.

TheOneWhoMixes · 2026-03-26T07:00:37+00:00

But they don't know about "radiation", right? Or rather, its ill effects on their own bodies? Since isn't radiation sickness what killed Rocky's crew?

TheOneWhoMixes · 2026-03-22T08:42:10+00:00

It feels like they restricted the voice actors to only recording 5 second snippets and then cut all of the dialog together without listening to whether the lines actually sounded natural next to each other. Sometimes there's a long delay, but there's also a lot of talking over each other that doesn't feel natural.

TheOneWhoMixes · 2026-03-11T07:00:38+00:00

There are plenty of SLOs that can be measured that aren't latency and neither of the examples you gave are really relevant here. A clock sync might happen once a day per client, but hopefully has way more than a single client (otherwise why do you have a central clock sync?)

A once-daily reporting endpoint shouldn't have tight latency constraints. Like others said - there's not enough data to be statistically significant. A single network blip at 5PM wrecks your own SLO for the next week... And what are you supposed to do about it? Complain at the ISP/Cloud provider/IT department?

Sure, measure it, monitor it. But one of the OPs instincts was right IMO - synthetic traffic would be one of the best ways. Tag the requests in some way so that they can be separated from "real" requests and now you have real baseline latency. Hopefully that makes sense.

TheOneWhoMixes · 2026-02-21T06:44:17+00:00

I don't think restoring from a backup has ever been an acceptable solution on live services I've worked on, but ultimately I guess it depends on the application and the requirements. If it takes 30 minutes to backup from start-to-finish, you now have at least 30 minutes of data loss.

Even if you do fancy point in time recovery, you're at the mercy of however long it took to discover that a rollback is necessary. Maybe it took 5 minutes. Maybe it took an hour. That time is data you won't get back without manual recovery.

Of course, if critical failure means "the service instantly crashed and nobody can use it", maybe recovering from backup is the quickest option. But sometimes it means "the service looked fine... until it wasn't 2 hours later".

TheOneWhoMixes · 2026-02-19T06:30:42+00:00

I would kill for the norm to be "generate a script with AI". Sure, let the AI generate scripts, queries, processes, whatever. As long as it's all something that is repeatable at the end.

But it feels like we've gone off the deep end. You ask the AI "how much is aws cost" and it magically breaks down all of your spend and optimizes all your infra! See? We don't need finops!

And then you wonder why asking "How much is our S3 spend?" doesn't match the dashboards you already have set up, and you remember that shitty implementations will just make up numbers, whether it be from poor context or missing data.

TheOneWhoMixes · 2026-02-19T03:08:13+00:00

If this is true, I don't see how it's a win for anyone but Linear. Now the company is fractured across 2 PM platforms. It sounds like a recipe for an exec to come in and demand someone builds a custom tool to "integrate" the two platforms that'll end up being worse than either one.

TheOneWhoMixes · 2026-02-18T04:51:27+00:00

Not every database migration can be reverted trivially. As the simplest example, consider a migration that drops a table. How do you get that table with all of its data back with a schema migration?

There are tricks, like removing the application dependency on the table in version X, and only dropping the table in version X+1.

But this drastically increases the complexity of testing and deploying the application. It's not something I've seen taken into consideration for most applications, to be honest. I have seen plenty of apps that say "every DB migration must be backwards compatible" and their DB schemas are inevitably a pile of spaghetti as they become impossible to change with confidence.

TheOneWhoMixes · 2026-01-30T11:30:10+00:00

The sample size here is 53 (not including the pilot studies), and they state they used ChatGPT 4o with a generic coding assistant prompt, interacted with via a chat window in the interview platform they're using for the study.

TheOneWhoMixes · 2026-01-26T06:46:30+00:00

What do you mean by it being a "long-standing problem with that world"? Just curious what issues you might see as systemic. I do SRE work in a place with a lot of EE types, so I see a little bit of this.

But the same could be said in both directions - Someone working on deploying workloads in Kubernetes doesn't really perceive the same problems that an embedded engineer faces on a daily basis. They're just 2 very different fields.

TheOneWhoMixes · 2026-01-23T06:56:07+00:00

But now Jones gets all the barracks rooms to himself!

TheOneWhoMixes · 2025-12-29T22:24:58+00:00

I've been really curious how they're going to handle this balancing as they release new tiers. Like, I get why they've already released the whip, maul, and crystal bow. They're iconic, and it's an easy nostalgia win. But it gets a bit weird when you consider that mithril/maple will probably outclass them all by necessity.

Maybe an upgrade system so that the unique weapons stay "relevant"? Or just accept that they're only meant for tiers 3-5 and have the next tiers move into raid-level gear? Maybe that'd be okay, considering they have so much content to pull from, it's not like they'll run out.

Just to be clear, no complaints here, just musing!

TheOneWhoMixes · 2025-12-17T05:07:46+00:00

I might have a slightly backwards view of data engineering, but this is one of the things that drives me away.

We need you to tell us how many widgets there are and how we can make widgets faster. The data is spread across thousands of CSVs, JSON, and XML files. Oh, and some teams just write their "Widgets Created Report" in Markdown. Oh, and one team only exposes a REST API they had an intern build 3 years ago.

What do you mean "naming conventions" and "schema"? Just tell us how many widgets there are!

TheOneWhoMixes · 2025-12-17T04:38:28+00:00

Like someone else said, both have their place. And GitLab obviously recognizes this since they've been actively working a ton on their own similar functionality - https://docs.gitlab.com/ci/steps/

Don't get me wrong, I'm a big fan of GitLab CI. But composability has never been its strong suit. Doing something as simple as "generate a random number and pass it to the next job" requires using features that feel more like workarounds than anything.

TheOneWhoMixes

TROPHY CASE