You could consider ‘partitioning’ your DB when you migrate your schema so each DB instance only deals with a single bitemporal slice eg after 5 migrations you have 5 distinct database instances. This approach avoids bloat assuming the vast majority of queries would be served by the most recent instance, while not precluding serving verbatim responses from earlier instances.
I wonder why so few people seem to think about persistent data structures (persistent in the functional sense, that is immutability -- copy-on-write). Basically we implemented a form of hash array based tries for https://sirix.io ... or it's just like how ZFS stores objects adding levels of indirect blocks/pages on demand with bitsets storing which indexes are really set to avoid having arrays with a lot of null references. For sure you have to copy the path to the root, just like snapshots work in ZFS or Btrfs, but I think that data is neglegable when you basically also do versioning on a per record-level/per revision level. At least thus we can restore each revision in the same time, you do not have to have a "history table", which is inefficient to query in contrast to the most recent revision table.
This is interesting, but I think there's an implicit assumption here that a particular topic must be covered in depth, at which point its study is completed, not to be returned to.
And indeed, this is way many textbooks are structured. But I see no reason for this to be the case. If topics are covered lightly via an exposition and then subsequently drilled into in depth, the order, and resulting motivation becomes almost a side note.
I say this as I'm currently studying linear algebra via Coursera, and the resource that has become most valuable to me is a Scapple board with a bunch of screenshots, text and arrows. It is this (non-linear) diagram that I return to most often to help internalize and solidify my learning.
In this regard, the order of exposition becomes almost incidental.
A few years ago, I recall being impressed at the clealiness of the toilets in Edinburgh train station. An attendant was diligently wiping each urinal with a cloth, and also used the same cloth to wipe the Dyson hand dryer.
I’m sure it’s not a common practice, but I’ve avoided them ever since.
I think you've already done the most important thing you could by creating a separate room that delineates home life from office life.
The biggest distraction I've found while working with a remote team is dealing with IM. In practice I've found this can be more distracting than low level banter in the office - you can tune out to this, and it's always obvious if a message is directed at you. Not so with group IM, where unread messages may or may not be directed at you. In short, and assuming your colleagues are happy with it, I recommend going 'Do not disturb' for a few hours every day while you focus on work without distraction.
When I was employed as a developer, I was quite obsessive about refactoring my code to the point where I considered it elegant.
Now I run my own company and am the sole developer. So these days I tend to think if my code is well factored, I'm doing it wrong.
It's not quite that simple of course. The lower down the stack a chunk of code lies - the more things that depend it - the more I want it well factored and well tested. But I'm quite comfortable with code high up the stack being scrappy, hacky and untested.
A contrasting approach - when Mo Ibrahim set up a mobile network in African counties he knew a no-bribe approach wouldn't fly, so bribes were limited $30,000.
