Consider a donation to help people providing you the open source software you seem to depend upon.
Usage of a helper tool to perform tasks on code whether it is AI or the IDE internal features can reduce the work load of benevolent developers who has not asked you to use their softwares.
Maybe the language was not appropriate but get real. With the little revenue generated by the usage of people complaining, the use of AI agentic coding might be the only way to being features without pushing benevolent devs to burnout.
Railcar8095@lemmy.world 2 months ago
Test in production is the best. We spent months warning from data bugs and nobody bat an eye (upstream bug, not our responsibility but we noticed) When it was d launched in prod we just pointed out the bug that nobody fixed was still there and immediately a war room was formed and the bug fixed within an hour.
It honestly seems more efficient to let shit hit the fan than to fight everybody to do their job.
x00z@lemmy.world 2 months ago
You’re implying a shitty capitalist company that nobody cares for if it burns down. A tool like this though that is self-hosted by a lot of people (29.1k stars on GH!) and that is internet-facing is very different.
Railcar8095@lemmy.world 2 months ago
Then, let’s just call it “massive decentralized surprise testing”
MirrorGiraffe@piefed.social 2 months ago
For sure, the song of the hero who fixed the production bug is oft sang at meetings but the loser who prevented the bug to begin with gets no credit.
hornedfiend@piefed.social 2 months ago
Testing in production is the most idiotic last 10 years or so concept, which is mainly driven by incompetence of project managers.
Imagine if you get sold a car by a company, for 100k, then it start having major issues and the car company tell you: “we’ll fix it”.
While that does not necessarily apply to software or services or webapps, the logic still stands. You are selling bugs to people. Bugs that could have been cought, with some risk management and planning.
Railcar8095@lemmy.world 2 months ago
I completely agree. I work on an internal solution, which is a part of a very large product. It’s not a live product, only part of a pipeline that runs on a predetermined schedule. Our bit is the only one with actual business/performance KPIs, most of the other teams measure only “user story/CR points”. If the other teams screw up, it will impact our performance unless we prove it’s their fault. And of it’s their fault, they open a US/bug which improves their metrics (one more US closed). Our team has to think ahead and try to do things well in one go, because our bugfixing doesn’t count as work. But our speed is measured against people who benefits from half doing stuff. When we did massive effort, we got complaints we were slow. Now we do less effort and once every blue moon we have to do a hotfix. Most often than not when we have an production issue is due to the other teams that run before us on the pipeline, so we even had to develop checks to our input because they won’t add checks to their outputs. And they won’t because that’s a CR that requires extra funding that’s not approved, but we had to create them for our own sanity.
Yes, I’m looking to move out haha
hornedfiend@piefed.social 2 months ago
A project is as good as its weakest point. While people might get butthurt by getting pointed at, a project is a group effort. Segregated teams are always a problem and almost always becomes a vulnerability,
Given current micro services architectures, we all have to get along with each other,for the greater good and the interest of the customer.
You sell shit, you get shit back. You sell high quality products with less obvious faults, you profit in the long run.
But no: “Let’s test in production”…