I think this is a fun thing for TigerBeetle to do, but I'm pretty skeptical that this was a good engineering decision.

Ha, yeah, as an 8 year software engineering manager I'll agree that "fun" is not a good initial look for a new project, sadly — the best engineering decisions are boring far more often then not.

After years of insisting on picking boring options, I realized working like that was a buzz kill long term for my reports, I tried to relax and figure out how to have fun projects too. Give people with ideas space to run. My deal now is, the tighter the blast radius of the project you can give me, the more I'm ok with you going nuts.

Documentation is a great place for fun, low-blast-radius projects, so I totally get TB on this one!

Some other rules I give up front for project proposals. Hopefully the theme of blast radius control is charmingly obvious:

- No new languages. (I have had professional arguments over this)

- No fun projects that require ongoing labor/upkeep.

- No fun projects in stateful storage infrastructure. (I have had distressingly passionate professional arguments over this)

- No fun projects that involve new SaaS / hosting providers that can't be trivially cut loose or cost > $50-100/mo.

- Fun projects in generally persistent infrastructure need solid justification.

- Fun design system / UI infrastructure projects must be able to be gracefully incrementally adopted, or scoped tightly.