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.

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.

...to age restricted consumers, and in many European countries, with health warnings about over-consumption of alcohol

I didn't know I could use it on MacOS. I recently started a new job where they have nothing but Mac, so I've been looking for a text editor that can do what Kate does. Everything seems to want to do 101 things before basic text editing, rather than just be a simple text editor with optional functionality, so I'm really excited to have Kate installed. I'm really hoping I don't run into too many issues as I've used Kate for years on my home & work setups and would really like to continue using it on mac now.

I often see people making what could be very simple terraform setups into incompehensible monolithic monsters as well.

I tend to preach separating things out and keeping things small. Why do you need a huge TF project to manage 15 services and have weird conditional parts when you can have 15 smaller projects that can deviate from a boilerplate template where it's sensible? I get that running "terraform apply" in one place makes the ops team's life easier, but the mess it creates in the actual TF isn't worthwhile IMO. And god forbid you use TF for your infrastructure and deploy using something that works more appropriately.

> Say it with me: Elevate Permissions

I always tell my team that we should be able to build and deploy from our laptops. That we should make sure we don't bake our build/deployment into third party systems, so we're still able to do things when they have outages and can move to a different one if they become unreasonably priced etc.

But that we SHOULDN'T be doing those builds/deploys from our laptops UNLESS it's an emergency. Almost no dev needs a key for the whole production infrastructure sitting on their laptop, they don't need a production DB superuser. They should know how to get access to things when needed, but embrace the safety of not being able to accidently kill something important.

I love having the power to destroy a whole companies offering at my fingertips, but the terror of running a command and realising you're doing it by accident is just not worth it.

Though, I have seen on more than one occasion someone promoted again and again after reaching their level of incompetance. This seems to be more driven by the incompetance of the person/people doing the promoting to cover their tracks though. They can't be seen as incompetant themselves, so they move the original incompetant employee up the ladder again, but to the side so they're less able to cause problems, but still look good.

This. If my bank contacts me I want it to be legitimate and honest. If I started getting phishing attempts I'd start ignoring my banks contact attempts completely. So when someone skims my card, makes some purchases and they try to ask me about it, I'll ignore them. Not good.

Same for here in the UK. My iron suppliments are 30mg, which seems pretty usual here.

Number one would be: tying your deployment to the cloud providers way of doing things. ECS, CodeDeploy, heroku.... it's easy to get stuck when your ops requirements grow beyond how they do things, and really hard to set up something more agnostic alongside it (especially when you have a tight budget on cloud resources).

Number two: using tech that you really don't need. Keep it simple, even if it means not using something that the rest of the industry is in love with. Figure out what your requirements are, pick the simplest way of setting it up (keeping #1 in account, because using tooling that isn't able to grow with you is worse IMO), and keep it agnostic. Then when you start to hit the edges of the capabilities, either scale up your ops understanding and start using more sophisticated things, or hire someone in to help out.

Also, I really do agree with @KaiserPro when they say to separate your infra from your deploy. It makes moving to something else much, MUCH easier when you inevitably need to.

This is more like:

- Doctor, it hurts when I hit my head on the wall

- Then don't hit your head on the wall

You have solutions available, use them