I think many people misunderstand the purpose of code review. The purpose of code review is not for the reviewer to find bugs, and certainly not for them to ensure that the code is bug-free. Anyone who depends on code review to find bugs is living in a fool's paradise. As everyone should know by now, it is not in general possible to find bugs by examining the code.
The primary purpose of code review is to find code that will be _hard to maintain_. The reviewer looks at the code and tries to understand what it is doing and how. If they can't, that means it will be hard to maintain in the future, and should be fixed now, while the original author is still familiar with it.
plurality update re: cognitohazard? cognitoopportunity?
TwinRoot (basically, who we were for 2 days when the entire system merged and became a singlet) was brought out by our attempt to practice this. Yesterday they hosted, but they've decided to just be a steadying hand for the rest of us. Apparently they enjoy being other people more than themself?
A blog article I wrote up for my publisher on figuring out why my language development was different to other people.
#Autistic
@actuallyautistic
https://blog.jkp.com/2025/08/autistic-communication-not-as-simple-as-a-b-c/
autism (-)
Had a dream about society disabling me, only at the end I somehow was calm enough to start to explain: hey, I understand objectively this isn't a big deal but it's the result of a cascade of failures in navigating this whole system, which happens constantly because society isn't designed for me. you acted reasonably and it's not your fault but be aware that a lot of extra emotional weight from other events has been piled on top of this one thing for me @actuallyautistic
fedora: we make our bad decisions before any other distro, guaranteed
ubuntu: have you heard the good word of our lord and savior, snap?
debian: never change (derogatory)
arch: giving fedora a run for its money
gentoo: our systemd support is in the uncanny valley, but at least you have the tools to fix it [refuses to elaborate]
nixos: infinite recursion encountered while evaluating reductive quip
re: executive function rambling
@emerald The way I would make myself do that specific thing would be: stop, rest, cultivate love. Specifically love for my present and future self would get me moving. Which also means that it doesn't make much difference whether it's me or someone else that will experience the eventual benefits, i.e. "gratification" on any timeline doesn't play into it.
(Being able to generate love in that way took a lot of work though.)
stream announcement
Playing my own randomizer https://www.twitch.tv/madewokherd/
randomizers and bias, bad end
The naive algorithm is not as slow as I expected, in this case. I suspect that in other cases we'll have a problem.
So, I still have no good solution. I guess we go naive for now.
randomizers and bias, bad end (15/N)
Turns out I do not understand this as well as I thought. PlaceOrbsInLands in this example (even though that's not quite how I actually wrote it) has a probability of failure that's proportional to the ideal failure probability, for one step, but it's lower than that ideal. For it to be the same, we'd have to stop everything immediately after encountering any failure. But, if it is the same, we end up with an equivalent of trying every permutation.
randomizers and bias, bad end (15/N)
And now I have to rewrite my placement algorithm because I realized while writing this that I took some shortcuts that may not be valid.
randomizers and bias (14/N)
This is actually easy. The probability of stopping based on this specific orb that we placed should be 1/N * (probability of a valid combination based on having placed that orb). Well, the probability of PlaceOrbsInLands failing is equal to the second term in that multiplication, so we can treat this the same as an invalid pairing. It doesn't really matter that there might be some valid ones.
randomizers and bias (13/N)
OK, so what if an orb placement succeeds? We still have to place the rest of them. For that, we call PlaceOrbsInLands for our remaining set of lands and orbs. If it succeeds, great. We add the one pair placed in this step, and return the list.
If it fails, we need to decide whether to stop at this step. We want to do that in such a way that the overall probability of returning failure is proportional to the number of valid permutations given our input state.
randomizers and bias (12/N)
If we move on to trying a second orb after a failure, and that one also fails, we should return failure a total of 2/N of the time. But we already did the 1/N check, so at this stage we should return failure 1/(N-1) of the time, to increase the total probability to where we need it.
randomizers and bias (11/N)
So, for the induction step, we try to place 1 orb.
We have to first account for permutations that fail at that step: we should have an M/N probability of failing outright, where M is the number of invalid orbs for the first land, and N is the total remaining.
So, we can try the orbs in a random order. If the first one fails, we know M is at least one, and so we should randomly return failure 1/N of the time.