Don’t call me that.

If you’ve ever tried to argue your point in a debate on either politics or religion, you’ll understand what I mean when I say you’d make more progress talking to a brick wall with a sore throat and a cloth stuffed in your mouth. Paul Graham wrote an insightful article in which he explains why these conversations yield such uniquely useless discussions.

I think what religion and politics have in common is that they become part of people’s identity, and people can never have a fruitful argument about something that’s part of their identity.

This identity bias is not specific to certain topics, though. Paul goes on to explain why;

Which topics engage people’s identity depends on the people, not the topic. For example, a discussion about a battle that included citizens of one or more of the countries involved would probably degenerate into a political argument. But a discussion today about a battle that took place in the Bronze Age probably wouldn’t. No one would know what side to be on. So it’s not politics that’s the source of the trouble, but identity.

You see, when you let topics become part of who you are, those topics begin to define you as a person and you can become blind to reason. When someone challenges a topic that’s part of your identity, you take it personally. Your initial reaction is to fight back and defend your identity, rather than listen to what they have to say.

I read Paul’s article a few years back, but just recently, it got me thinking about the ongoing debate about the roles of designers and developers and who should be doing what. Everyone seems so eager to cling to an identity. UX designers, visual designers, motion designers, ruby developers etc. The list seems to be getting longer by the month. Each time a designer masters a new skill, they add it to their tagline like a trophy on a mantlepiece. So, instead of a UX/UI designer, now you’re a UX/UI/Visual designer. I understand it helps to give others some insight into what you do and recruiters must narrow the field somehow but why put yourself in a box? Why assume an identity that limits your productivity? If you’re someone who designs products but can’t build them, that doesn’t make you a “designer” as opposed to a “developer”. It just means you’re less competent at building products than someone who can both design and code.

To make things worse, certain skills are being applied to these identities, as if assuming a certain role forbids you from performing any of the other tasks necessary to build a product. UX designers should do research and draw wireframes. Visual designers should choose typefaces and draw illustrations. Front-end developers should write HTML, CSS and Javascript. Ruby developers shouldn’t. Who makes up these rules?

Drew Wilson is a good example of someone who doesn’t place unnecessary boundaries on his work. Despite his freakish ability to launch a new product every other week, I’ve been most impressed by his reluctance to call himself either a designer or a developer. Instead, he describes himself simply as someone who makes stuff.

Most discussions I’ve read on topics like unicorn designers or whether or not designers should code have been fruitless. I believe the reason for this is that too many people are personally identifying with particular roles and the skills that traditionally go along with those roles. They’ve let these meaningless terms define them as people. So, when someone comes along and shakes things up, they are incapable of approaching the topic objectively. They can’t think outside the box.

David Cole wrote about the benefits of designers learning to code and how so called “developers” and “designers” will one day meet in the middle.

Designers will become more like programmers as programming becomes more like design.

I think he’s right and for me, that day can’t arrive soon enough. I can’t help thinking though, that as the industry evolves, people who identify too strongly with these empty tags will be reluctant to evolve with it and may get left behind. So stop calling each other names and just go build products.