Stoned, Seriously, Simply, Silent, Studious, Seasoned
Obstinate, Obscure, Orphaned, Obedient, Observant, Old
Leaning, Lies, Learning, Lemmings, Louts, Liars
Independent, Invoking, Instead of, Invent, Inhale, In
Developers, Disguise, Doubt, Desire, Donuts, Decline
Single Responsibility Principle
Things do one thing. The thing is up to interpretation, and sometimes it only shows up when you have multiple uses of a thing, but only a subset are shared. That subset becomes a new thing that your original thing makes use of.
Open Closed Principle
Open to Expansion, Close to Modification. Once you find the atomic nature of your thing, lock it down, but make it available to be extended and inherited. If you have to change it all the time, there's a good chance that it's a business rule or isn't following the other principles.
Liskov Substitution Principle (They bent This into SOLID)
It's turtles all the way down. If you have a function that takes a parameter of a specific type. Anything that inherits that type anywhere in its hierarchy should be able to satisfy the function by standing in as that original type.
Interface Segregation Principle
Don't be burdened by upstream garbage. Only force clients to implement shit they use. You're always welcome to define your own interfaces at the client level and map to the public ones. Also don't go crazy. I remember learning to use some ESRI products and I remembered the interface stew that greeted me. Maybe it was great design and I was naive and looking for simplicity, but at the time it seemed like they did it specifically to tie features to paid version levels.
Dependency Inversion Principle
Depend on a representation of a thing, not on the implementation of a thing. That thing you need is a placeholder for any type of thing that fills the same need, and maybe someone will find a much better way to thing, and then you can use that.