I have been a front-end developer my entire career. Beginning as an owner of a small web agency, I moved on to join other companies, where I was often the only front-end guy. These were and are great gigs. I’ve contributed to product interfaces, team frameworks, and marketing campaigns.
In being the “only guy” to do front-end, I’ve realized it’s not so great after all. I’ve experienced the Mulder syndrome at times (which isn’t an actual syndrome, but a nerdy reference to The X-Files, where the eccentric protagonist Fox Mulder is exiled to the FBI basement). In other words, I sometimes have felt people don’t care about or respect front-end. It’s a department they realize is necessary, but it’s also a department they don’t want to see.
I think we all know front-end is a valuable role—just as back-end is essential, as well as design, project management, quality assurance, devops, and so on.
But I’ve always been left with that sense that I’m not a real coder, I’m not a real designer, and my job responsibilities fall somewhere between “code this email” and “make this button look pretty.”
How can we make front-end development’s importance more accepted?
It’s not easy. But with a bit of proactive effort on your part, you can turn the front-end department into a valuable resource that has a direct impact on your organization’s goals.
Telling people what I do for a living is always painful. I can say “software developer,” but it’s not entirely true. Front-end developers live in a strange Upside Down universe, where the outside world doesn’t really know why we exist—or that we exist at all. I always describe front-end as the mechanics behind the user interface.
This is why front-end developers need to be more adamant about telling their story.
I no longer hide behind the veneer that I’m a software developer. I tell people I’m a front-end developer. I explain what that involves and why it’s important. People get it—and they often had no idea such a role existed.
Likewise, education within your company is essential. Key stakeholders might not be able to differentiate between back-end and front-end, so it’s your job to make that distinction clear. Through water cooler chats, you can help coworkers understand your skills and the value you add to the organization.
Educating your engineering colleagues is just as important. I’ve seen too many back-end developers shrug off front-end as a necessary pain. This is a terrible attitude. At my current company, we hold weekly luncheons during which an engineering team member presents a topic on his or her interest. I’ve used this platform to dive into subjects such as email development and ways a developer can keep their skills sharp.
If you don’t have a similar platform on which to share your knowledge, make the effort to organize one. It only takes an hour a week and the benefits are enormous to the entire team.
Take charge of projects
Many organizations fail miserably at managing projects. Sometimes project managers don’t exist. Or sometimes the software development lifecycle is in chaos. Whatever the case, there’s always an opportunity to step in and take the lead on a project that matters to the company.
By taking charge of a project, you can show that front-end developers have the ability and know-how to successfully manage resources and team members. This adds legitimacy not just to your individual position, but to your department as a whole.
The project you choose to lead doesn’t have to be a big one. Maybe there’s a landing page that needs to be designed, built, and tested. Be the guy or gal that stands up and says they’ll make sure it succeeds. Demonstrating success with these projects will show the company that front-end pushes the envelope and creates powerful results that have positive outcomes.
Staying up on your knowledge of the front-end world is a great way to maintain relevancy in a constantly changing industry—but also consider learning about other areas, especially as it relates to your company.
When I started my most recent position, I found out the back-end was built with Ruby on Rails. I had no idea what that was.
I knew I had to learn.
I read about how the view works within Rails. I played around with the back-end code to figure out how controllers worked. I investigated the database and learned about models. Eventually, I built my own application on a server I configured.
I have no desire to become a back-end developer, but doing these things encouraged me to understand what my back-end brethren did for a living. And knowing what they do helps me to do a better job at front-end.
The same idea applies for other departments within your company. Whether it’s marketing or finance or business development, knowing how your organization functions as individual units will help you converse intelligently and discover evidence for your own projects and tasks.
Codifying front-end development processes creates structure that gives credence to your department. Just as nations rely on rule of law to maintain stability, a written set of rules for front-end developers will show that your department has a coherent and organized method for handling projects.
For example, my current front-end department has worked heavily with the quality assurance department to develop a test matrix on which our applications are evaluated against. This checklist ensures our products work on the most popular environments our users rely on.
Similarly, creating internal structure, such as troubleshooting documentation or CSS naming conventions, will aid the front-end department in operating efficiently. And this is structure that can be shown to other engineers to give them an understanding of what it takes to develop strong interfaces.
Moving front-end forward
Front-end development is a serious industry that boasts careers with good salaries. None of this post is to imply the opposite. I think the general problems I run into with front-end development is confusion.
There’s confusion about what the role actually entails, confusion about how the position can be used to add value to the organization, and confusion about how a front-end department should be structured.
While I outline these as problems, I also see them as opportunities. If you’re a front-end developer at a small company, you have a huge ability to educate your team and to elevate front-end to be an impactful, goal-achieving component of your organization.