108. How Do I Know If I Am Overusing a Principle?

How do I know when I am overdoing a given principle? Principles like SOLID, DRY, and TDD are useful, but can I overdo them? When is it too much of a good thing? These are the questions we are going to answer in today's episode of Dev Questions.

[mitchellvaughn]

Almost all of what I know has been self taught or accumulated over the years helping maintain a fairly simple in-house application at the company I work for. This is a question I wish I had asked myself years ago. I think many of these principles were 'rules' in my head for a long time and honestly ended up making me more frustrated than anything. Instead of understanding WHY things are done I think I would essentially just focus on HOW they were done, and that can quickly turn into a convoluted corner. Even though dev isn't my main job and probably never will be I can't tell you how much I've learned from your videos. My understanding of the actual concepts has grown exponentially. Thank you, sincerely, you do great work.

[dasfahrer]

Thanks for this. I've shared this video with some of my colleagues that are heavily dogmatic about a number of principles.

[daniell]

I find myself over-using DI when all I need is just a static class that does the same. Are there any general rules when it comes to determining whether to use DI, static class, or instantiating a new class in a constructor?
Thank you for all the great contents.

[VeaceslavBARBARII]

Man I love. I meet my deadline in part because of you. 🥂

[WiDuAlK]

Hello Tim, can you make a video about how to read and understand correctly a documentation(especially microsoft documentation)

[davidardo]

Teacher math is important to software engineer?

[BrianHinkley]

I don't know if self commenting code is a principle. If it isn't the next person to follow me is going to hate me.

[krccmsitp]

Audio and Video are out of sync, I'm afraid.