Don’t be an X Developer

It’s very common that developers refer to themselves as being an X Developer or Programmer, where X usually is a specific programming language, such as Java, Ruby or Javascript or an architectural area, such as Frontend, Backend or Database. It can even be specific to a certain vendor or a product. Examples of this is EpiServer, Sharepoint or Salesforce. Some developers like to include their preferred programming paradigm in their professional title. But the only example I’ve seen is Functional Programmer. For some reason Object-Oriented or Procedural Programmer is less common.

So why do people do this?

I think there are three main reasons. First of all those titles are used to emphasize their area of expertise. The title states that their not just any developer, but they are specialized in a certain technology area. The second reason is that it indicates that the person belongs to a community. Together with the reason above, this serves as an identity. “I’m not just any developer, I’m a Ruby Developer.” Implicitly, this also indicates what they are not. Since they are Ruby Developers they don’t care about or even despise other languages, like Java. The third reason is that this is commonly used in job ads and by recruiters. I think that is problematic, but recruiting is a big topic that I don’t want to get into here. Maybe that will be a topic for another blog post.

Why is this a bad thing?

Most importantly, it imposes unnecessary limitations on people’s learning. It gives you the false impression that you don’t have to care about what’s happening outside of your area of expertise. Instead of being curious of why people get excited about Elixir or React, the Java Developer is patiently waiting for the long-awaited wonders of Java 9. Another issue is that it’s an obstacle for collaboration. In most organizations, developers need to cooperate to build a complete product. The users don’t care if the backend is a beautiful peace of art, if the overall experience is terrible. Everyone on the team that builds the product need to help out to make the best possible product. If, for instance, the backend developers have no interest in trying to understand what the frontend people are doing, that will make it less likely that the team will build a successful product. Don’t get me wrong, I’m not at all against specialization. But I think most developers benefit from having what is usually called a T-shaped competence profile, where you have a speciality but also have knowledge in many other areas. Remember that technologies come and go. Most of today’s mainstream languages and platforms will not disappear anytime soon, but it might be that in a couple of years the technology you specialized in will not be a popular choice for greenfield projects. Nothing wrong with working with legacy systems, but you really don’t want to identify yourself with technology that is slowly dying. If you stay as an X developer, there is a risk that you will become an ex-developer.