Discussion
It's tempting to think that slowing down helps. The reality is that it doesn't. Slow releases are even buggier. Shipping fast and iterating matters, but what matters even more is a collective effort to help devs find and reproduce bugs. It is very time consuming on all sides, but I don't think any opensource project succeeds without this collective effort. 🐛🐛🐛
So, if you're testing minded and have the time, you can help your fav projects succeed in a big way. If they don't interact with you in a way you like, or you can't seem to work with them (or find them), then by all means pick a different project to support.. But do try to support them if you can. I know nostr makes it difficult as we can barely see each others notes but, gotta keep trying. 🌊
I'm one of the few bug-reporters on Nostr, but I've got to disagree with you on the first point.
These people aren't fast because they're agile. They're fast because everything they ship is alpha and they skip refactoring and maintenance.
There's no way to test quality into something poorly-conceived and sloppily-executed. I've nearly given up reporting anything because either they don't fix it (because HOW?) or their fix breaks something else because they don't have tests to protect against regression.
Agile projects tend to be a bit slower, at the very beginning, because they focus on DevOps and architecture. It's the product iterations that are fast. A good agile team can release every week with confidence, or even continuously, if they have the chain tight enough.
These people have no chain. Their website goes down or their app becomes unusable and they don't even notice.
I mean, just think about how non-existent monitoring a website must have, if it is down for days or weeks and just showing a 404 or an internal error, or it has an expired site certificate.
That means... They aren't even clicking on it, once per day, to see if it's still there. 🥴
I've been reporting this stuff, but it's outrageous.
Ok but even in these cases slowing down doesn't seem like it would help either 😂 I have a saying in Linux world, "pick a better upstream". When something upstream from you proves to be bad over and over, gotta ditch it. I mean those are the choices right? I agree with OP there are lots and lots of bugs. I just think slowness is an anti pattern. Because I've heard it a lot in dev world, seen it tried, and it just ends in the same misery but slower 🌊🐛
Michael is probably faster than a lot of these "fast hacker guys". He's trying to *very politely* explain that they should go learn to code. That would slow them down.
Like, if it's a website, people should see something other than "DatabaseClosedError: UpgradeError Not yet support for changing primary key" when they click on the link. 🤦♀️
Ultimately I agree with you. I have some weird tendency to test the living shit out of stuff I write. I think it's just many years of devops being on the receiving end of bugs. I even used to make company wide rules like no releases on Fridays and stuff like that.
Probably from an outside perspective it seems like I'm slow. But I don't like bugs and am very good at finding them after all these years of paratrooping other people's code and being tethered to a pager.
I don't know why more testing isn't done. I can always name off things that can help, recommend process or dev environment improvements, train eng teams how to read their own logs, but at the end of the day it's a life long mystery for me..
You're the only person who has ever paid me to test out their stuff. That's why I subscribed and am happy to pay you. 😅
Literally a core quality measure.
I think a lot of people don't get *why* I consider it a quality measure. It says
1) I expect my stuff to work.
2) I have bad feels when it doesn't work.
3) I know checking to make sure it works is also work.
4) People should be paid for their work.
5) Thank you for working for me.
I don't actually burn out of testing or reporting bugs. I spent 5 years doing that all day, every day.
I burn out on the attitude of the person I'm testing and reporting for.