While working and learning I noticed a peculiarity in discussions, tutorials, and general advice. A strange focus on the the tools instead of the problem at hand is usually there. This is mostly because people, myself included, like to use what we already know and are familiar with. This goes for programming language, development methodology, and other tools.
Though there is nothing wrong with relying on the tools you know, an over-reliance in never great to have. By fitting the problem to the tools there will come a point that the “solution” will not work, or work but is not adaptable. Simply by changing the problem for our tools to work we can create countless more problems for ourselves. Even more so because sometimes we do not even solve the problem at hand.
Beware that this issue is not only limited to direct tools such as a programming language or design software. Realize that most. As an example. in the last few years there has been an increased focus on Test Driven Development (TDD) as THE method for developing software. While TDD is great and has many advantages, some have become dogmatic in its use and forget that it is a tool, not a natural law. There are cases where TDD will not work as well, such as biological research where coding is only used for the analysis.
So while we can use TDD everywhere for software development, it is not always the best solution. For a quick biological analysis it will generate a lot of bloat and unnecessary specifications (entire framework pipeline) that will not be used, looked at, and be relevant for the developers and users. To re-iterate again, this is not only TDD, or programming languages. This dogmatic focus can be placed on any tool. Try to find the ones that work for the problem, and learn them to solve it.
With any real world problem there are without doubt multiple ways to solve it. So in the end, does it really matter that we focus more on the tools than the problem? Likely not, but I do believe it is good to keep in mind that tools are simply tools. If warranted, we can fit the problem as close as possible to our own skills and tools without truly distorting our problem at hand. Otherwise, we just have to learn more tools to solve our problems, which should already be part of the job.