I want to preface this post by saying it is not directed at anyone, but is rather a reflection on some interactions I have had both at work and in the open source community in past months.

In my current role at LinkedIn, I interact with a lot of developers; on an average day, I work with a dozen or more different individuals discussing software engineering in some capacity. So, you can imagine that I encounter a lot of differing opinions about how we should be building our web applications.

One of the most contentious, opinion-driven topics in the past year centered on whether we should have taken the plunge in using Ember.js as our framework of choice.

Among the many talented JavaScript developers I work with, there are (unsuprisingly) some that greatly dislike Ember and some that really enjoy it, with most failing somewhere in the middle. I have heard valid reasons from all sides at this point and have my own opinions on the matter, but this post isn’t about that.

This post is about building applications with Ember (or any framework/library/language) and how I don’t really care if you like Ember.

Let me explain, when it comes to building an application with a given tech stack, your opinion on the tech stack should not influence the quality of your work. Put more plainly, if you have to build an app with Ember, you better learn to be good with Ember.

Even if you prefer React or Polymer or think all frameworks are superfluous, if you are going to be getting paid to build an application with a certain technology, then you should be competent and skilled in that technology (or at least strive to be).

This isn’t a chastisement so much as it is a critique of a mindset I often see amongst developers: If I don’t like X, then I shouldn’t be an expert in X.

To this I respond by saying:

Agreeability should not dictate your expertise in a given tool for your trade.

I think this extends beyond the world of software engineering, but software engineering is my forte. So, as software engineers, it is our job to be expert problem-solvers and to deliver the best possible solution to those problems within the constraints we are given. If one of those constraints is that you must use a piece of technology that you don’t particularly agree with, you still better be able to understand how to use it properly.

I find that because I understand Ember and am skilled in constructing Ember applications, that most developers assume I like Ember. The reality, however, is that whether or not I like Ember is irrelevant to my skill in using it.

If we decided tomorrow that we were throwing out our application and will be constructing a React application in its place, I would be annoyed for sure, but I would then set about making sure I became an expert in React, because that is how we will be successful.

All of this to say, you can disagree with the opinions of a tool while still understanding how to use it effectively.