In the early stages of my career in software development, I picked up a set of ironclad rules that seemed undeniable to me:
- Object-oriented programming wasn’t merely a paradigm; it was the only way to craft quality software.
- Methods longer than 20 lines were an affront to clean code.
- Writing tests before code was not just a good practice; it was gospel.
- Repeated lines of code are a form of technical debt.
- Design patterns must be used, or your code will be unmaintainable.
These, along with others, weren’t just guidelines to me. Rather, they were commandments all software developers must follow, and anyone who didn’t was committing heresy. But, as I gained more experience, the foundation of these rules began to crumble. Exposure to differing ideas revealed a stark truth: these “undeniable facts” were dogmatic beliefs.
Falling into the trap of dogmatism is a common tale in our field. My desire to do the “Right Thing™” had blinded me, leading me to think there is only one solution to multifaceted problems. As I was gradually exposed to differing viewpoints, I realized these weren’t rules that should never be broken but tools and patterns to be applied when necessary.
Despite this, I believe there was something to be learned from strictly following these rules. This phase of my career served as a learning experience for how to engage deeply with software development practices while evaluating their pros and cons. Because of this, I believe being intentionally dogmatic can be a boon for anyone’s career.
Defining Intentional Dogmatism
Intentional dogma, in the context of software development, is the practice of deliberately adopting a set of principles or methodologies for a limited time. It’s not about sticking to these practices because someone said so; it’s about really understanding their benefits and limitations.
For instance, by immersing myself in Test-Driven Development (TDD), I’ve gained a better feel for where it is important to write tests, and where writing tests doesn’t provide much value. I also understand the safety that tests provide as well as the overhead that too many tests can introduce to a project.
By being intentional, we not only uncover the practicalities of these methodologies in real-world scenarios but also learn to balance their ideals with the pragmatic needs of building software.
Benefits of Intentional Dogma
Here are some of the key benefits of intentional dogma:
Deep Understanding
Delving into a practice like TDD provides an understanding you can’t get from just reading about it. For example, by using TDD in my projects, I’ve learned not just its strengths, but also where it might not work best. Hands-on experience shows you the limits of what you’re learning. This deeper understanding helps you know when to stick with what you’ve learned and when it might be better to try something different.
More Tools
Diving deep into a practice is like unlocking a new set of tools. Each practice you explore adds more tools to your collection. It’s not just about learning one way to do things; it’s about having options. For example, understanding of the pros and cons of both functional and object-oriented programming helps you know where one is useful, where another is not, or where you should use a blend of the two.
This variety of tools means you can pick the best one for the job. Whether it’s choosing the right programming paradigm or deciding on the best testing strategy, having a diverse set of tools at your disposal makes it easier to address the gamut of problems we have to solve.
Better Communication
Understanding a practice deeply means you can explain it in simple terms. When you know why something is done, not just that it’s done, you can share those reasons more clearly. This is much better than saying, “Because that’s the way you do things,” without really knowing why.
For example, with a thorough understanding of design patterns, you can explain the benefits of using them. Conversely, you can explain why using a design pattern might not fit a specific context.
How To Be Intentionally Dogmatic
Applying this requires a nuanced approach, allowing personal growth while not interfering with the collaborative nature of software development. Here are a few key ways to apply intentional dogma.
Side Projects
One of the best ways to explore and apply intentional dogma is through your own projects. Here, you’re free to experiment with different practices, understand their implications, and observe their outcomes without constraints.
Selective Application in Team Projects
When working with a team, it’s crucial to adapt your approach to fit the team’s established practices. Instead of imposing your chosen methodologies on others, look for ways to practice them without impacting others. For example, Introducing FP concepts like currying to a team unfamiliar with them might not be well-received. However, incorporating side-effect-free code will probably not be met with contempt.
Dogma and Problem-Solving
Being intentionally dogmatic opens up a world of deeper understanding and more effective problem-solving. This method moves us beyond theory and into the practical application of various practices. With this, we’re equipped to enhance our own skills and contribute more meaningfully to our projects and teams.