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 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.
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.
It's also a rare problem, so not really a reason to screw over biodiversity in general.
We don't ban restaurants just because sometimes someone gets food poisoning. We just take action when a specific restaurant isn't able or willing to follow food safety rules.
I recently moved into a new home with a lawn that seems to have been semi-recently laid. I want to add some daisy's as I think they're pretty in a lawn. I didn't think of clover though, so wanted to ask, how prolific is it? The grass is taking some work to get thickened up, so I don't want to make it harder to keep some grass, but clover would probably help it get there.
And shirt + jumper combination outfits, where the "shirt" is just the collar stitched in. Drives me nuts when you see a nice jumper that comes with a "shirt" only to realise you'd need to unpick it to at least get one of them.
Coding speed really is a horrible metric. I can code really quickly, but it doesn't mean I'm doing anything productive or correct.
I'd rather slower coding speed, properly written as it provides higher overall velocity. And velocity should take into account the refactoring that happens months or even years later. Crappy code can look really fancy, and even be bug free, but if it's overengineered and hard to change, it can create long change times or even a full stop in development later in the products lifecycle.
And that's on top of developers losing the understanding of how something actually works. If AI helps create the code that would have been written without AI, then great, but I don't observe that happening, and the code has never been a better idea than then dev could have done without it.
I've been the person working stupidly long hours for many years. Eventually I stopped doing it, and I started to set boundaries around my downtime, and I found out something really valuable: Nobody noticed a difference in my productivity. I was doing far less, but nobody noticed. They all assumed I was still as busy, and doing as much, and it's because the things we all do to be super busy and productive ARN'T productive. You might ship some things faster, but the quality suffers, changes are harder to make later and everyone's tired all the time.
So no, "working hard" won't get you ahead. The people who really get that far ahead in life are the ones networking and learning the political games, not really working. And why do you need to "get ahead" to be successful? I'm ambitious, and I love growing in my career. I'm not someone who is happy with the bog standard things, but I've also learned that when all you value is being ahead of your peers, you miss out on more than you gain. And on top of it, you all end up in similar roles anyway.
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.