833 karma · joined August 26, 2010
Do enough of these kinds of things and not only will you connect with those you serve, but also with those serving others out of love. These are good people to be connected to, especially since you'll become more like them over time.
People can obviously make the opposite choice, but I'd encourage anyone that's never been around good little kids as an adult, to find a way to be around them in a helpful or fun role for a while. Volunteer at a youth group, sports camp, coding class, whatever. Or just be an "uncle" to some of your friends' kids. My volunteering at a church youth group in my early 20's probably gave me the nudge I needed.
Community isn't the default that everyone's forced into anymore, but if you are intentional about it, you'll find lots of other people are feeling the same way and are happy to join in.
Maybe it's:
- the terrible educational state of the school system?
- the fact that device and social media addiction is a prevalent and growing problem that they don't want their kids brains rotted by?
- they want to provide their kids an education based on experiential and project based learning rather than filling out worksheets?
- they don't want their kids to be forced to wait for the slowest / least interested kids in class to catch up before moving on to more challenging material?Something that would give me a button I could press to de-bullshit a site, not one that tries it on every single site maybe?
I'd suggest you check out Tom Holland's "Dominion" if you'd like a well-researched and nuanced take on the effect of (Judeo-Christian) religion on Western civilization.
That said, it reminded me of a funny collider meme I saw recently:
That said, Antithesis doesn't require you to write manual tests, integration or otherwise. It requires your software system to be packaged in containers, which is fairly straightforward, and then requires a workload to be written which will emulate the normal functioning of the software system. So for example an e-commerce store would have product views, cart adds, checkouts, etc.
With this, Antithesis can start testing (running your workload, varying inputs, injecting faults, etc) the software and looking for violations of test properties. There are many (60+) test properties that come "out of the box" such as crashes, out of memory, etc. You can (and should) also define custom properties that are unique to your system, as this will surface more problems.
As your tests run, violations of test properties are reported, with lots of useful debug information included. Test runs that are particularly interesting can have a lot of extra analysis done, due to our ability to "rewind" and change inputs, get artifacts, add logging, etc.
https://antithesis.com/product/how_is_antithesis_different/
Here's the relevant text though:
Antithesis testing resembles chaos testing, in that it injects faults to trigger and identify problems. But Antithesis runs these tests in a fully deterministic simulated environment, rather than in production. This means Antithesis testing never risks real-world downtime. This in turn allows for much more aggressive fault injection, which finds more bugs, and finds them faster. Antithesis can also test new builds before they roll out to production, meaning you find the bugs before your customer does.
Finally, Antithesis can perfectly reproduce any problem it finds, enabling quick debugging. While chaos testing can discover problems in production, it is then unable to replicate them, because the real world is not deterministic.
I became friends with Dave our CTO when I was 5 or 6, we were neighbors. He'd already started coding little games in Basic (this was 1985). Later in our friendship, like when I was maybe 10, I asked him if he could help me learn to code, which he did. After a week or two I had made some progress but compared what I could do to what he was doing and figured "I guess I just started too late, what's the point?".
I found out later that most people didn't start coding till late HS or college! It worked out though - I'm programmer adjacent and have taken care of the business side of our projects through the years :)
https://antithesis.com/docs/introduction/how_antithesis_work...
In short though, unit tests can help to inform a workload, but we don't require them. We autonomously explore software system execution paths by introducing different inputs, faults, etc., which discovers behaviors that may have been unforeseen by anyone writing unit tests.
Aphyr / Jepsen never tested FDB because, as he tweeted "their testing appears to be waaaay more rigorous than mine." We actually put a screen cap of that tweet in the blog post linked here.
We got to a point where the default was that all of our 10,000's of test runs each night would flash green if no new code was introduced. Tests that flashed red were almost always due to recent code additions, and therefore easily identified and fixed. It let our team develop knowing that any bugs they introduced would be quickly caught, and this translated to being able to confidently take on crazy new projects - like re-writing our transaction processing system post-launch and getting a 10x speed increase out of it.
In the end our focus on quality led to velocity - they weren't mutually exclusive at all. We don't think this is an isolated phenomenon, which led us to our newest project - but that's a story for another time.
The problem was that the maintenance revenue was valued at a much higher multiple by investors than their Perpetual Licensing revenue because it was recurring. Cue the thought... "What if the whole thing was recurring?"..."Hmm how could we justify that?"..."We make it a SERVICE that WE host!"... and then here we are now where if you want to actually own software, chances are you're out of luck.