scaryclam

I really wish people would tell me what the dependencies are and NOT just ram everything into a container image so I have to reverse engineer what's required to just run the damn thing on the stuff I am ALREADY running.

Just tell me what the entry point is and what the dependencies are for it so I can decide if I already have enough to just sort it out myself.

By all means, create a kitchen sink container image as well, but don't have that be the ONLY artifact for running it.

I do this as well, but there is a workflow problem to solve and that is: getting PRs merged when they need to be to continue working.

It's not a simple problem to solve, we can't all just jump because someone finished some work after all. But if the PRs are OK to rubber stamp, and merge, and they're safely behind a feature flag, then it could just be as simple as letting the submitter merge without the need for an extra review. That can of course be contentious, but then we can ask "why not?" and figure out what non-human gateways need to be added to help make it possible etc.

I'm finding myself increasingly interested in understanding what friction can be removed from the software review, merge and release process, without sacrificing safe, well tested, understandable code that follows good standards.

The question is, why are you not just merging them into main as you go? It's a bit of a smell when you "need" to merge branches into branches. It shows a lack of safety and ease in deployments, which is the real problem to solve IMO.

I mean, unless you work at an organisation that deals with a specific religion, I would say that they're all NSFW, as there's no reason to be using them at work, and they're bound to cause controvosy at some point.

Given the level of NSFW material in some of them (sex, violence, etc), I think it's not surprising they're getting labelled as such, even without the link to a religion.

It really depends on the decision, what was done, and the overall impact. If the decision is to migrate to microservices, a year in it may be reviewed and decided that the work has been far more than anticipated, and is too much for EVERYTHING to be migrated, and the decision changed.

Or it might be an architectural decision to change the hierarchy of some organisational structure. Again, it could be the correct call for the time, but as things evolve over a year, it may not be sufficiant a year later.

A year isn't a bad time to review, and if the decision is just a "yeah, duh, of course we'll continue", then it's a really quick conversation, but at least you're thinking about things.

As another data point, I run a k8s cluster on Hetzner (mainly for my own experience, as I'd rather learn on my pet projects vs production), and haven't had any Hetzner related issues with it.

So Hetzner is OK for the overly complex as well, if you wish to do so.

You don't need AI if that's all you're using it for. In fact, IDEs have been doing a fine job at that for years.

It feels right now, that much of the time, AI is a solution looking for a problem to solve.

I find it more useful to treat AI like an easier to search stack overflow. You can ask it to go find you an answer, and then elaborate when it's not the right one.

Or one or two devs in the F100 customers made an account using their work email so they could chuck some OSS prototype code somewhere, or test something out.

You should report sites that do that. We still enforce the GDPR, and it's illegal to force acceptance of cookies (excepting functional cookies) for any reason, including offering to remove them for money.

The kinds of messages that get sent via email or text are usually pretty unimportant. Important things tend to be sent via letter or a phone call.

It's not likely to be anything critical.

The EU isn't even a continent. It's a trade/political block, making up a part of a continent. And the part of the EU pushing back is generally just the European Parliament, not the whole organisation.

Some segregation is useful. If a key I use for work never touches my personal machine, that's a good thing. If my work laptop gets stolen I don't want to have to cycle my personal key, etc.

I guess the point I'm making is more for making decent keys to create sensible separation points, rather than having one for each machine though. Allowing work vs home vs foo vs bar

And if you work at a place as an employee that has made a situation where you ARN'T disposable, you should either try and change that or leave.

If there's a single point of failure like that, the company is being mismanaged. NOBODY leaving, getting sick, taking a holiday or even dying, should leave the rest of the company at risk.

Companies should most certainly value employees and treat us with respect, but they should also be setup to allow for employees not being around forever.

> Also, bored people are typically boring people.

This is such a bad sentiment. Being bored is fine and a normal part of existance, it doesn't make a person boring. There are LOTS of reasons to get bored and we don't all need to feel stimulated all of the time. Being bored can push people to do something new, being bored can just be down to having to watch Cars with your kid for the 1000th time because they want to watch it with you and you don't always put your own self first. Being bored can also be due to burnout, trying to chase all the shiney new stuff to make yourself feel interesting.

For those of us who don't use windows regularly enough to remember the tool names, this is wonderful to know about.