At last week’s CSSDevConf, Micah Godbolt gave a great talk entitled Raising a Banner for Front-End Architecture, which really hit home.

Without stealing the thunder of his talk too much, I’ll try to summarize what I took away from it, and define what a Front-End Architect is.

Content Strategy?

He opened by telling a story: in the early days of the web, there was one role: Webmaster. As time went on, people began to group under certain “hats they preferred to wear.” He references Kristina Halvorson’s 2008 ALA post on Content Strategy as being a formative moment for “people that love content.” The idea of content strategy had been discussed, but “what this article did though was define the heart, soul, and purpose of Content Strategy, and the Content Strategist.”

He argues that what is happening with Content Strategy is what is happening now in Front-End. We are tired of the front-end* “being an afterthought, something to start after all of the important work has been done.”

*whether that’s build tools, CSS/Sass structure/theming, or perf opt, JavaScript, etc.

“Just like Content Strategy, Front End Architecture is a collection of processes. It’s a discipline, and those who practice it are Architects. But instead of planning, developing, and managing content…We are planning, developing and managing a theme system.“

What is a Front-End Developer?

Ask ten people what the job description for “Front-End Developer” looks like; you’ll probably get about 8 different answers. Is it someone who writes CSS and styles or creates themes? Is it a JavaScript or Rails dev who works on the “view” portion of a site or app? Is it someone who does client-based HTML/CSS/jQuery? And MVC JavaScript?

Here’s a few descriptions I found on GitHub Jobs and Authentic Jobs:

Translate requirements and mockups into fully functioning features using JavaScript and HTML/CSS; Experience with JavaScript libraries such as JQuery; Experience with data-driven product development: analytics, A/B testing, etc; Empathy for the end user

Extensive knowledge of HTML / HTML5 and CSS / CSS3; Strong command of jQuery and other JavaScript frameworks; Intimate knowledge of cross-browser compatibility, web standards, and SEO best practices; Solid understanding of XML and interacting with public APIs; Skills in Photoshop or similar design software; Strong knowledge of usability and user experience (UX) design; Good eye for layout, composition, and typography

(That one came from a job posting entitled “CSS & HTML Ninja with UX & UI Skills” which makes me kind of nauseous.)

Strong knowledge of web standards (HTML5/CSS3); Responsive design experience and interest in designing for mobile users; Solid understanding of JavaScript/jQuery; Understanding of Git; Experience developing for WordPress and open source CMS’s; An eye for design, typography and attention to UI details; Experience with preprocessing languages (Sass, Less, etc.) is a plus

Familiarity with linting and/or other code quality tools; Working knowledge of grunt or similar build tools; Knowledge of optimizing CSS/JavaScript performance by coding practices and tools; Experience with CSS pre-processors, preferably Sass.

HTML/CSS Template creation and Maintenance of existing sites—this may include adding a navigation item, a new image, new content, etc; Ability to quickly figure out how a site is put together, and make the appropriate changes; Ability to write and work with existing JavaScript and jQuery; Experience with CSS Preprocessors and git

Are these really all the same job title?! Are we looking for one person who is simultaneously a UX designer, visual designer, “not just jQuery” JavaScript developer, HTML/CSS proficient, a Sass expert, familiar with git, CMS’s, analytics and A/B testings and responsive design, and also experienced in performance optimization, build and deploy tasks, and MVC and API development?

With 3-5 years of experience?

Mostly what this says to me is that our industry, the vague “front-end development and design” industry, is just growing and changing so quickly, we haven’t solved the hardest problem: naming it.

It’s okay that we need all these roles, that we need people to wear all these different hats. And it’s also fine that depending on the company, the HTML/CSS/Sass person is also the designer, or that the MVC JavaScript person is also the jQuery/interaction/Sass person. All of us have things we like to do better, and there will be a lot of overlap. Many companies, especially small ones, do need you to wear many hats.

Now, I’m not bashing specialization; I’m not saying that you can’t be a jack of all trades, or good at many things at once. But I do think we can do a better job of naming the roles we are looking for.

My path to loving Front-End architecture

I started my career as a “Web Designer,” in which I made pretty pictures of website-looking things in Photoshop that occasionally turned out looking mostly similar. I was pretty terrible at this job, honestly, because I am much better at writing HTML & CSS than I am at blank-slate designing.

After that I was an “Implementation Designer,” which really meant I themed white-label software to match our client’s websites. This job was 5% Photoshop, 20% explaining to clients that we couldn’t make Feature X work a certain way because It Just Doesn’t Do That Sorry, 75% editing huge CSS templates, and 0% editing the HTML because it was all generated and backwards-compatible and not-editable-by-us-peons. Something like that.

Around this time I attended a workshop by Jonathan Snook, Dan Rubin, Bryan Veloso, and Steve Smith. I had a fun chat with Snook afterwards, in which I asked him, “how do you organize your CSS?” What I really wanted to know was, “when you have a great big CSS file, how do you group, organize, contain, and structure it so that it makes sense?” I was quite pleased to hear his answer, which was quite similar to my thoughts, and eventually turned into SMACSS.

I was very excited about fixing those ugly huge CSS templates, and so I did. That was my first foray into “architecting” anything in CSS.

This was a defining moment in my career, and in my recognition of my niche in the web industry. I liked that kind of refactoring, organizing, structuring, and building. I liked it way better than I liked doing funky CSS tricks, or detailed style and theming work. I liked making a CSS file that was organized and commented, that other people could read and use, and I felt that the end result (the designed website) was way better when the code was better.

My next job was building the HTML and CSS structure for an large-scale enterprise application undergoing a realign/redesign that also included some new functionality. It was a huge undertaking that involved visual themes for different clients, consistency of UI and UX interactions across multiple apps, IE and responsive support for devices, performance and asset caching concerns, and global versus app-specific styles. I wasn’t that far into my career and it was the most scared and most exhilarated I’d ever been.

But that job? That was architecting the front end of the app. I was not the designer on the project, although I did make design choices. I was not developing functionality, although I was responsible for keeping interactions and functions similar across the apps. I was not always even creating the visual/color themes, although I did create the setup in which they worked.

My job was building a system that could serve non-responsive styles to IE8, responsive styles to modern browsers and devices, kept UI modules consistent in multiple locations, and worked even though our apps were all gems being pulled into a larger project and couldn’t share a Sass variables file. My users were my fellow developers; my job was to make it easy for them to style a new app with as little effort and research as possible, to have bullet-proofed the styles so that bug fixes didn’t break other things. My job was to help our devs take us under 3 seconds load time on our data-heaviest apps, to eliminate CSS and JavaScript and optimize images and performance so things worked quickly and easily.

A far cry from “Implementation Designer,” where I was styling CSS to match a client site.

Both were great jobs. But they were very different jobs. And very different from a JavaScript MVC/app/feature developer who happens to also touch HTML and CSS sometimes.

Some thoughts on Salary

Even though the “Designers as startup founders” and “why design matters” discussions are gaining traction, designers still make less than developers. When I search Web Designer on Indeed.com’s Salary Search, the average is $66k; Front End Designer gets $84k, but Front End Developer and Back End Developer $95k. Rails or Ruby Developer postings reach $102k. Interestingly UX Designer gets $94k and the super-vague designer/developer combo gets $78k.

That wasn’t the most detailed research, but I hope it gives some quick insight into the way that our job titles matter. Certainly my job as a CSS-editing theme-and-button-graphic maker was a lower salary than my job as a designer/developer/architect, as it should have been. Treading lightly here, as I absolutely am not implying that anyone’s particular skillset isn’t valuable or should be worth less money, but the skills required to do theme/styling or prototyping in HTML and CSS are not comparable to systems and architecture on the front end. Those two roles should have different names, and perhaps different salaries. Likewise, an incredibly talented designer who also does some styling and rapid prototyping should be compensated differently than someone who only does the styling/theming.

I think it’s been understood that a developer should make more money because they are “solving hard problems.” I don’t disagree, but that has left the front-end and all its related tasks (design, images, js, and front-end performance, style guides, etc) as leftovers, stuff that either gets shoved off on unwilling back-end devs or unprepared designers. As Micah says, “an afterthought after all the important work is done.” At this point, though, I think we need to accept that someone doing the work of a Front-End Architect is solving equally hard problems as a Back-End Developer, just in a different yet related arena. And why shouldn’t they get paid on the same scale? (And on that note, why shouldn’t a designer get paid highly too—aren’t they solving hard problems?)

A Banner to Rally Under

Micah defines Front-End architecture as:

“a collection of tools and processes that aim to improve the quality of our front-end code while creating a more efficient and sustainable workflow.”

What defines a Front-End Architect, compared to a Front-End Developer or a Front-End/Web Designer or what have you? Certainly there is a lot of overlap.

Micah’s talk covered the following potential responsibilities:

  • Coding Standards - HTML, CSS and Sass/LESS/etc, JavaScript
  • Documentation
  • Style Guides or Pattern Libraries, “a common language”
  • Regression Testing
  • Dependency Management, package managers, etc
  • Build Systems, Grunt/Gulp/etc
  • Linting, Compiling, Minifying, etc
  • Performance Optimization for CSS, JS, images, asset caching
  • Continuous Integration

I’d go on to say that a quality Front-End Architect might also be responsible for:

  • understanding the cascade, inheritance, semantics, and being able to choose the best style of CSS organization for the project (not necessarily their favorite)
  • organizing and building UI modules, working closely with UX or more visually-focused designers/CSS developers
  • consistency of modules, look and feel, UI interactions
  • creating file and folder structure and naming conventions, for HTML and CSS, most likely JS as well, and helping define back-end naming conventions for consistency
  • understanding the technological and business implications of a task, technical debt, and “perfect is the enemy of done”

Obviously every project and company will be different, and some of those items may be filled by multiple people, or even teams.

But that is the job I want. I want to build systems, architectures. I want my users to be my fellow developer and designers as much as the end user. I want to make a site where the code on the inside looks as great as the outside, and make it easy to do things like theme, A/B test, and build new modules.

I want to be a Front-End Architect when I grow up.

So how do we get there?

I’ll posit an obvious and easy first step: change your Twitter bio. My dad, who has an MBA, and Patrick, the best manager I ever had, both gave me advice along the lines of “do the job you want to be doing.” It’s worked, so far; refactoring those ugly big CSS templates was not my day-job, it was something I tackled out of desire that eventually turned into some of my main responsibilities. It is what led to my next job, and the next.

No, changing my Twitter bio to say “Front-End Architect” won’t make it my official job title, but I think it describes what I do pretty damn well.

And after that? Ask for it. I aim to put it on my resume as the goal for my next job, and I intend to ask for it as my title. Yes, that may mean coming in with a job description for myself, but that’s okay. I know what it is that I do best, and I’m okay with explaining it to others.

If this doesn’t resonate with you, what is your niche of the front-end world? Are you a JavaScript Developer, a CSS Developer? A Web Designer? A Product Designer & Developer? What is a Front-End Developer? I won’t open that can of worms, except to say I think it might be time we start making new definitions.

Micah, thank you for raising a banner we can rally under, and giving me the words to describe the job I’ve been doing for the past three years. I’ll be sure to let you know when I’ve got it on a business card.