I’d go easy with the recommendation to couple components loosely. If you make things that belong together loosely coupled, you’ve created obfuscation, and added complexity to your codebase. Loose coupling makes sense, but not everywhere.
And it will “surely” be assisisting a genocide should Trump be elected. He never hid it or denied it.
Even if that was true, how is that better than having fascism today, given than genocide will happen no matter what? You seem to imply people will have more willingness to resist if it happens tomorrow (and I doubt it). But are you really willing to take the chance on actual fascism? It really seems like you want it to happen…
You guys have a twisted sense of priorities. You’re willing to trade a maybe for a surely.
It really seems like my options are Fascist Now Party or Fascist Later Party. If the Democrats don’t listen when I vote and don’t listen when I abstain, why should I vote?
The answer is in your question. Fascism later is the better option because it buys you time to do something else. Fascism now means the game is over today. Nothing about that is difficult to understand.
You’ll have ample time (and freedom) to oppose Harris after November, but now’s not the time.
Language variety in India is huge. I wouldn’t take bets 😁
I just shat bricks realizing this.
I know how it works, thank you 😚
I like how you’re making excuses for something that it is very clear in context. I thought AI was great at picking up context?
Beware folks, Ai WiLl TaKE yEr JoOOoObS
If higher-ups complain about intempestive code refactoring, it’s always a good idea to stop for a moment and to start becoming less trigger-happy with refactors. It’s OK to take some time to determine what actual value refactors bring to the project in tangible terms - intuition is not enough. Convincing a critical manager is a good start, because their tolerance for programmer bullshit is low if they don’t actually write code.
Very often, and this is especially prevalent among junior programmers who care about what they do, the reasoning for refactoring turns out to be something along the lines of “I don’t like this” or “I read some cool blog article saying things should be done that way”, without any care about whether or not the change in question is actually improving anything, or, if it does, if the improvement is worth the degradation in terms of quality (new bugs)/maintainability (added genericity making the code more difficult to understand, cryptic features of the language being used that make it hard to understand what’s going on, I’m sure there’s other examples…)
The problem is you often get in cases where the developer cannot back their intuition that something is actually harmful with facts. When it’s not just pure bikeshedding about code they don’t like and falsely claim to be a ticking timebomb, they fail to weigh the risks of leaving slightly offputting code in the codebase against the risks associated with significant code changes in general, which, even with tests, will still inevitably break.
Developers of all sorts tend to vastly overestimate how dangerous a piece of code may be.
To be clear, while I’ve seen it with other developers, I’m still guilty of this myself to this day. I’m not saying I’m any better than anybody.
It’s just that I’ve seen how disruptive refactoring can be, and, while it is often necessary, I thought it would be important to mention that I think it should be done with care.
If you can convince a manager with rational arguments in terms of product quality, it can be a good way to make the case for a refactor, because your manager probably won’t be impressed by arguments about unimportant nuances we developers obsess about.
The answer is… It depends. Stealing food or diapers because you or your child are starving is based. Stealing someone’s car… Not so much.
I legit had no clue what a Fumo plushie was 😵💫
I hear Sam Metaman is actually a pretty chill dude, compared to his cousins.
The day of reckoning is approaching fast. May this teach a lesson to my fellow techies that tech billionaires aren’t any better than the other billionaires. I hope there won’t be another cryptoscam after LLMs 🤷♀️
Or, if there’s another one, I hope that it won’t consume massive amounts of energy. If techbros only hurt themselves, I suppose it’s fine.
Nobody talked about banning them, once again. I don’t want to do that. I want it to leave the mainstream, for environmental reasons first and foremost.
The fuckup is, IDK, the false impression of productivity, and the 41% more bugs? That seems like a huge deal to me, even though I’d like to see this study being reproduced to draw real conclusions.
This, with strawberrries, Air Canada’s chatbots, the 3 Miles Island stuff, the delaying of Google’s carbon neutrality efforts, the cursed Google results telling you to add glue to your pizza, the distrust of the general public about anything with an AI label on it, to mention just a few examples… It’s starting to become a lot.
Even if you omit the ethical aspects of cooking the planet for a toy, the technology is wildly unsound. You seem to think it can get better, and I can respect that. But I’m very skeptical, and there’s a lot of people with the same opinion, even in tech.
I’m talking about people criticizing LLMs. I’m not a politician. But I’ve seen a few debates about LLMs on this platform, enough to know about the common complaints against ShitGPT. I’ve never seen anyone on this platform seriously arguing for a ban. We all know it’s stupid and that it will be ineffective, just like crackdowns on VPNs in authoritarian countries.
The reminder is the tech itself. It’s yet another tech pushed by techbros to save the world that fails to deliver and is costing the rest of the planet dearly in the form of ludicrous energy consumption.
And by activism, I mean stuff happening on Lemmy as well as outside (coworkers, friends, technical people at conferences/meetups). Like it or not, the consensus among techies in my big canadian city is that, while the tech sure is interesting, it’s regarded with a lot of mistrust.
You can take LLMs seriously if you’d like. But the proofs that the tech is unsound for software engineering keep piling up. I’m fine with your skepticism. But I think the future will look bleaker and bleaker as times goes by. Not a week goes by without its lot of AI fuckups being reported in the press. This article is one of many examples.
You can bury your head under the sand all you want. Meanwhile, the arguments proving the tech “flimsy af” will keep piling up.
Not my experience. I’ve had the displeasure of having to use Rider at work, and it’s much slower than VSCode, if only for boot times which are a pain in the butt for large projects. You gotta pay for that bloat and feature creep somehow.
And that’s on a Xeon machine.
As for refactoring, yes, Rider has lots of options that don’t work and do half the job. So much so, that I don’t use them at all, because they’re unreliable.
The requirement for Copilot to qualify an IDE is a bit funny. First, VSCode has some support for it, and, secondly, this is super recent, so unless IDEs didn’t exist since last year, I’d say this is not core to the definition of IDE.