I want to reprogram the way I think about the state of my data models.
Think of a blog post. Before I publish it, it's unpublished. After I publish it, it's published. If I unpublish it, it's unpublished again. Maybe I edit it and republish it. Published again.
I (and a lot of programmers, I think) tend to think of a thing like a blog post as having a state. Maybe in the MySQL database, blog posts are in a
posts table having a
status column. It's an
ENUM type, probably.
But state is really just whatever the most recent change represents. Like git -- state is like
HEAD. And too often, I don't think about saving the history of states when I should.
So, resolved: consider whether any new data model having a state or status should instead (or also) have a history.