I come across a lot of blog posts and hear a lot of conversations where someone says, “don’t be dogmatic about that”. I’m sure you’ve heard it: “Don’t be dogmatic about TDD” or “don’t be dogmatic about SOLID” or “don’t be dogmatic about KISS” or “don’t be dogmatic about patterns” or “don’t be dogmatic about Functional Programming” or “don’t be dogmatic about YAGNI”.

On first blush it seems like good advice. Of course! Don’t follow something dogmatically! Try it out, see if it works for you, and discard it if it doesn’t. But I’m starting to change my tune.

In almost all cases this seems to boil down to the author/conversationalist being unfamiliar with the practice to which they’re asking you not to be dogmatic about. Maybe they tried it, didn’t quite get it, and then wrote it off as not worth it. From that point on they saw anyone who followed the practice as being dogmatic. But the thing is, if you aren’t somewhat dogmatic about it, how do you learn something new? We have a tendency to think about things in terms of what we already know. It takes a lot of work to undo that. You see this a lot with programmers when they try to pick up a new programming language; they try it out, don’t see what it can do that their favorite language can’t already do, and write it off. This is understandable. We think about problems in terms of the languages we are familiar with. It’s the same with human languages.

I say, give it a shot. If you find value in simplicity but aren’t quite sure how to do it, then really strive for it. Build your modules maybe simpler than is necessary for the system (I know, that sounds kind of oxymoronic). If the SOLID principles seem like a good lighthouse, then follow one or two of them to a T. Sure you might end up doing some unnecessary work but you’ll be learning. You’ll eventually get to a point where it makes sense why our industry has adopted a practice and why countless books have been written on the topic. And best of all, you’ll learn when it makes sense to apply the skill and when it doesn’t belong, instead of applying or not-applying it across the board.

But here’s the thing. Don’t be so dogmatic that you insist others do it as well. This is your journey. Choose which skills and practices you’d like to hone and go after it. Maybe it’ll seem so valuable that you will want to share that with others. When that time comes, show them the value. Show them how to make software faster, cleaner, and with fewer bugs. It won’t take long before someone asks how you do it.