This #FounderTalk guest post was written by Jonathan Zazove. Jonathan is currently CTO and a unicorn at EndlessTV in New York City. He was previously the founder of Papervitamins and is a Managing Director at FounderDating.
I often go to Meetups. I go to Meetups that cater exclusively to developers by only covering technical topics. These are often fun because developers tend to be smart and creative. I usually leave learning something new, but I also leave puzzled. Why don’t people talk more about the non-developer roles that they take on during the day? Isn’t that the harder part of our jobs? Why are some developers even criticized for doing non-developer roles? Is there even such a thing as a pure engineering role anymore?
My career as a developer started as a combined role of “front-end AND back-end AND designer AND sysadmin AND QA AND marketer AND customer service” – let’s call it a unicorn. I wrote SQL statements with my left hand and configured a (surprisingly lightweight) Cisco ISDN router with the other. I literally wheeled around a cart of six PC towers that each had a different permutation of Windows and Internet Explorer for testing website layout (yep, HTML tables). I wrote, designed, coded, and sent HTML emails (FWIW, this is still hard) to our customers. I did everything because I had to. I did everything because I had no additional resources or support.
This problem turned out to be an excellent career opportunity because it allowed me to understand the context of each role on a team. I became a better developer by doing non-developer roles.
As a designer, I needed to be consistent and deliberate. In order to write code like a designer, I relied heavily on abstracting templates and CSS. This forced me to have a front-end structure that had hard rules. As a result, I have found that back-end engineers appreciated not having to think about how to apply the rules.
As a salesman, I needed to be nimble enough to add features quickly. In order to write code like a salesman, I would write current features with a future pipeline understanding. This forced me to see what my future code would look like. It also allowed me to never fall in love with my code – something forever to be avoided in a transient programmer world.
As a help desk analyst, I needed to learn how to articulate the features so that they were clear to a wider audience. In order to write code like a help desk analyst, I was constantly working to push complexity away from the end user. As a result, I became more vigilant about handling dialog and error messages alongside the core business logic.
In short, these perspectives have made (and continue to make) me a better coder. These are the intangibles that are harder to learn than algorithms. These are the techniques not readily available in books. These are the skills we should be sharing because programming is growing up fast. These are the skills that let you speak the language of your whole team.
So learn to be a designer, a receptionist, a salesman, a help desk analyst, a mailroom employee, or any other role on your team. By being more empathetic to non-developer roles, you will begin to write code as an entrepreneur. If you’re a developer that expects business and marketing to speak your language, then you should speak their language as well. It’s easy, you’re a developer and good at learning languages.
Want to Connect with Jonathan or other awesome developers becoming entrepreneurs? Join FounderDating today.