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.
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.”
“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?
Here’s a few descriptions I found on GitHub Jobs and Authentic Jobs:
(That one came from a job posting entitled “CSS & HTML Ninja with UX & UI Skills” which makes me kind of nauseous.)
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.
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.
A far cry from “Implementation Designer,” where I was styling CSS to match a client site.
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:
- 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.
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.