I was inspired by a great article from one of my former classmates and now a very honored colleague of mine which brought an interesting point of view about switching between different technologies. Well, I think the same, but I want to expand this idea. And it's pretty important to point out that switching between different technologies has brought a huge misunderstanding inside the job position of Software Engineers.
I know, it's 2019 and 2020 is pretty close, you can be anyone. But can you be anyone? I am a very huge fan of not switching your technology at all, but, for some reason we can argue about what we can exchange.
First of all let's clarify what I mean with different technologies. I am not talking about the use case of switching from Android with Java/Kotlin to Android with Xamarin, or Android with Flutter or React Native. Or, when you want to build a cute front-end app with Angular and argue if switching to React or Vue could be a good choice. No, I'm talking about the cases where you leave your front-end career to pursue a career in Ruby on Rails or something. So, I am stating that we should not switch between technologies which solve different business problems.
It is important to state not to misjudge any of the software engineer choice because no one knows the reason for his/her switch.
There could be a pretty good reason for my thesis. Since microservices are gaining strong advantage over monolithic applications and also the monolithic front-end paradigm has already been broken migrating to micro front-ends, can you enter the software engineering market without at least mastering one? My definitive answer is no, but I can bring a lot of facts about it. By not mastering at least one of the technologies, you can't do serious business with your employer, and your scopes will remain unexpanded.
Perhaps entrepreneurs don't care about the quality of the software, they care about the quality of the product. The difference between a very good quality product and a very good quality software is all about the architecture. The perfect product doesn't crash, does what it is supposed to do and it sells, brings money. The perfect software has nothing to do with the perfect product.
If employers don't care about the software, who will? If we don't care about the software architecture, we are not working, we are just producing code. On the other side if we do care about the software, we really want to think and plan more than writing code in terms of time.
And suddenly, in my own humble opinion this does imply that by carrying about the software, we directly care about the technology we are working on and the business problem we are solving. What I mean by carrying is to know in details the kind of problem each stack solves and the architecture and design patterns it is built on.
To sum up, it is already a fact that every single business problem has a variety of ways and a variety of technologies that can be used to solve it, but this does not mean we should solve another problem, just because the salary could be better, or how friendly the environment is. Furthermore, if you really care about the software , the problem you want to solve, and the product you want to show to your boss/client, stay in the technology which actually you are better at. If one of the frameworks solves more than one business problem, ignore it. It's not the software engineers way.