Yeah I can write code, but I can do other things too!
I want to begin this post by saying what I am about to write is completely subjective. I don’t intend to draw a hard line in the sand and that my idea is the absolute right idea for everyone. I know that everyone involved with the creation of technology has different interests and skills which lead them into different jobs and career paths. This post is really just a compilation of thoughts and ideas I’ve written down in forming my opinion and ideas regarding what I want my career path in technology and design to be, and hopefully it will help others figure theirs out too.
According to my business card I’m a ‘UX engineer’, or what most people would refer to as a front-end developer. Now I hear people quite frequently say that titles don’t matter and aren’t something that you should worry about, and for the most part I agree. However title’s aren’t meaningless; they are typically the first thing people use to form a perception about what you do and what you’re good at doing. And while I don’t necessarily care about titles themselves, I do care a lot about how people perceive me and what I do as a professional. Which is why I really, really don’t like it when someone refers to me as a ‘coder’, ‘programmer’ or even a ‘developer’. Beyond the obvious perception of programmers as socially awkward people who are very strong in technical disciplines like maths and sciences, but lacking ability in communication, empathy or big picture problem solving, the descriptor of ‘programmer’ or ‘coder’ is a title tied to a tool — code. So when ever people say “We need to hire a programmer”, often times what they are actually saying is “We need to hire someone to write code”.
Personally, I’m not what you think of when you think about who a programmer might be. I graduated college with a degree in Communications, interned at an advertising agency as a copywriter and then began my career at a large advertising agency helping clients solve advertising and communication problems. I then decided that, although I love solving big picture problems, I’m missing out on the process of taking those high-level ideas and turning them into real world solutions. Since I had always had an interest in being able to build software, I started learning how to write front-end code in an attempt to be more involved in the ‘creating’ part of problem solving. I left the agency I was working at and started at a software company as a ‘UX Engineer’.
In my new position I quickly found that being able to write code is kind of a double-edged sword. On one hand, being able to write code was this magical ability to create, invent and turn my ideas, which before I could only write about and explain to people, into actual real life things. On the other hand they way that I was perceived changed dramatically. I went from being known as someone who was talented at ideating and thinking about big-picture, human problems, to being perceived as someone who enjoyed and excelled at very technical, low-level problems. I went from being responsible for having ideas, to being responsible for implementing other’s ideas. From being perceived as a source of creativity to an inhibitor of it. All because I wrote code.
Code is not a profession, it’s not a discipline or even really a craft. Code is a tool that people learn to use in order to create software. There are certainly a lot of people who love to write code, computer scientists and ‘real’ software engineers among them, but not me.
Asking myself these questions led me to a fairly simple conclusion: front-end development is design. More specifically, I believe that the discipline of front-end development is the application of design and design thinking to the creation of user interfaces. I look at front-end developers as big picture thinkers with a technical toolbox, those who can design and engineer with technology with empathy for users.
This is the part of the post where I expect some of my designer counterparts to start saying “Waaaiiitttt just a second, that’s our job”. And yes, we still need designers, but front-end developers come at designing an interface from a slightly different, yet equally as important perspective.
Designers — focus on creating user friendly interfaces
Create interfaces that are easy to use
Create design solutions based on human behavior
Create designs that help people solve problems
Developers — focus on creating user efficient interfaces
Create interfaces that needs to be used less
Create solutions based on technical opportunities
Create solutions that leverage technology to solve problems so that people don’t have to.
The goal of a front-end developer is to create invisible design solutions. They should be able to see the technology behind the interface that’s invisible to the user, and help design an interface solves a user’s problem by leveraging that technology to the user’s benefit.
While developers and designers share the same goal — creating a great product for the user — the difference between the two lies in what information they have available and thus how they approach problems. Designers are often armed with user research, personas, jobs-to-be-done analyses, etc. and therefor approach problems from a user’s perspective. Developers meanwhile, are armed with technical knowledge and the ability to visualize how a product will be built, and are thus able to find interface design opportunities and advantages through the technology.
While the tools and technology that a front-end developer uses will change throughout their careers, the discipline and value that front-end developers provide is the creation of technology solutions for HCI and design problems.
I understand that this may be a big change in thinking for some organizations. I mean who actually wants more people giving their opinions on strategy. The general thinking for most organizations, in my experience, seems to be: although we need some developers who are talented at strategically thinking about software architecture, we need the vast majority of developers to be effective, efficient implementors and code writers. As a developer, it’s very easy to fall into this trap of expectations. We sometimes shoot ourselves in the foot by trying to be the fastest, most efficient code writers that we don’t leave ourselves any time to think about how our code is affecting users, sometimes because even if something is detrimental to the experience it’s simply too late in the process to do much about it.
The onus is really on front-end developers to make themselves present in meetings and discussions, to throw around ideas and concepts with colleagues, and to push themselves toward the front of the design process. If all you make time for or show an interest in is writing code, that is precisely the job you are going to be asked to do because as a developer, that’s already how most people perceive you. That’s OK if that’s where you want to take your career; if you’re idea of success is to achieve technical mastery on a highly technical and scientific level and you take interest in solving very complex technical problems, then there is a very clear career trajectory for you to follow. However if you want to be a developer who is seen as creative and someone who can use technical expertise to solve big-picture user experience, design or even business problems, that track isn’t as well defined. It’s all up to you to go out and develop a way to put yourself and your ideas out there, and sell yourself as someone who can empathize with users, who can see the forest from the trees, and who can develop creative solutions to high-level problems. And can also write code.
I have to credit Joel Califa’s talk, ‘Full Stack Anxiety’ for really helping me organize all the tabs that were open in head about this subject. It’s an awesome talk and I highly recommend you watch it if you haven’t already.