When I went to college I knew I wanted to work with computers but I didn’t know what exactly I wanted to do. I had fallen in love with a Packard Bell “multimedia” computer with a Pentium processor and a (gasp!) CD-ROM drive. I spent every waking moment on that computer doing nothing in particular but constantly building little tools and tweaking the system. It was all I could think about doing, and I knew that this was my career.
In college I took the requisite courses. Computer Science I and Computer Science II taught in Pascal. C for UNIX. C++. Smalltalk. Prolog. Assembly. Data structures and algorithms. Databases. All that stuff that requires you to sit in front of the terminal and type furiously to get a result. I found that really boring. I’m a very visual person, and staring at an endless stream of text all day drove me insane. That’s when I started experimenting with the web.
I’m dating myself here, but during my first year in college (1996) I set up my first webpage on AOL. I set it up mostly to keep in touch with high school friends and before I knew it I was spending a lot of time on that page. I was constantly updating and tweaking and trying to add new functionality. After a few months of doing this, I wanted to find a way to turn it into a job. My college, however, had zero classes on web development in the curriculum. It was just too new. So I learned mostly on my own, and got myself an internship at a startup doing web development.
It’s been over 15 years since then. Business has shifted to the web and with it the demand for web developers has steadily increased. What is surprising to me is what hasn’t changed: the perception of web developers as a whole.
In most companies, both large and small, web development is seen as some sort of gross amalgam of design and engineering. It’s not unlikely to see web developers in strange organizational groupings. Sometimes they are under design, sometimes they’re under product management, sometimes they don’t exist at all. I’ve spoken with a lot of web developers who have expressed this frustration to me. It’s hard for them to get any respect in the organization for what they do. And that starts with the organization as a whole.
Shortly after that, led by these first few web developers, Yahoo decided that all of those talented individuals were actually software engineers. Every single “web developer” became a “front-end engineer” overnight. They were now officially part of engineering, where they should have been all along. What followed was, in my opinion, the development of the greatest front-end community in the world. This was before Google became the place to work and long before Facebook and Twitter entered into the minds of engineers. A lot of the best practices we have today, especially in the realms of performance, progressive enhancement, open APIs, and accessibility, come directly from the work that was done at Yahoo during this period. By the time I arrived at Yahoo in 2006, the front-end community was vibrant and thriving, transforming Yahoo into a company that took incredible pride in crafting Web experiences. I was honored and privileged to be able to contribute to that community and work with all those people.
Many of the front-end engineers from Yahoo can be found at companies large and small all around the world, helping to bring the same level of professionalism to other companies.
Yet in so many companies there is still a lack of respect for web development. Quite frequently we are labeled as “not engineers”, and sometimes even shunned by the “real” engineers. What I know, what I learned from Yahoo, is that what we do matters (this actually comes directly from Nate Koechley’s required “How to be a front-end engineer at Yahoo” class during my orientation). We may not have the same training and skills as traditional software engineers, but that doesn’t mean we aren’t software engineers. Yes, anyone can be a coder, because that just means you write code. What makes you a software engineer is that you’re paid primarily to write code that ends up being used by your customers. The fact that your code isn’t Java or C++ doesn’t make you any less of an engineer than someone who uses those every day.
(Note: I’m intentionally skipping over the typically arbitrary distinction some make between “developer” and “engineer”. As far as I’m concerned, they mean the same thing.)
Yes, we might not know all the sorting algorithms, or how to hand code the linked list, but we don’t need that in our day-to-day job. On interviews, I always told people up front that if they wanted an expert in algorithms, I’m not that person. I am the person who can create really nice, performant, accessible web interfaces that make the product more enjoyable to use. I am a software engineer, and what I engineer is web interfaces. Other software engineers engineer databases or servers. We are all engineers.
The key to making a difference in the perception of web developers is to act like we matter. Don’t let anyone even hint that you’re not a software engineer. The best way to do that? Make sure your title reflects what you do. I’d like to see less “Web developer” positions and more “front-end engineer” and “UI engineer” positions. Naming is important, which is why Yahoo changed everyone from a web developer to a front-end engineer. And please, shun titles like, “web ninja” and “web rock star” and the like. That doesn’t reflect your value to the company (and it just looks silly on a resume). Titles are often negotiable because, to some, they’re meaningless. But they do have meaning insofar as it communicates your value to the company.
The next part is a bit harder. Front-end engineers should be part of the engineering organization, period. We are all engineers, we should be working with other engineers, and we should be honing our craft like other engineers. All engineers should be treated equally, and their level should reflect their skill. The fact that some engineers have specialties in different areas doesn’t make them any less engineers. If your company has a database architect or network architect, then there’s no reason not to have a front-end architect. Such titles connote a certain level of skill, rigor, and accomplishment in a particular area of software engineering. These all cut across specialties evenly. Here’s how I tend to think software engineering titles:
- Junior engineer – just beginning, perhaps out of college. Needs significant training and mentoring. Capable of taking on small jobs with oversight.
- Mid-level engineer – several years of experience. Doesn’t require significant oversight and is capable of doing medium-sized tasks on her own. There is a level of trust that she will do most jobs well.
- Senior engineer – experienced and shows leadership qualities within the team. Capable of taking on tasks completely and performing superbly without oversight. Takes responsibility and others on the team look up to her for advice and guidance.
- Principal engineer – very experienced and shows leadership qualities that extend outside of the team. Capable of owning complex tasks as well as delegating and managing others. Rock-solid interpersonal skills that allow her to influence direction both within and outside her own team.
- Architect – very experienced and shows leadership qualities across teams. Organized and a good communicator with a good understanding of systems. While capable of implementing, likely spends most of her time designing and overseeing implementations as well as mentoring others. The go-to person for tough problems.
As you can see, all of these positions are much more about personal capabilities than they are about a particular set of technical skills. You should be able to apply these conditions regardless of an engineer’s specialty or area of focus. A senior front-end engineer should be, level- and skill-wise, quite similar to a senior back-end or database engineer. Things like code conventions, best practices, and systems design are learned on the job, not at school, and are equally important for all engineers to understand. Setting up appropriate leveling really makes the case that front-end engineers are on par with any other engineer in the company.
If your company isn’t setup this way, it’s time to make the case. Web developers are software engineers and should be treated as such. The overwhelming success of the front-end community at Yahoo serves as a lesson to all companies: when done right, you can attract a phenomenal amount of talent and do amazing things. Yahoo’s recent struggles aren’t a reflection of the front-end community, and as mentioned earlier, there are a lot of former Yahoos who are now trying to build proper front-end organizations in other companies.
Almost all of the “top companies” you can think of right now are thriving because of the contribution of front-end engineers. There’s still an arms race going on among Google, Facebook, and Twitter, trying to find and hire more and more front-end engineers. Make no mistake, this is our time. So the next time someone asks you what you do, simply answer, “I’m a software engineer.” Then you can explain that your focus is on making web applications.