When I first started this chapter the intent was to convince developers to favor the mastery of patterns over frameworks. As I began to write this chapter and explain more about frameworks, I began to rethink my approach. The content naturally lent itself to teaching about how to use both of these tools in a toolbox versus persuading to avoid one of them altogether. Now my goal is to teach you how to use both of these concepts to your advantage and further develop your ability to be a competent engineer.
There will always be a new kid on the block when it comes to programming. Taking part in this career means understanding this reality and learning how to navigate it. When I first started writing code, C++ was the probably the most popular language in the world. Then out of nowhere a new contender named Java came to challenge the throne. Like many upstart programmers, a sense of panic started to make its way into my mind because I feared that learning another language would be a formidable challenge (especially since I barely new C++). After some time, more new languages started to gain traction and visibility. Staying current with the flood of new technology ushered in the sense of playing whack-a-mole! As soon as I felt like I caught up with what was currently happening, more things started to pop up! I’d love to tell you that the engineering world has come to its collective senses and everyone decided to just stick with one language but I can’t. Not only would this be untrue I would even go so far as to say that the problem has amplified itself! With the widespread adoption of open source collaboration and the ability to publish whatever you want to the internet (yes, this book included) there are new languages all the time, and there seem to be no signs of this trend slowing down.
Everything is about choosing the right tool for the job; choosing the right framework for the project/task. When buying into a framework, one has to acknowledge the impact it has on the codebase, the skills required to use it and the opportunity cost of having to remove it if (when!) that time comes. Remember to keep a keen eye on the larger picture.
What steps can we take to lessen the impact of the skills gap created by the technology? I say technology here because it can be the result of a new language, library or framework. First and foremost, the onus is on you as the champion of this change to come up with a roadmap for how the new technology will be used and how it will fit in with the team. Identify the problem it will solve and think critically. The fact that you are fond of the tool is not enough. Consider ways well to help your team members be successful during implementation time. This includes coming up with code samples, documentation and even a proof of concept using an existing problem your team faces. Be open to feedback and understand that this can be a sensitive process especially if there are people on your team that are resistant to change. Bringing in new technology to your team doesn’t have to be as challenging as passing a bill through Congress. Understanding your why helps to smooth out the process.
Though this chapter has focused heavily on languages, libraries, and frameworks it is certainly worth mentioning the role that patterns play in the grand picture. Software design patterns are long lasting, reoccurring parts of your learning and careers. If your team does not allow for adding a given technology to the process, it is always valuable to know the types of design patterns that you can put into practice to solve problems. Many times a library merely abstracts a design pattern and does the heavy lifting for you. While convenient this too can lead to trouble. What happens with the technology is malfunctioning? Having no understanding of the underlying foundation means that we won’t be able to do advanced debugging and problem-solving. Remember, libraries are written by developers just like us - humans.