SOLID

 This week, we read a very straight-forward chapter by Edward Guiness of the book Ace the Programming Interview: 160 Questions and Answers for Success. It very quickly explains the SOLID principles, which are widely-known principles applied to object-oriented programming that have to do with minimizing dependencies between classes. I won't explain what each principle consists of (since it's very easy to find), but I will share my general thoughts about them. 

I still remember when I first started university, my code consisted of one very long python file that you could very easily read from top to bottom; the concept of functions was still foreign to me, and when we started using them, we would split up all of our code into two or three functions and that was that. Since then, we've been introduced to many different ways to make code cleaner and easier to read, and one that's been repeated often is the Single Responsibility Principle, which I agree is very useful in order to make code more maintainable. 

While working, more often than not (especially in my current role) I come across code for a project that I don't own and just have to make some changes to. I've had to learn to follow the Open/Closed principle (and to a lesser extent the Liskov Substitution) so that I don't break anything and receive angry pings from the team that actually owns the project. 

I don't have much experience with the other two principles (Interface Segregation and Dependency Inversion), as outside of school, I haven't come across the need of using interfaces (or perhaps I just haven't noticed when they could've been useful), but I can definitely see how they could be useful whenever I actually work with them. 

As the author mentions, it's also important to note that these rules aren't always set in stone, and they can also be open to a little interpretation, so it's good to use common sense (and know, from experience, when it's right to ignore them), but I think we can all agree that they serve as good guidelines for software engineers as a whole, and it's in our best interest that more people learn about them, as that translates into easier work for us down the line, when you have to stare down a project you've never seen before and have to tread carefully if you don't want to break anything.