job titles – CSS-Tricks

More Than “Slapping Paint on a Website”

Geoff Graham — Tue, 29 Nov 2022 15:03:20 +0000

I’m a sucker for anything about front-end job titles.

CSS evolved and we’re beyond the point where everyone can just do it as a side interest. We all can learn it and build amazing stuff with it, but using it wisely and correctly in a large-scale context isn’t an easy job anymore. It deserves people whose work is to focus on that part of the code.

Anselm is partly in responding to Sacha Greif’s “Is There Too Much CSS Now?” and the overall sentiment that CSS has a much higher barrier to entry for those learning it today than it did, say, in the CSS3 days. Back then, there was a super direct path to see the magic of CSS. Rachel Andrew perfectly captures that magic feeling in a prescient post from 2019:

There is something remarkable about the fact that, with everything we have created in the past 20 years or so, I can still take a complete beginner and teach them to build a simple webpage with HTML and CSS, in a day. […] We just need a text editor and a few hours. This is how we make things show up on a webpage.

That’s the real entry point here […]
— “HTML, CSS and our vanishing industry entry points”

Rachel is speaking to the abstraction of frameworks on top of vanilla CSS (and HTML) but you might as well tack big, shiny, and fairly new features on there, like CSS grid, flexbox, container queries, cascade layers, custom properties, and relational pseudo-classes, to name a few. Not that those are abstractions, of course. There’s just a lot to learn right now, whether you’ve been writing CSS for 20 days or 20 years.

But back to Anselm’s post. Do we need to think about CSS as more than just, you know, styling things? I often joke that my job is slapping paint on websites to make them pretty. But, honestly, I know it’s a lot more than that. We all know it’s more than that.

Maybe CSS is an industry in itself. Think of all the possible considerations that have to pass through your brain when writing CSS rules. Heck, Ahmad Shadeed recently shared all the things his brain processes just to style a Hero component. CSS touches so much of the overall user experience — responsiveness, accessibility, performance, cross-browser, etc. — that it clearly goes well beyond “slapping paint on websites”. So far beyond that each of those things could be someone’s full-time gig, depending on the project.

So, yes, CSS has reached a point where I could imagine seeing “CSS Engineer” on some job board. As Anselm said, “[CSS] deserves people whose work is to focus on that part of the code.” Seen that way, it’s not so hard to imagine front-end development as a whole evolving into areas of specialization, just like many other industries.

More Than “Slapping Paint on a Website” originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Is CSS a Programming Language?

Chris Coyier — Fri, 07 May 2021 13:56:17 +0000

I have a real distaste for this question. It might seem like a fun question to dig into on the surface, but the way it enters public discourse rarely seems to be in good faith. There are ulterior motives at play involving respect, protective emotions, and desires to break or maintain the status quo.

If someone can somehow prove that CSS isn’t a programming language (this is such a gray area that if that was your goal, it wouldn’t be terribly hard to do) then they get to keep on feeling superior in their “real” programming skills and rationalize the fact that they are (likely) paid more than a front-of-the-front-ender specializing in CSS. This is maintaining the status quo.

The reverse can also be true. If you can prove that CSS is a programming language, perhaps you can shift your own company or the industry at large toward equal respect and pay toward front-of-the-front-end developers. This is breaking the status quo.

Let’s say we could all agree on a boolean true or false on if CSS is a programming language. What now? If true, is pay normalized among all web workers? If false, do CSS specialists deserve pay cuts? If true, does everyone start respecting each other in a way they don’t now? If false, do CSS people have to eat lunch in the boiler room? I have doubts that anything will change; hence my distaste for the discussion at all.

Whatever the facts, it’s unlikely most people are going to accept even the possibility that CSS is a programming language. I mean, programs execute, don’t they? Nobody doubts that JavaScript is a programming language, because it executes. You write code and then execute that code. Perhaps you open a terminal window and write:

> node my-program.js

Sure as eggs is eggs, that program will execute. You can make “Hello, World!” print to the terminal with console.log("Hello, World!");.

CSS can’t do that! Um, well, unless you write body::after { content: "Hello, World!"; } in style.css file and open a web page that loads that CSS file. So CSS does execute, in its own special way. It’s a domain-specific language (DSL) rather than a general-purpose language (GPL). In that browser context, the way CSS is told to run (, usually) isn’t even that different from how JavaScript is told to run (


The interesting thing to note here is that the act of front-end development changes based on the size and scale of the organization. As with all arguments in front-end development, there is no “right” way! Our work has to adapt to the problems that we’re trying to solve. Is a large, complex React front-end useful for Basecamp? Maybe not. But for some organizations, like mine at Gusto, we have to specialize in certain areas because the product that we’re working on is so complicated.
I guess what I also might be rambling about is that I don’t think it’s engineers that are making front-end development complicated — perhaps it’s the expectations of our users.
To Shared Link — Permalink on CSS-Tricks

Designing for the web ought to mean making HTML and CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.



What makes someone a good front-end developer?
Chris Coyier — Tue, 11 Dec 2018 15:06:41 +0000
We recently covered this exact same thing, but from the perspective of a bunch of developers.
Chris Ferdinandi weighs in: 

The least important skills for a front-end developer to have are technical ones.
The nuances of JavaScript. How to use a particular library, framework, or build tool. How the cascade in CSS works. Semantic HTML. Fizz-buzz.

Chris takes that a little farther than I would. I do think that with an understanding of HTML, CSS, and JavaScript, the deeper the better, and that it is an ingredient in making a good front-end developer. But I also agree it’s much more than that. In fact, with solid foundational skills and really good soft skills (e.g. you’re great at facilitating a brainstorming meeting), you could and should get a job before they even look at your language skills. 
To Shared Link — Permalink on CSS-Tricks

What makes someone a good front-end developer? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.




Solving Life’s Problems with CSS
Diana Smith — Mon, 28 May 2018 15:33:32 +0000
Or: When all you have is a CSS hammer, the world looks like a CSS nail.
Whenever I hear a perfectly nice comment like, “Yeah, representing the tech field!” in response to my pure-CSS art, I get a sharp feeling of panic. 
Like many people who work on UIs for a living, I have difficulty applying the “tech” term to myself without feeling like a fraud. Impostor syndrome is a hard thing to shake. A front-end specialist? Oh, you mean the stuff that isn’t really code? That amps up the feeling from impostor to villain.
Even though 90% of my daily work revolves around JavaScript, I feel as if the “tech” label is a shiny trophy that I greedily snatched from someone more deserving. As if there are nameless, starving computer science grads out there and I’m stealing the ramen right out of their mouths.

Take for example this scenario that computer-science schooled people are probably familiar with:


      CS Course Problem: Write a script that sorts then randomizes this dataset N times, but for every 8th Q print 12 trees stacks queues void flip flop and you don’t stop rockin’ till returning the sum of the results 4x + 3y.

    My proposal: (12 hours and eight gallons of coffee later) Done! Here are 1,200 lines of beautifully formatted code! There are forty-three loops, thirty-two if/else conditions, and eighty-three lines of comments because I keep getting lost in the file — but I’ve achieved the exact desired result!
  

    CS Course Answer: Use three lines of recursion.
  

    My response: …%#@& you.
  

An exaggeration, but it’s helpful to be regularly humbled like that. It helps you grow as a programmer, problem-solver, and human. Plus, it prepares you for real-world scenarios in your career where you will regularly come across interesting challenges that require a bit of creative thinking.
When it comes to the CSS side of things, no employer will ever ask you to produce a detailed painterly CSS art piece. If they do, you really should immediately report that as harassment to HR. But it is very common to have a small and sometimes unusual request. One that may not have an obvious solution right away. 
The “tech-free” CSS — with its glaring lack of programming functions — may not immediately come to mind when given such a challenge. But make no mistake, it can be one of the most valuable tools in your algorithm arsenal! For example:


    CSS Course Problem: A disclaimer message needs to pop up into view as a warning when a user clicks a certain input field.
  

    Proposal: Piece of cake! We use our trusty friend JavaScript to trigger a click or focus event on the input element. Then we load the disclaimer template. Then we make an Ajax call for content. Once our Promise() is resolved, we append the element to the page and find where to insert it by way of finding the event.target’s parent element. After the disclaimer is loaded, we need to ensure that we’ve handled another click event on the actual disclaimer itself to toggle out of it. Once we’ve toggled out of it, we destroy the element.  If the input is clicked again, we repeat this process.
  

    CSS Course Solution: input:focus + .disclaimer { display: block; }
  

    Response: …%#@& off.
  

Again, it’s an exaggeration (and the world’s least efficient JavaScript solution), but it’s only a slight exaggeration. I see those types of proposals being put to use way more often than you’d expect. Being able to provide ridiculously quick solutions to what have long been thought of as lengthy JavaScript problems? That’s one of the ways in which CSS allows me to feel like a master of tech.
This is just one of the many things I love about CSS. The limited set of rules is exactly what makes it so fun. You don’t expect CSS to fulfill all of your needs, which is what makes it all the more rewarding when you end up finding a way that it can.
Now, say there’s a design challenge. You’re asked to implement this shape in the browser:



    Proposal 1: “There’s no “reverse-border-radius” property to create that shape in CSS, so that’s not possible. Just embed an image. Duh.”
  

    Answer 1: Okay fine, don’t learn CSS for all I care.
  

No please come back! I want you to learn.
It’s true that no one will penalize you for using an image. There are no CSS police enforcing this rule. Hell, there aren’t even any computer science police stopping you from using a terrible billion-line algorithm instead of a beautifully simple recursive one. But if there’s any concept to be shared between CSS and CS it’s that “not possible” is hardly ever the answer.
So let’s try a brute-force method, shall we?

    Proposal 2: Start with a black rectangle, then notch out the sides with two border-radiused 
 elements that match the white background color, like so:



    Answer 2: Alright! Now we’re getting somewhere. The shape is coming together. But what if the background is varying? Or a gradient? Or an image? How would that look?


Hm. No longer looks quite as nice. So how we do allow our natural background to shine through, while still keeping a sloping-inward shape — something that CSS isn’t natively built to support?

    Proposal 3: Keep the rectangle. Keep the curved divs. But don’t fill the rectangle with color, and don’t fill the curved divs with color either. Instead, spread the black color outside of the curved divs,  using box-shadow. The rectangle will simply need an overflow: hidden; to keep that box-shadow color contained within its boundaries.



    Answer 3: Well done! Beautiful!

The above technique has been described in even better detail in Ana Tudor’s excellent post on scooped corners. And it’s an excellent concept to keep in mind when presented with “not possible with CSS” problems. It’s one that I love to use when creating art.
Take, for example, this portion of one of my CSS paintings:

The human neck unfortunately does not usually come conveniently packaged in a perfect rectangular shape. But HTML does, so that’s what we have to work with.
But wait, isn’t that neck-shape pretty similar to the curvy black shape that we outlined above?

Yep, it all started with a big rectangle. In this case, our outward-curving divs just used a softer blending on their box-shadow.
Outside of work, I keep coming back to CSS for artistic inspiration.
Because something about those limitations just calls to me. I know I’m not alone when I say that a rigid set of restrictions is the best catalyst for creativity. Total artistic freedom can be a paralyzing concept.
That can sometimes be the case with programming. If you have the most powerful programming languages in the world at your disposal, it starts to seem natural that you should then have no difficulty solving any programming problem. With all these amazing tools offering countless solutions to solve the same problem, it’s no wonder that we sometimes freeze up with information overload.
Sure, CSS can be thought of as not being a “true” component of the tech stack. I would not even argue against that. Let’s face it, pure CSS is not about recursion or data storage or database-querying. Its primary purpose is indeed for prettification — which doesn’t exactly help the stigma of front-enders not being “real” techies or programmers.
CSS never made any bold claims or promises. It has merely offered assistance, and it just turns out that its assistance can be downright heroic.
If you are a front-ender who has to deal with a bunch of DevOps folks mocking their CSS, just wait and see what the response is when you sneak a body { display: none; } onto production. We’ll see who’s laughing then!^*

^* They will still be the ones laughing because you will be fired. Please don’t do this.

Solving Life’s Problems with CSS originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.




The spectrum of design roles in 2018
Chris Coyier — Fri, 23 Mar 2018 22:45:07 +0000
Job titles is a regular topic around here. Occasionally heated, as job titles play a role in the hiring process (why are you asking me React questions for this UX design position role?). And complicated by the fact that there is no agreed-upon standards and the loads of people and companies who don’t take them seriously (we just want people who do a good job, make your title whatever you want it to be). Complicated again when someone from the outside needs to look in.
Jasper Stephenson:
Recently, a colleague of mine named Mariko Sugita needed to hire a designer for a website she was creating. She’s an urbanist, and not particularly involved in the digital design field, so she asked the closest designer who happened to be on hand (me), “what kind of designers should I be looking for?”
Jasper takes a crack at it in this post.

Here’s a roundup of other cracks at how to answer the same sort of question.

To Shared Link — Permalink on CSS-Tricks

The spectrum of design roles in 2018 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.




Tales of a Non-Unicorn: A Story About the Roller Coaster of Job Searching
Lara Schenck — Mon, 08 Jan 2018 15:51:12 +0000
Hey there! It’s Lara, author of the infamous“Tales of a Non-Unicorn: A Story About the Trouble with Job Titles and Descriptions” from a couple years back. If you haven’t read that original article, I recommend skimming it to give you some context for this one, but I think you’ll still find value here even if you don’t.
A lot has happened since I wrote that article in 2015, and this follow-up has been in the works for a good six months. I ended up, not with a solution for the job titles conundrum or a manifesto about the importance of HTML and CSS, rather a simple, honest story about my roller coaster ride. 
Okay, enough dilly-dally. Let’s go!


In the aftermath of the FizzBuzz drama in 2015, I doubled down on my freelance business and did really well. I got a great contract gig with startup in New York refactoring a Haml/Bootstrap situation that paid the bills and then some. I hired an assistant and started the Tackle Box, an online school sort-of-thing where I taught web development and WordPress. I made a little money off that one, too. I spoke at a handful of conferences and meetups, taught a bunch of classes, and generally had the pedal to the metal.
Then I got really, really tired. 
I was sick of writing emails, sick of sending invoices, and sick of being on the computer all the damn time. I wanted to go to work and then leave work at work; something that is very hard to do in our industry, and extra difficult when you are your own boss. I enjoyed coding sometimes, but it was all about the billable hour. Why should I write code or be on the computer at all if I’m not being paid for it? This was burnout, that thing that’s become a weird, convoluted rite of passage in our industry. 
I wanted to shut down Lara Schenck, LLC and be a ski bum. And you know what? I did. It was time for a break, and I took one for about six months.
Ski Bum Sabbatical
I left New York City in August of 2016 and moved back to my family’s farm near Pittsburgh. I got a job cleaning horse stalls for $7/hr at the stable where I used to ride when I was a kid. My plan was to gradually ramp down business while I lived rent-free and prepared myself for the simple life. That December, I would be starting work as a bartender at Goldminer’s Daughter Lodge in Alta, Utah, a tiny ski town outside of Salt Lake City. Room and board were included in the job; I’d make enough pocket money for booze, and my life would consist of skiing, sleeping, and socializing. No emails.
Just down the winding road from Alta Ski Area.
The simple life was okay for a little bit, but bartending at a 3:2 beer bar and skiing every day wasn’t as fulfilling as I’d hoped. I cut the season short and moved to Los Angeles in March with my partner at the time. We had a mutual friend with an open room in Hollywood, and I was starved for city-living. (I have since learned that LA is not the city-living I expected, at all, but that’s another conversation.) 
Time to Get a Job (for real this time)
I formally announced I was back on the scene, reached out to old clients and people from my New York network, and was even on a podcast out of the gate. None of that translated into much paying work. Luckily, I had a cushion of savings to float me for a few months (Freelancing Rule #1: You must have savings), but my heart just wasn’t in the freelance hustle this time. The prospect of negotiating contracts and engaging new leads was nauseating rather than exciting, and the small business website work I did was no longer the challenging and invigorating experience it had been before.
I decided to get a full-time job, for real this time.  Once again, I wanted to work on a team and on bigger projects. I was tired of doing everything myself, and I wanted to learn from and share my experience with others. And, you know, a regular paycheck.
I set to work applying for jobs, putting long hours into carefully crafted cover letters. I had several promising interviews, got my hopes way up a couple of times, and received zero job offers. For one particular role, I’d gotten as far as discussing salary requirements and start dates, and was expecting an offer letter within the week. Then, the next week they were all of a sudden no longer hiring. I didn’t run into any FizzBuzz, for better or for worse.
I started to question why my designer/developer skillset appeared to hold so little value now when I’d felt so in demand just a year ago. I stubbornly refused to learn React just so I could have it on my resume—I’m great at other important things, why can’t people see that?! I wondered whether the five years of self-employment was a hindrance, or was there something fundamentally wrong with how I interviewed? Did I shoot myself in the foot with this whole “non-unicorn” thing in the first place?
These months were a major ego-check. It turns out, full-time jobs aren’t something you can just “get.” It’s just not that easy, for me at least.
The Value of HTML and CSS
Responding to job posts with those carefully crafted cover letters had a very low return on investment so I decided to change my approach. Instead of putting my time into writing said cover letters, I would focus on writing about real things and becoming a better developer, and the jobs would come to me. I launched a well-thought-out redesign of my website, published a Reverse Job Post, and buckled down on my JavaScript studies.
This was right around the time Mandy Michael wrote “Is there any value in people who cannot write JavaScript?” which hit the nail on the head. I wrote a question into ShopTalk show about this phenomenon and mentioned to Chris that I’d love to come on the show and talk about it if they’d like. The next day, Chris invited both Mandy and me to come on the show and hash it out:
HTML and CSS are valuable, but intimate knowledge of them has become more of a specialist role. Perhaps, one can position their skills as HTML, CSS, plus something else (e.g. UI design or WordPress). The nature of products and rapid feature releases deem quality HTML and CSS an afterthought at many companies so at the moment, maybe the demand just isn’t there. Perhaps the rise in accessibility awareness, design systems, and time lost debugging bad CSS will change the tide?
The episode was well received; I was obviously not the only one struggling with this issue. I made a Github repository called Front-end Discourse with the intention of gathering and synthesizing opinions and coming up with a plan of action on the job titles front. Chris even wrote about the job titles conundrum here on CSS-Tricks. The momentum was there; this could be my thing! 
But then…I let it die.
An Unexpected Twist
A few days after the ShopTalk episode came out, I received this tweet:

Umm…that’s a link to a Google job post. 
I thought it was a joke at first, but nope, the tweet author sent me an email later that day, and it was the real deal! They’d been referred to me by a benevolent figure in the web industry whom I’d never met. I had a call with them and another member of their team, and it was magical. They told me all about a new team starting within Developer Relations at Google that would be working to improve the “Web Content Ecosystem.” Web Content Ecosystem? That’s WordPress! And they were recruiting me! Holy sh#t, this actually happens!
This was my dream job, not a front-end designer/developer role. I didn’t even know this was a job! I had already been doing this work on my own time for several years: teaching and speaking about WordPress, writing informational blog posts, recording videos, and helping people use WordPress more responsibly. And they would move me to San Francisco! I was not a huge fan of Los Angeles.
Unfortunately, Google doesn’t just “give” people jobs…you have to interview. 
Computer Science Bootcamp
Now we have me, the designer who applied for a JS job and failed FizzBuzz, preparing for the Google interview otherwise known as the grandparent of all technical white-boarding interviews. It was time to swallow any feelings I had toward this interviewing style and get to work.
I had three weeks until a “coaching call” that would unofficially determine whether or not I could skip the technical phone screening and jump straight to the day of on-site interviews because, duh, this was meant to be. Luckily, this coincided with a lull in freelance work, which had also been picking up, so for about a week and a half, I put myself through a self-directed computer science bootcamp. On the way, I wrote a bunch of blog posts about what I learned. 
Oh, how I longed to write that Tales of a Non-Unicorn: I GOT A JOB AT GOOGLE, F@#KERS!!! follow-up for all those Reddit haters after it was said and done!
The day of the coaching call arrived, and it was fantastic! I was a little slow on the coding question, but it wasn’t as hard as I’d thought, I aced the role-related questions, and the interviewer was excellent. I heard back from the recruiter who was coordinating with me, and he said I could go straight to the on-site interviews. 
In the meantime, I went to WordCamp US in Nashville where this particular team at Google was a sponsor. I got to meet a few of the folks I’d be working with, and it seemed like such a great fit. This Google interest and being at WordCamp made me question why, at the beginning of my job search, I had seen my knowledge of WordPress as such a secondary skillset. WordPress is everywhere! And its awesome! I mean, sure, it’s not that “cool” yet, but mark my words, it will be in the “cool” ranks soon enough.
The Non-Unicorn Interviews at Google
In the week leading up to the interview, I focused on researching the role and beefing up my passion for improving WordPress and helping those who work with it. This was not a software engineering role, after all; in Developer Relations, passion for and knowledge of your subject is more important than knowing binary tree traversal, right? 
Google flew me to San Francisco and put me up in a nice hotel. I had a full day of four interviews—usually, it’s five, one was canceled—and a long, enjoyable lunch with the folks I’d been in touch with from the get-go. I didn’t feel great about my performance in the technical parts of the interviews, but I did my best and my strategy was to come off as a great coworker who knows when to ask for help. When in doubt, I remembered the strong correlation between “hard interview” and “received offer” on Google’s Glassdoor profile.
Back in LA, freelance work kept me busy while I waited for a verdict, which wasn’t long. I felt relatively zen about the whole thing. Yes, I had my hopes up, but if it didn’t work out, I at least had work to pay the bills, and it wasn’t going half-bad. I’d been contracting with an agency and learning a lot; it wasn’t the small business WordPress sites I’d been building all by myself previously. 
The Thursday after my Monday interview, I got a call from my recruiter contact. They were not going to proceed with the approval process at this time. He said I showed some very promising “Google-y” qualities, but my performance in the coding portion of the interviews wasn’t strong enough. He said he had it in his calendar to reconnect with me in six months, and that he would keep an eye out for less technical roles that might be a better fit.
…oof.
Incredibly, I was able to fend off the majority of the anger and the “I’m a failure and I suck at everything” thoughts that go hand-in-hand with rejection, maybe in part because I received such a nice email from one of the people I’d been in touch with throughout the process. He had applied three times before he got a job there—which apparently is not uncommon—and this simply meant I’d be taking a slightly different path. They were all bummed I didn’t make it. 
This brings us back to the present. I don’t feel sour about algorithms or white-boarding interviews…I have another one to get ready for in six months! Unless, of course, another really awesome opportunity comes my way in the meantime. Who knows. 
This whole job search has been such a ridiculous roller coaster of hopes slowly going up then crashing down. If there’s one thing I’ve learned, it’s that I still don’t know where I’ll end up, but I’m doing my best and I’ll keep doing it until the right thing comes along.


Whew, that was a lot! Thanks for making it this far. A+ for you, reader!
Post-Mortem
Before I wrap this thing up, I want to make a few observations about this whole job searching process that I hope can help others on their roller coaster ride. 

Algorithms and white-boarding interviews aren’t necessarily bad. I think they can be implemented badly. The Big Tech Companies are fully aware that they miss out on great candidates because of algorithm questions, but this interviewing strategy is so good at filtering out bad candidates that they keep it around. It sucks for us, but I don’t see that changing anytime soon. Plus, I learned a hell of a lot of stuff preparing for it, and it’s made me a better developer and better human being.
Write a “Reverse Job Post.” I don’t recall where I learned about it, but here’s mine for reference. Even if no one reads it, it’s a great way to figure out what type of job and company you are looking for, and you could totally paste a link to it in the cover letter field for an application and call it a day.
Learn computer science fundamentals. I know we are already inundated with things to learn, so it’s hard to preach this, but having context for what the tools we use actually are has helped me a lot. For example, two months ago I would have had a hard time wrapping my mind around GraphQL, but in my interview preparation I learned about graphs and tree data structures, so I was able to understand the concept relatively easily. Cracking the Coding Interview is not a good place to start, BaseCS and the Impostor’s Handbook are. Also, stay tuned for some relevant articles here on CSS-Tricks, from yours truly!
Don’t spend all of your time on job boards. It’s a crapshoot. I think there are great job boards, but in general, no matter how quality the listing, whether or not the position is actually available or accurately represented in the post is a toss-up.
Be vocal. I doubt any of this Google stuff would have happened if I hadn’t written into ShopTalk show and asked Chris to have me on the episode. If you have an impulse to write something or have a question or feel the urge to tweet at someone you don’t know, do it (but be a good person about it, obviously). The more web people that know you exist, the more likely it is that something will come your way.

Those are some things that helped me, but I still don’t have a job, so maybe don’t listen to what I say. I don’t know. It’s an incredibly difficult and demeaning process, and there’s no secret sauce that works for everyone. Our industry is a young one, and as far as I’m aware, there is no such thing as a surefire career path in web development.
I hope I don’t write another “Tales of a Non-Unicorn” installment. The whole idea of a “unicorn” is bogus, anyway. We are all just people, with different levels of knowledge in different areas, and if you can honestly say you’re doing your best then I think that’s all you can do. 
What I will be writing, however, are some “Computer Science Study Guides” for the self-taught developer, here on CSS-Tricks, and maybe some stuff about how cool WordPress is nowadays. At the very least, “Intro To Algorithms” will be coming at you, soon!
How about you, reader?
Have you been on this roller coaster ride, too? Where did you end up? What advice can you offer to those of us who are still in the midst of our journey?

Tales of a Non-Unicorn: A Story About the Roller Coaster of Job Searching originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.




Getting Nowhere on Job Titles
Chris Coyier — Mon, 16 Oct 2017 07:37:23 +0000
Last week on ShopTalk, Dave and I spoke with Mandy Michael and Lara Schenck. Mandy had just written the intentionally provocative “Is there any value in people who cannot write JavaScript?” which guided our conversation. Lara is deeply interested in this subject as well, as someone who is a job seeking web worker, but places herself on the spectrum as a non-unicorn. 

Part of that discussion was about job titles. If there was a ubiquitously accepted and used job title that meant you were specifically skilled at HTML and CSS, and there was a market for that job title, there probably wouldn’t be any problem at all. There isn’t though. “Web developer” is too vague. “Front-end developer” maybe used to mean that, but has been largely co-opted by JavaScript.
In fact, you might say that none of us has an exactly perfect job title and the industry at large has trouble agreeing on a set of job titles.
Lara created a repo with the intent to think all this out and discuss it. 
If there is already a spectrum between design and backend development, and front-end development is that place in between, perhaps front-end development, if we zoom in, is a spectrum as well:

I like the idea of spectrums, but I also agree with a comment by Sarah Drasner where she mentioned that this makes it seem like you can’t be good at both. If you’re a dot right in the middle in this specrum, you are, for example, not as good at JavaScript as someone on the right. 
This could probably be fixed with some different dataviz (perhaps the size of the dot), or, heaven forbid, skill-level bars. 
More importantly, if you’re really interested in the discussion around all this, Lara has used the issues area to open that up.
Last year, Geoff also started thinking about all our web jobs as a spectrum. We can break up our jobs into parts and map them onto those parts in differnet ways:
See the Pen Web Terminology Matrix by Geoff Graham (@geoffgraham) on CodePen.
See the Pen Web Terminology Venn Diagram by Geoff Graham (@geoffgraham) on CodePen.
That can certainly help us understand our world a little bit, but doesn’t quite help with the job titles thing. It’s unlikely we’ll get people to write job descriptions that include a data visualization of what they are looking for. 
Jeff Pelletier took a crack at job titles and narrowed it down to three:

Front-end Implementation (responsive web design, modular/scalable CSS, UI frameworks, living style guides, progressive enhancement & accessibility, animation and front-end performance).
Application Development (JavaScript frameworks, JavaScript preprocessors, code quality, process automation, testing).
Front-end Operations (build tools, deployment, speed: (app, tests, builds, deploys), monitoring errors/logs, and stability).

Although those don’t quite feel like titles to me and converting them into something like “Front-end implementation developer” doesn’t seem like something that will catch on.
Cody Lindley’s Front-End Developer Handbook has a section on job titles. I won’t quote it in full, but they are:

Front-End Developer
Front-End Engineer (aka JavaScript Developer or Full-stack JavaScript Developer)
CSS/HTML Developer
Front-End Web Designer
Web/Front-End User Interface (aka UI) Developer/Engineer
Mobile/Tablet Front-End Developer
Front-End SEO Expert
Front-End Accessibility Expert
Front-End Dev. Ops
Front-End Testing/QA

Note the contentious “full stack” title, in which Brad Frost says:
In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around.
Still, these largely feel pretty good to me. And yet weirdly, almost like there is both too many and too few. As in, while there is good coverage here, but if you are going to cover specialties, you might as well add in performance, copywriting, analytics, and more as well. The more you add, the further away we are to locking things down. Not to mention the harder it becomes when people crossover these disciplines, like they almost always do.
Oh well.

Getting Nowhere on Job Titles originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.




“lives in a sort of purgatory”
Chris Coyier — Sun, 19 Feb 2017 13:51:14 +0000
Brad Frost:

A front-end designer … lives in a sort of purgatory between worlds:

They understand UX principles and best practices, but may not spend their time conducting research, creating flows, and planning scenarios
They have a keen eye for aesthetics, but may not spend their time pouring over font pairings, comparing color palettes, or creating illustrations and icons.
They can write JavaScript, but may not spend their time writing application-level code, wiring up middleware, or debugging.
They understand the importance of backend development, but may not spend their time writing backend logic, spinning up servers, load testing, etc.


A front-end developer is aware.
To Shared Link — Permalink on CSS-Tricks

“lives in a sort of purgatory” originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.




The Front End Developer’s Dilemma
Geoff Graham — Mon, 13 Jul 2015 13:01:38 +0000
Hello, my name is Geoff and I am a web designer. At least, that’s what I tell people I do for a living, because it’s what most people understand.
The truth is, I am a front end developer. If you read this blog with any sort of regularity, then I don’t even need to bother explaining that job title. 
Or do I?

I get a sense that we likely have different definitions for what it means to be a front end developer. I bet the job description you would write for me varies a ton from what I actually do on a day-to-day basis. You may even expect that I know certain programming languages that I, in fact, do not.
In other words, some of you may not consider me a developer at all, or a poser at best. Many hold the opinion that front end development is not development at all. That used to hurt my feelings.
I found myself recalling those hurt feelings recently when Lara Schenck shared her story of missing out on a UX job because she wasn’t familiar with the programming test FizzBuzz. The fact that she didn’t get the job didn’t bother me as much as the number of snarky comments her story got, mostly from people who don’t consider front end development a form of development.
My Tale of Being a Non-Unicorn
I design for the web, and often code those designs into the stuff that people interact with on the front end.
I didn’t always write code. In fact, I never thought I would ever write a single line of it when I first started designing sites in 2005. Designers worked in Photoshop and developers worked in whatever they worked in — I didn’t know because it never seemed relevant to ask. We were all cogs in the machine, at least at some of the places I worked at.
But over time, I found myself not only asking those questions, but trying to answer them for myself because it became a necessity. If my designs were not pixel perfect (remember when that was a thing?) on the screen at the end of the day, I wanted to know why. In the end, that led to learning HTML, which led to CSS, which led to jQuery, which led to JavaScript. I even found myself gaining a basic understanding of PHP solely for the ability to write WordPress filters.
Am I excellent at all of the above? Absolutely not. I definitely get by, but I still find myself navigating Stack Overflow forums for what might be totally obvious answers to other developers.
That’s the abridged story of how I became a front end developer. Or front end designer. Or just plain designer. Whatever.
But You’re Still Not a Developer!
This is where I get a little hippie-dippy on things because I think the role of development is an evolving concept. Is development just about programming? Or can development be design as well? Because, if it’s all about programming, then I’m definitely not a developer.
The truth is that development has a lot to do with both design and programming. They’re not mutually exclusive. Trying to divide them in a cage match over who owns the term is as useless as Santa Cruz and Huntington Beach fighting over Surf City, USA.
How I Cope With the Criticism
I tend to deal with the criticism that front end development is not “real” development simply by not worrying about semantics. Honestly, I don’t care what people think my job title is. In some circles, I am seen as the designer. In other circles, I’m seen as the developer (for lack of a better word, I guess). Heck, as I type this, Chris Coyier sees me as the writer. Where does that fit into anything?
I called myself a web designer at the beginning of this post and that is my default answer for what I do. Some of my work happens to involve designing layouts. Some of it happens to involve coding prototypes. Some of it even requires me to write functions. All those pieces are what work together to develop a website, which is what I’m trying to do at the end of the day regardless of if I am seen as a designer or a developer.
Where Do We Go From Here?
First off, let’s make love and not war. I’m not really a fan of name-calling and snarky online comments because it’s unproductive.
Secondly, I think the door is wide open to talk honestly about the need for better job descriptions. The point of Lara’s post is not that FizzBuzz is the epitome of evil, but that the job she interviewed for was out of scope from what was written in the job description.
Lastly, let’s accept that our industry changes rapidly and that includes the scope of the work we do. We need to have an expansive and evolving baseline understanding for what front end development encompasses and that the meaning of *development* may shift from time to time or even project to project.
OK, time to stop writing and start designing. Cheers!

The Front End Developer’s Dilemma originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.




Tales of a Non-Unicorn: A Story About The Trouble with Job Titles and Descriptions
Lara Schenck — Mon, 11 May 2015 19:05:23 +0000
The following is a guest post by Lara Schenck. I heard her tell this story at a CodePen Meetup in New York. I saw an awful lot of nodding heads. It’s a fact that there is some trouble in this industry with job titles, descriptions, interviewing, and that whole rigmarole. Check out this story from Lara, then follow her, as I’m sure this isn’t the end of this discussion.

I’ve been self-employed for the past three years. Though I did spend my first year out of college working for a three person, now-defunct startup, I’ve never had a typical 9-5 (or more like 10-8 nowadays) and to be honest, never really wanted one. Lara Schenck, LLC is a profitable business, and every day I do work that is enjoyable and challenging. I make my own hours, take vacations when I want to, and run everything on my terms. 
While that’s all awesome, what you don’t get from working independently is the team experience. I base my work on teaching technical literacy to non-technical designers and content producers so that they can better communicate with developers. The theory is that if a designer understands why it’s a bad idea to request 18 fonts, and if content producers know why it’s not trivial to edit the titles of a set of related posts, life will be easier for everyone. At least that’s my theory, and the assumption on which I’ve developed my business.
Lately though, in a bout of the good ‘ol impostor syndrome, I’ve been feeling like, wait, how can I be telling people how to work on teams if I’ve never really worked on one? I’ve always been the ‘Lead UI/UX/Visual/Web/Front-end Designer-person-thing’, and have never worked for a larger company with separate teams for product, UX, marketing, content, frontend, backend, etc.
So I felt the urge to look for a job, and a seemingly perfect one fell into my lap. It was for an awesome company, and it sounded right up my alley skill-wise. The title was ‘UX Engineer/Interaction Designer’. I usually balk at the the term “engineer” (perhaps for good reason) but considering the presence of “designer” and the nature of the job post, I wasn’t too bothered.

FizzBuzzed.
When it came time for a technical interview with the lead developer, I felt pretty confident. Except for JavaScript “engineering” and anything related to algorithms, my technical skills are sharp. We begin with a great talk about style guides, Sass, the designer/developer phenomenon, atomic design, content, all those awesome things that get me super stoked. Then came the coding portion. I was anticipating questions about nitty-gritty positioning, semantics, maybe some UI based JS stuff, and development workflow. The first question was:

Interviewer: Are you familiar with FizzBuzz?
Me: Um, to be honest, no.
Interviewer: Ok, well, you have to write a program where multiples of three print ‘Fizz’ instead of the number and for the multiples of five print ‘Buzz’. For numbers which are multiples of both three and five print ‘FizzBuzz’. So it would look like ‘1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz, 13, 14, Fizz Buzz’
Me: (OMG MATH. I tried to talk through it a bit, but then said:)
Me: Ok, again to be honest, my JS knowledge is more regarding UI/UX based tasks. And I don’t really understand the point of the question. Like, what’s the use case? When would this come up in the role?

(Only after recounting this interaction to a friend did I realize you should not ask “why are you asking me this?” in a job interview.)

Interviewer: Well, it’s an exercise in programmatic thinking. No worries, let’s move on to the next question. Write a function that takes a timecode string and turns it into seconds.

Again I started talking through it, but it was impossible for me to figure it out with someone watching. I needed to do some serious Googling. He said I could email back my solutions. I toyed with the idea of calling up and saying, “forget it, this isn’t for me” but I decided to stick it out. After spending a few hours coming up with something that semi-worked, I found the solution on StackOverflow and, in my honesty, linked to it in the code.
Unsurprisingly, a few days after I sent my solutions I got a “you don’t have enough experience for the position, but we’d like to keep your resume on file”. In my impostor-prone state, I felt called out as a just-good-at-Googling-and-maybe-jQuery developer. I was embarrassed.
But yeah:
FizzBuzz dying in a fire.

After letting this self-doubt dissipate, a new emotion settled in: anger. FizzBuzz is a way to filter out fake programmers. I am fully aware that I am not a programmer, at least “programmer” in the sense of algorithms, data modeling, etc. 
Let’s go through the job description I saw (only slightly altered for anonymity). To me, this job description was definitely not for a programmer according to that definition.

UX Engineer/Interaction Designer
(…blah blah blah, we’re a great company and looking for a great person…)
Responsibilities

Create low and high-fidelity mockups to effectively convey interaction and design ideas (e.g. wireframes, sketches, ‘pixel-perfect’ mockups, etc).


Awesome. Except for the ‘pixel-perfect’ part. But maybe this could be an opportunity to help them update their processes.


Deliver engaging, innovative prototypes, and contribute to front-end development of our products.


Sure thing!


Collaborate with and synthesize feedback from other members of the team.


You got it.


Evaluate the usability of new and existing products, apply user research findings, and make constructive suggestions for improvements.


I’m in.

Minimum qualifications

B.S. degree in Design, Computer Science or related technical field or comparable practical experience.


Little problem. Feel free to contradict me, but can we agree that there isn’t such a thing as a B.S. in Design? And that Design and Computer Science degrees are wildly different? But I decided to let this slide. 


2 or more years of designing clean, valid, and compatible websites and applications.


Yes!


Knowledge of Adobe Photoshop and Illustrator.


For sure!


Clean and elegant visual design aesthetic.


Yeah!


HTML5, CSS3, JavaScript.


I’m a master at the first two, but since there was no mention of programming stuff and the responsibilities section was so design-centric, I figured my jQuery proficiency and capacity to self-teach would suffice.


Passionate about creating responsive and delightful interfaces and experiences.


My favorite!

Preferred qualifications

Experienced with Object Oriented JavaScript and modern JavaScript libraries such as Ember, Backbone, or Angular.


I’ve played around with these and understand the concepts. I wouldn’t say I’m proficient, but I definitely have ‘experience with’. Sure, this could be a lack in my qualifications for the position but again, the verbiage in the sections above is way more oriented around design and prototyping skills.


(blah blah stuff about self-motivation and communication skills)


So, where does FizzBuzz play into this? Sure, “engineer” is in the job title, but so is “designer”, “UX”, and “Interaction”. To me, that definitely doesn’t indicate a programming job. I wouldn’t have applied if I knew that.
It’s a problem.
I imagine I’m not the only one who’s had an experience like this. The job title conundrum is a known issue. But job descriptions are just as bad or worse.
Let’s take a look at a few more examples I’ve seen.

UI/UX Designer

UI/UX is far more non-descript than I’d like.

In addition to your experiences and capability with UI and UX design, if you accidentally mastered HTML, CSS, JavaScript, front-end development, then that would be seriously awesome.

Remember when you woke up the other day and were like, woah! I mastered JavaScript and didn’t even realize it! No.

Frontend Developer

Write front-end code in HTML/CSS/SCSS and JavaScript
Occasionally write front-end code in PHP (WordPress) or Ruby (on Rails)


Umm, PHP and Ruby are not front-end languages. Maybe they are talking about templating, but… no. Also, listing SCSS and CSS as required skills is suspicious. I smell someone listing buzzwords.

Frontend Developer: HTML5, CSS3, JavaScript
What You Will Be Doing
In this role, you will collaborate in designing, building, and testing world-class web applications. You will work across product, marketing, legal, business development, and operations teams to build and improve our core products. Test and deliver solid, reliable code that meets all requirements. Discover and experiment with new technologies and share with the team.

You will be the entire company. Not helpful.

What You Need for this Position

HTML/CSS
JavaScript Frameworks
CMS (WordPress a plus)
Adobe Create Suite
UI/UX
Eye for Design 


Very non-specific. 
Now for my favorite… 

Competencies

Creativity
Problem Solving
Dealing with Ambiguity
Customer Focus
Functional/Technical Skills


Lolz.
Sheesh.
Hopefully you get my point. 
Who is writing these descriptions? I’m sure these companies find a perfect match now and again. But I have a feeling that’s not the norm. It’s more likely that many of these companies just don’t know what they need so they look for everything. A recruiter or HR person whips something up and puts it out there to see who bites. Maybe they’ll catch a unicorn!
What’s more, based on my (albeit minimal) job application experience, who knows what will happen in the interview? I imagine you’d talk to a real designer or developer with a much better idea of the situation, and who knows how well that matches the job description, let alone the interviewee’s skillset?

I feel like it’s pointless to rant without proposing a solution, so here are some suggestions for whomever is in charge of this hiring stuff:

Audit your process and identify the gaps. Either hire a consultant or do it internally, but please look at the big picture, talk to a range of employees (junior and senior), and figure out where the pain points are. Don’t just interpret the opinions of dev/design leads and managers and lump their needs together.
List tangible, example tasks that are relevant to the position. Particularly if JavaScript is listed in the role (can you tell I’m a little sore about this?). Something like:

Implement image sliders and smooth scrolling
Migrating our CSS pipeline to Sass
Make quick design decisions about interactive elements, such as button hover states and form styles.
Create a registration form using AngularJS.
Use regular expressions to detect any date within text content.
Recommend improvements to our Rails deployment workflow.


Hell, put code examples in the description. Why not? Seriously. If I saw that I would be expected to sanitize data with pure JavaScript, I wouldn’t have bothered.

Storytime
That’s my story. I call it “Tale of a Non-Unicorn” because, going into this application process, I kind of thought I was a unicorn. They’d be lucky to have me. I’m a designer/developer if there ever was one. But, thanks to an erroneous job description (and JavaScript… grrrrr), I realize my unicorn-ness was a fallacy. Sad face. Except not sad face at all because business is booming at Lara Schenck, LLC.
I think other people have dealt with this. Yes? No? Am I just being bitter and snarky?

Tales of a Non-Unicorn: A Story About The Trouble with Job Titles and Descriptions originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.




Job Titles in the Web Industry
Chris Coyier — Wed, 14 Aug 2013 12:53:53 +0000
There are loads of job titles in our industry. The opinion on their usefulness range from harmful (i.e. leads to “not my job” syndrome) to vital (i.e. people change companies sometimes and need common language). Since they are out there and we use them, there should be some consistency to their definition. Perhaps we can get closer to nailing that down.
Let’s light this fire, shall we? This is all debatable, of course.

Job Titles
These are legit in my opinion.
Web Designer
If “designer” is in the title, the job is designing. Literally deciding and implementing how websites look and work. “Web” is in the title because the job is specifically focused on the web. Specific skills would be design-tools-of-choice, HTML, CSS, and light JavaScript.
If the job is also designing for print, apps, signage, products, clothing, etc., the title would be widened to Designer. 
Front End Developer
This job is focused on HTML, CSS, JavaScript, and light backend work. Not design. The lack of “designer” in the title is intentional. Because the job doesn’t require design, deeper skill in the other technologies is implied. You likely have a grasp on some concepts beyond the core technologies, for instance, regression testing or performance. 
A synonym might be Front End Engineer. I tend to think of that as a requiring a deeper and more specific skillset, possibly with more narrow focus or at a higher level. 
Technology specific job titles may be also be appropriate here, like “JavaScript Developer” or “JavaScript Engineer” for a job where that is primarily what needs to be done. Although, none of the front end technologies live in a bubble so I generally prefer Front End Developer.
UI Designer
This job is more about designing and less about implementation. Really good at design-tools-of-choice with perhaps only light HTML and CSS skill. A synonym might be a Visual Designer.
UX Designer
A specific focus on studying and researching how people use a site. Then ushering changes for the better through the system and testing the results. May not have or need any design or implementation skill. All jobs should care about user experience, but this job lives it.
Interaction Designer
Primarily design, just like a UI Designer, but with specific focus on how things are used and movement.
Art Director
The job is quality control, leadership of other designers, and client communication. A synonym could be Design Director.
Web Developer
This job is focused on back-end work and working with languages specific to the web, like PHP, ASP, Ruby, Python, etc. Medium skill in database/server work, medium skill in JavaScript, light skill in HTML. This is very different from a Front End Developer as there is little working with the design and heavier on programming concepts and concerns, like security and structure.
Synonyms could be Web Programmer or Web Application Developer.
Full Stack Developer
This job is a combination of front and back end work. Seriously, though, not mostly one and a little of the other. Good crossover people are needed at organizations and this is a high-end job. 
Content Strategist
Rather than working directly on implementation, this job is about the structural design of websites. Things like the taxonomies, metadata, scheduling, and analysis of content. A synonym might be Information Architect. They might work with people who work with content in a more general way like a Writer, Copywriter, or Editor.
IT Technician
This job works with the actual computers and tech equipment. A hardware person. 
Dev Ops
The job bridges the gap between IT and Developers. They handle things like server software, version control, deployment, build processes, and testing servers/processes. I wish this had a more job-title-y feeling to it. As it stands it sounds like what you would call the whole team of people with this job.
Product Manager
This job is about guiding the site as a whole (or a major feature of the site) toward a better future. Largely dealing with people and planning. A Project Manager would be similar but smaller in scope and possibly a temporary role rather than full job title.
Customer Service Representative
This job is about communicating directly with users of the site to provide help. Then triaging bugs/problems to the internal team. Also understanding/communicating the voice and vibe of the community around the site.
SEO Specialist
This is a big enough sub-industry that it can be its own job.
Job Title Prefixes
Any of these job titles can be prefixed with Junior or Senior. Junior meaning less skill/experience. Senior or Lead meaning more skill/experience. Responsibility and pay commensurate. The tech is the same.
Consultant might be suffix to any of these job titles as well, like a Front End Development Consultant, in which you offer strategic advice and help.
Bad Job Titles
The following are not job titles.

Ninja _______ – Cutesy and meaningless. It’s a recruiter trying to say “we want someone really good” but then shooting themselves in the foot.
Rockstar _______ – Same.
Web Master / Webmaster – It feels outdated and cheesy, but more importantly, never developed any specific meaning.
_______ Hacker – Cheesy for anything with the possible exception of a job with the specific responsibility of finding security exploits.
I kind of like Web Worker as a term, but not as a job title (too vague).
Mobile _______ – Even if the job has that focus it feels overly specific.

Not Caring About Titles
Like I said in the intro, the opinion on job titles is hugely variant. Right in the middle is not caring at all. If that’s you, awesome! That probably means you work for yourself or for some little startup where your title can be like “Lead Hucklebucker” or some other nonsense. That’s just good fun, live it up!
Not Web
Careful with these if the job is actually web related.

Graphic Designer – This has come to mean “design, but not web design.”
Software Engineer / Programmer – This has come to mean “programming, but not for the web.”

Conversation
Did I miss any important ones? Surely there is very specific job titles that are legit. That’s fine because they are specific. It’s the big general ones that we need to be concerned about. Did I get any wrong? Have you ever changed jobs and found it problematic? How does your organization handle it?

Job Titles in the Web Industry originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.