Strong opinions about not important things, this is what developers community likes. Tabs vs spaces, React vs Angular, JS vs TS, Python vs PHP, OOP vs FP. These are just examples, we like to say our technology stack is better, our solution is a silver bullet, yes... but it's simply not true.
My code is better than yours, but what means better code? Isn't it a subjective statement? If you rewrite 'for loop' into 'reduce' only because you feel sick looking on any loop, it only means your goal has nothing to do with your project goal. All these articles which start with - "Never use x" or "Don't use y". What is the point? Point is to show how my opinion is better than somebody else's. Are there any proofs? No, only examples made to show the difference in a specific light, the one which works for the author. There is no reason to point somebody that he has used 'else' instead of 'early return', there is no point in fixing code which has switch instead of fancy using object keys. If you think your code is perfect, you didn't grow up.
I am an observer of people who try to show the rest of the programming community that FP is a better paradigm than any other, and everything else is just not worth trying. Most programs working in the wild and maintaining our society and industry were written in an imperative style of programming. You say imperative code is wrong, you didn't grow up.
Note. I am not saying FP is wrong, I am saying FP is not ideal, and is not a silver bullet.
How common is to repeat that OOP is wrong, object orientation failed, you should never do OOP. Very, very popular opinion among so called FP programmers. The problem with this statement is that many people who say that, even don't exactly know how looks OOP and how to write object oriented code. They say classes and inheritance, strange and complicated patterns. And as I agree that you can very easily write wrong OOP by overusing tools, you can also make maintainable and readable code by separating your domain into objects with own responsibilities and state. Yes you can write good soft in object oriented paradigm. It is fully fair to prefer functional programming, but blaming OOP for all programming sins is a proof that you didn't grow up.
No difference is with static vs dynamic typing. One say - I don't need static types, there are no benefits of having it. Other say - dynamic type systems have one type, and are so error prone that you cannot do anything with them. I personally prefer languages with static type level, but I see the tradeoff, static type languages in order to achieve comparable expressiveness need to create very sophisticated ways of making polymorphism (for example Haskell typeclasses). Example of something which probably cannot be expressed in nowadays static typed languages are - transducers. Also there is quite a visible benefit of dynamic type languages in writing fast, small programs, they allow for rapid development. On the other hand static type languages give tools for code maintenance without a fear. You say - static types are useless - you didn’t grow up. You say there is no place for dynamic languages - you didn’t grow up either.
👻 speculative execution 🔪@sliminalityAs someone who strongly prefers static types, I can't believe I am saying this but I don't love the trend of dunking on dynamically typed languages as "merely" unityped/badly statically typed. Dynamism has its own rich history, including contributions to static typing.05:06 AM - 17 Oct 2020
New project, lets force my rules. Very common is to see senior developers who enter the project and instead of understanding current codebase and current code decisions, like to say - let's rewrite it, or - everything is wrong because you don't use library x. As critical thinking is beneficial, rejection thinking is poisoning. If you want to rewrite somebody else code, only because you don't want to understand it, you didn't grow up.
Every technology has flaws, has pros and cons. Some languages, libraries will work better for us in specific circumstances. Very often a better choice will be using libraries, languages which we already know. And it is ok. If your native language is let's say Polish, even though Polish is a very hard language, it is easier for you to describe some things in Polish than in English. But even though you can do that, it doesn't inherently mean Polish is in general better in describing these things, it only means the tradeoff is positive in this situation. If you choose Node.js for your server, only because you have a team of JS developers, it is ok, but don't fool others that you have picked Node.js because it is the best server side technology. If you say that the language you use is ideal - you didn’t grow up.
PHP is not a programming language. Why is PHP not programming when Python is? The difference is really syntax only, the same algorithms can be expressed in both. We can say objectively Python was better designed and has nicer syntax, but it doesn't make PHP not a programming language. If you say PHP is not programming - you didn't grow up.
Frontend is not programming. This is a far less common opinion than it was some time ago. But I remember times, when BE developers were proud to be "real programmers". If you think so, you didn't grow up.
Not knowing something is fully ok, it is totally fine that you are not expert in everything. It is better to say simply "I don't know" instead of stating some nonsense and pretending you know what you are talking about. Even though you are experienced developer who is considered as senior from seniors, even then, you can say "I don't know". If you try to have opinion on things which you have no idea about, you didn't grow up.
Enough examples. Be critical, see pros and cons, understand your tools, don't believe in your tools. Languages differ from each other, but most are capable of doing the same things. Hating or loving is not what we should do, being a fanboy does not make you better in your job. Sitting ten years in one language either. Change languages, change domains, learn from other people, you are senior in JS, great but don't be afraid to work with Java as a junior dev, changes will make you a better programmer in general.
Code should be consistent, projects should have coding rules, and everybody should obey these rules. If we agree that we use FP concepts like maps and reduce, then let's use them, if we agree on specific code conventions, let's obey it, if we do unit tests, let’s do them, even though you don't feel the benefit. If rules are to be fixed, let's discuss that, let's propose, don’t force. Some of your team members can be not comfortable with things you are comfortable with, you need to help them, take them to your level. But also, maybe it is not the time for that, maybe you need to postpone your ideas.
Having no strong opinions doesn’t mean you don’t care about code quality or agree on bad solutions. You still see bad, good code, you still refactor bad code, you still try to push better solutions. What is different, is that your decisions are not based on the one framework you know, or what is currently trendy. But your decisions are based on your knowledge, on your experience, are not based on being a fanboy of solution X. You see tradeoffs, not silver bullets. If your decisions are based on experience, you are able to describe and explain them better, you are able to introduce your ideas and concepts without forcing them.
This post is written to myself from the past. Yes, I was a developer with strong opinions. I've needed a very long time to understand that such an attitude makes me weaker. I hope you will understand this faster than me. Also, as a last, take into consideration that some of your programming colleagues will never grow up.