This is an amazing summary of good advice for software projects! I literally pasted it into my notes for reference. You should write a blog or something on this topic if you don't already.

Thanks for the very kind words. No blog yet. The closest thing to a blog was that I was writing a book, "Racket Tactical Field Manual" (RTFM), which would teach a programming language (Racket) and effective software engineering practices incidentally using Racket tooling, in one tractable, self-contained book (and beg Randall Munroe to do the cover illustration)... But then it looked like Racket was determined not to have commercial uptake, so I abandoned it.

I suppose, if I had a software engineering blog that was fortunate to be well-received, maybe I wouldn't get 90%+ interviews wanting to give me a LeetCode frat hazing. We could instead speak like colleagues, who can see that the other person has, say, written a bunch of open source code, and skip ahead to getting a feel for more important factors about how we might work together. Instead, the signal I get is that they really, really want to do the frat hazing. (Like the AI company I just got off a successful recruiter screen with, minutes ago.)