Don’t confuse what I do with how I think or why front-end developers are not engineers.
Front-end developers are having a bit of an identity crisis, one that designers should know very well.
For the longest time, many organizations misunderstood design as an aesthetic function. But designers knew that they could contribute more than just pushing pixels. They didn’t want their whole job to be ‘make it pretty’; they wanted to get inside the user’s head and understand the human problem that design and business were trying to solve. Of course not all designers want this kind of additional responsibility, some are content with the artistic side of design and have no intention to delve into the problems of the business and user. But a clear subset of design, product design, is as much of a problem solving function as it is aesthetic.
Front-end developers are in a very similar situation. Many organization look at front-end development as an execution and implementation function whose job it is to ‘make it work’. Just like there are designers who only want to create visuals, there are developers who love to solve engineering problems related to maintainability, scalability and performance. However there is a rapidly growing subset of developers to whom simply executing and implementing a design with code is not where they excel. This subset is front-end development. Similar to designers, front-end developers want to understand the communication and business problems that products are trying to solve, and use their knowledge of code and the interface and use it to help develop the product.
Because of it’s name, many people see front-end development as a counterpart to back-end programming, however a lot fewer people view it as a counterpart to design and I think that perception hurts the prospects of many smart front-end developers from solving higher-level business and communication problems.
I’m a front-end developer myself. I majored in communications and used to work in advertising developing communication strategies. I know HTML, CSS, and Javascript + some frameworks. I also know what looks good and how to create clear visual communication. But that fact I know how to write code for a machine leads people to believe that I think like one, when in fact the way that I think is much closer to the way a designer needs to think. This is similar to the misconception that designers think like artists.
Code is a tool like illustration is a tool. It says little about the person using it.
So as a front-end developer, what can you do to show that you’re not just some anti-social nerd who just wants to code in isolation, and that you actually give a shit about the product, how it’s used and it’s effect on the business?
Here’s the stack that I think all front-end developers should know.
Write
This is one the best and fastest ways to illustrate you’re thinking. You can write about anything: product concepts, design critiques, what you learned from studying other industries, patterns and trends you’re recognizing, etc. Anyone, developer or design or whoever, who wants to solve high-level problems needs to be able to communicate their thoughts and talk through solutions clearly and succinctly through writing.
Design
If you don’t already know design, pick up Sketch and learn design principles like whitespace, typography, color theory and hierarchy. Sketch is like the jQuery of design; it is a vastly simplified version of Illustrator and perfect for those who haven’t had a ton of experience working with vector software, and there are a litany of tutorials out there to help learn it. Like code, design software and design principles are just tools and patterns to learn and follow. You don’t have to have some innate ability, just learn how to do it.
While writing is great, being able to show someone what you’re talking about is often very helpful.
Prototype
This is a super power. Code allows you to take your ideas and actually make them real. Protoypes exist as a physical (or digital) representation of your thinking. They don’t have to be super performant or scalable; they need to illustrate the idea in it’s entirety. Remember you’re not in product engineering, your in product development. a prototype’s purpose is to show how a product/interaction is used and what it feels like in use. For instance, designing for delight is something to aspire to, but saying that you can design for delight using static images is a fallacy. Some things that we design for can only be communicated by using the product. To fully communicate you’re idea, code it up real quick using a framework or a generator. A lot of times having an actual thing rather than a concept is the difference between getting or not getting stakeholder approval on an idea.
I think imposter syndrome put a lot of pressure on front-end developers to go deep on engineering since they worked with code and sat with more hardcore back-end engineers. When in reality, many front-end developers are more successful and are able to contribute more going deep on the interface as a whole (meaning the human/communication part and the computer part) and being two-way communicators that speak both languages, seeing as interfaces are two-way communication layers themselves. The need for people to translate design/experience to tech and then tech to design/experience is enormous. At the end of the day front-end developers are there to help develop a product, not so much engineer it.
Quote : Tyler Cecchi
Source : Medium