Can you expand a little about how each of these parts of SOLID have influenced how you have written code? I feel like I've heard people say conflicting things to some degree on at least some of these (e.g.: single responsibility) and my own experience feels somewhat like following some of them to their natural conclusion can end up with code that is more complex and harder to maintain. Again, for example, the S seems to imply needing a larger number of classes that would have to be searched through to find a specific implementation or bug, and D feels like it would shove the code that actually does something down a layer and be harder to find. That could be my inexperience talking or just not knowing how to employ the ideas properly, though.
I guess a decent amount of what I'm feeling comes from my current job, which breaks a decent number of those rules. (S, O, I at least, possibly D but I don't think so) But despite that, code generally seems to be pretty easy to read through, so I'm a bit conflicted.
I find SOLID to be less reliable than applying ages old principles of contract-oriented programming. S is matter of taste, you can define it to be "show the whole GUI" or "show a text label in given position".
Depending upon abstractions directly is much less reliable than depending upon contract (which is usually not explicit in the abstraction) and preferably also verifying it as both preconditions and postconditions.
The other letters are important, though software should be designed for easy modification instead of being closed to it. Otherwise you end up with abstraction forests and deprecated code.
Many interfaces is typically a smell, as the developer now has to juggle multiple balls in his head. There is good medium ground out there - making the interface maximize usefulness while not sacrificing too much of Liskov substitution capability is key.
I guess a decent amount of what I'm feeling comes from my current job, which breaks a decent number of those rules. (S, O, I at least, possibly D but I don't think so) But despite that, code generally seems to be pretty easy to read through, so I'm a bit conflicted.