Events

Conversations that bring our community together

The State of Front-End Dev

Front-end dev is changing quickly, and plenty of readers are asking: what do we need to know now? During this event on November 4, an expert panel ranging from designers who code to engineers working across the development stack explored the skill sets, career paths, and technologies that make up this diverse field.

[youtube https://www.youtube.com/watch?v=hQWUKcLmf8Q?version=3&rel=1&showsearch=0&showinfo=1&iv_load_policy=1&fs=1&hl=en-US&autohide=2&wmode=transparent&w=960&h=540]

What we talked about

  • The changing face of front-end dev, and what that means for your work
  • Positioning yourself effectively with recruiters and hiring managers
  • Working successfully with a product team
  • Defining a career path that works for your goals and interests

Transcript

Chris Coyier: Hello and welcome everyone to the fifth A List Apart: On Air event! Our goal for these events is to provide a space for some deep expert discussions alongside some more casual Q&A for the audience, kind of like a meetup without all the hassles of geography. I guess that makes all of us in here right now “deep experts,” which is the first time I’ve ever been called that, I think. [laughs]

Our sponsor today for ALA:On Air events are the great folks at Pantheon. Pantheon is a hosting service for Drupal and WordPress. And when I say hosting, you may think “big, generic server in the cloud.” But no! Pantheon has this built-in system not just optimized for the server needs of Drupal or WordPress but designed to make even the sysadmin tasks easy; one-click core updates, automatic backups, Git integration, caching. It’s great, they’re great; that’s what the logo looks like. [laughs] Sign up for one of their guided tours or create a free account and start poking around at Pantheon.io.

Yeah, so thanks everyone for watching. My name is Chris Coyier and I’ll be moderating the event, so hopefully just kind of ushering the conversation and getting other people to say smart things—which I know they will because, secret, we did a preparation panel for this a couple weeks ago and it was so good, and I wish we’d recorded that also because it was an amazing conversation. I work on a web app called CodePen and I write about the internet stuff at CSS-Tricks.com and have a podcast of my own called ShopTalk.

But boring, boring, boring—let’s get into the far more interesting people. I’m going to introduce them quickly and then ask them an intimate question. Jina Bolton is here. Hi Jina!

Jina Bolton: Hello!

Chris: Jina is a senior front-end designer on the design systems team at Salesforce. And if you haven’t seen this, check it out: it’s LightningDesignSystem.com. It’s pretty impressive stuff; maybe she’ll mention that to us later. She also runs The Mixin, a San Francisco Sass & front-end meetup, and leads the brand and web design stuff for Sass—literally Sass, like the CSS preprocessor. Jina, how do you spend your day as a front-end developer? Like, after the teeth brushing and the...

Jina: [laughs] In addition to doing design and code for the design system that you mentioned, I spend a lot of time talking to designers and developers to kind of do that cyclical process of having the design system inform their design, but then also having their design inform our design system. So, that’s a lot of my day. [laughs]

Chris: Wonderful. We also have Una Kravets. Una, hello, hi, how are ya?

Una Kravets: Hi!

Chris: That’s a cool whiteboard behind you. It looks like you do lots of work during the day. Is there any secret stuff on there you forgot to erase?

Una: I probably shouldn’t be sitting here, but it’s fine. Just ignore this!

Chris: Okay! Una is a front-end developer on the cloud platform team at IBM. She started the DC and Austin Sass meetups and is a core member of the Open Design Foundation. Una, how are you productive during your day?

Una: I feel like I do so many things. I sort of work in that intersection of design and engineering or development, sort of making sure that things run smoothly and work together. Right now, I’m kind of doing what Jina does. I’m working on a style guide, so that’s been a lot of back and forth.

Chris: Ooh, is it secret still?

Una: It’s just kind of a way to mesh these worlds and ideas of how this product should look and provide something that’s performant, accessible, easy to work with. So, that’s the idea there. It’s been a lot of back and forth and talking, and figuring things out together.

Chris: Wonderful. That sounds like something a front-end developer would do. We also have Rebecca Murphey here. Hi Rebecca!

Rebecca Murphey: Hello! How are you?

Chris: So good. Rebecca, you are a senior staff software engineer at Bazaarvoice, and a creator of the js-assessment project, which maybe you could tell us what that is super quick, because I’m not even sure—is it, like, questions maybe if you’re going to maybe hire somebody in JavaScript?

Rebecca: It’s all sorts of things. It’s just a repo that I created a while ago, several years ago now, that people can use on their own to kind of get better at JavaScript, or use it as an interviewing tool. It’s just a test-driven tool for...there are tests, and your job is to make them pass with JavaScript.

Chris: Oh, nice. Oh, like Jasmine?

Rebecca: Well, they’re not Jasmine, but it’s like Ruby Koans or that kind of thing. So, it’s fun.

Chris: Cool. How are you productive during your day at Bazaarvoice?

Rebecca: ...I ask myself that every day.

Chris: [laughs]

Rebecca: Some days it’s like, “What did I do again?” But officially I’m the tech lead of a cross-functional product team of about 10 developers here at Bazaarvoice and I do a lot of JavaScript development on that team. But I also spend a lot of time just talking to people throughout the whole Bazaarvoice organization about front-end development and how we can do it better, and smarter, and faster.

[05:00]

Chris: Fantastic. And our final panelist, Marco Rogers! How are you, Marco?

Marco Rogers: Good, good.

Chris: Good. Marco, you are the head of engineering at Clover Health. Also @polotek on Twitter—you should definitely follow; he’s an important man to follow on Twitter, in my opinion. Anyway, how are you productive at Clover Health?

Marco: Yeah, I was hoping I wouldn’t have to, like, completely blow my cover really early, but I am an engineering manager these days, which means I don’t write very much code. But basically I’m head of the engineering team, so I spend most of my time trying to figure out how to keep engineers happy and productive, and more importantly, how to help them grow as engineers. So you know, at Clover we’re basically building better software for healthcare and health insurance, which is really important because a lot of their software is not great. But, you know, we have engineers who’ve been doing this for a long time and who are probably better than me, and ones who are like really just starting out. And so figuring out how to kind of put them on that growth path to becoming great engineers is what I’ve been thinking and spending a lot of my time on these days.

Chris: Nice. Marco, just tossing around the word “engineer” right and left. We’re going to get into that because that’s what part of some of the pre-show magic that we’re going to bring to you all very soon here. So we have at least half of this hour that we’re going to spend together at this wonderful Google Hangout, talking about things within this panel, things that we think are interesting—this is “The State of Front-End Development,” after all. So we’re going to do that and then hopefully field some questions from y’all, or from the world, about what you think about front-end development.

So, I thought this would be interesting. So, front-end development is a massive subject. We’re not even sure what falls into it. If we thought of it as a bucket or an umbrella or something, what goes into it or what doesn’t fall into it? So maybe we could maybe start with some obvious ones and then start with some un-obvious ones and see if they still fit into the bucket. So, group, could you please respond to me yes or no if you think this thing that I say falls under the umbrella of front-end development?

HTML?

Una: Yes.

Rebecca: Yes.

Marco: Yes.

Jina: Yes.

Chris: [laughs] Good start.

Jina: [laughs]

Chris: CSS?

Una: Yes.

Rebecca: Yes.

Jina: Yes.

Marco: Yes.

Chris: Everybody says yes. So HTML and CSS, definitely front-end topics. I’m nervous about the next one. Let’s just say it: JavaScript.

Rebecca: Yes.

Una: Yes.

Marco: I say yes, easily. But there’s a conversation to be had around that, I think.

Rebecca: [laughs]

Chris: There sure is. And let’s punt it, just for a minute. Let’s say configuring your Gulp file JS on your project. Is that front-end development?

Marco: Hmm...

Jina: I think so.

Rebecca: Maybe...?

Chris: Oh, we got a bunch of groaning and maybes.

Marco: Yeah, so it gets complicated at that stage, I think. And, you know, what is “front-end development”? I guess the hesitation comes from the fact that I’m not sure people should feel like they have to be able to do all of that stuff.

Chris: But just under the, “does it go under the umbrella or not?”

Marco: I think it does.

Rebecca: Sure. But then, like...well, I have a lot more absurd examples that I have to do, they fall under my job as front-end developer, but not...

Una: I think a requirement is being efficient, and that’s a big part of an efficient web development setup.

Chris: What about Sass, as in Syntactically Awesome Stylesheets that preprocess your CSS? Is that a front-end development thing?

Jina: Absolutely. Absolutely.

Marco: Yes.

Chris: What about HAML, then?

Jina: Sure.

Marco: Oh man, I was ranting on HAML recently, so I should probably abstain.

Jina: [laughs]

Chris: [laughs] Okay, just throwing that out there. How about Python?

Jina: No.

Rebecca: No, probably not. Depends on where you work, but probably not.

Chris: Okay, and when I say Python, is the answer equally “no” to Ruby and PHP and things that are often in that same bucket?

Jina: I would agree. Yeah, same bucket.

Chris: And not even should you...so this might be a can of worms too, but let’s say you’re working on a Ruby project. You should be able to work at the view layer, right? Like, “I have some data and I need to do something with it,” right? But that’s not the same? You’d say that’s not the same as knowing Ruby?

Jina: Yeah, I’ve worked at the view layer quite frequently; I would consider that front-end...uh, not so much. [laughs]

[10:00]

Rebecca: On the other hand, a project that I worked on for 18 months at Bazaarvoice had no backend, for all intents and purposes. Like, it was just an entirely client-side application and there wasn’t a server to worry about or understand.

Chris: Hm. But there was data, wasn’t there?

Rebecca: There was data, but we just consumed it. It was just JSON; we didn’t really have to know a lot about how it was made.

Una: The problem with just listing things is all those things can be a part of a front-end workflow and part of a front-end position, but are they requirements to be a front-end developer?

Rebecca: Right.

Chris: Well requirements aside, we’re just gonna jump into the bucket and then we’ll get into that. So how about this—how about is optimizing your JPGs and GIFs and PNGs, is that a front-end developer job?

Jina: Yes, absolutely.

Una: Yes.

Chris: Okay. So, what about making sure that those assets are gzipped when they come down. Is that a front-end developer job?

Una: I don’t think so.

Jina: No.

Rebecca: I think that you better advocate for that; even if you don’t do it yourself, you better make sure it gets done.

Una: I would agree with that.

Marco: Yes. That’s probably the best, most diplomatic way to...

Rebecca: [laughs]

Chris: [laughs] Okay. So, I like that this is in here, and we put this word in quotes, “awareness.” So, some of that “we’ve just got data,” like Rebecca was saying; “we don’t even know or care where it came from,” or “I can work in the view layer of Ruby” and stuff—you might call that “back-end awareness” or “server awareness.” Like, it’s not your job to know it all or how it was created or what buckets it goes in when it leaves your hands necessarily, but is that “awareness” kind of thing a front-end developer...?

Marco: I think absolutely. We definitely are going to kind of be in that gray area of what is a front-end developer, and my personal feeling about it is that gray area is totally fine. Like whether you’re doing it or kind of working closely with engineers who work more in the web server layer to do it, it’s kind of all part of getting things done. But in my experience, there’s a point where you are going to want to have at least some control over the data that you’re receiving, I think, if you’re building kind of non-trivial front-end applications. And so, that kind of firmly sits in that area for me. But I know some people may feel differently about it.

Rebecca: I think this all goes to, as soon as you leave HTML and CSS and start going further down the list, the more of these things you know, the better you’ll be at your job, and maybe the more jobs that you can get access to. That is something I would almost agree with Jina, that even JavaScript is not...you can absolutely get a job being a front-end developer with bare basic understanding of JavaScript, or maybe even less than that; it’s just that the pool of jobs you can get is limited. And every single one of these things that you add, the more jobs you have access to.

Una: But it’s important to also understand where your product lives, and understanding the ecosystem behind how servers work, and the browser, is an important part of understanding how your product is going to be used and accessed by people.

Chris: So, we have a “yes” on some server-level back-end awareness, and then we already talked about the optimizing of assets, for example, just as one thing, because we might put that in a bucket of network awareness, because it’s certainly like a front-end task to understand how the front-end of a website comes across the wires and ends up at a browser. So maybe it’s not your specialty, but having some awareness of how that goes down—are we saying yes, that’s a front-end-ish...?

Una: I think so. [laughs]

Chris: I’m going to go with “yes.” What about knowing a bit of SEO, like what Google thinks is a good website? Is that a front-end...?

Rebecca: I think that’s another thing, where if that’s a skill that you have, it will make you a more marketable developer. I don’t know if it’s a...I think it’s a skill that typically falls under the front-end heading, but you can get a job without it. You’d just get more jobs with it.

Marco: It’s kind of a question, right? But I can tell you that from experience, I’ve always been asked to do it in every single job.

Rebecca: [laughs]

Marco: So if experience says anything about it, then you just have to say “yes.“ Like, you’re going to have to—you’re going to be asked to look into that.

[15:00]

Chris: And I would think there’s some SEO things that are “use this tag, have HTML in this source order, don’t use too much of this garbage,” that kind of thing, which feels like that’s HTML, and we already said HTML is front-end. So perhaps, this is another big umbrella, but let’s just kind of get it out there so what we can talk about is bigger: UX. Is UX a front-end developer concern?

Una: It’s a concern, but I don’t think it’s a front-end developer “task.”

Jina: Yeah, I think it kind of falls into that awareness category we were talking about, but on a different side of the spectrum.

Rebecca: I would agree with that.

Chris: In perhaps a similar vein as SEO—well, I shouldn’t have said that, that’s a weird way to introduce this. Let’s have it be its own category here: accessibility.

Jina: I think that is an absolute requirement. I think it has to be.

Chris: Wow. Anybody disagree with that?

Marco: I say yes.

Una: I would agree.

Rebecca: I would agree. The business may not agree, but I would agree. [laughs]

Chris: And why is that, Rebecca? Because money, because time?

Rebecca: Because money and time, and I’m uncomfortable as I’m even talking about this because it is terrible that this becomes a money question. But we spent many months trying to make our third-party JavaScript application accessible and we didn’t do a lot of other things. And it was a real investment that we had to make, and from a pure business standpoint...it was morally right, but was it financially right is a hard thing to say.

Chris: Wow. And it was perhaps hard to get data on whether it was or wasn’t? Or you know that it wasn’t?

Rebecca: I mean...I think it’s a really important skill and it’s a really important thing for people to be aware of. Again, do you have to be an expert at it to go get a job? Maybe not. But it should be—in some ways, it’s almost like the gzip thing, right? Like, it should be a thing that you’re asking about and advocating for, and certainly there’s a lot of low-hanging fruit in accessibility-land that you should be advocating for and just making sure that you’re doing as a matter of course.

Chris: So maybe this “awareness” is there’s back-end awareness, server awareness, network awareness, SEO awareness, UX awareness, accessibility awareness...yeah, that’s fun. I promise we’ll stop after this, but what about Canvas or SVG?

Una: It depends on the job.

Chris: [laughs]

Una: Front-end development is so big, and I don’t think that’s necessarily a bad thing. Because it encompasses so many things, you can have different specialties within it. And ideally, if you work at a company that can hire multiple front-end developers, you can have them sort of specialize in different flavors of front-end development and then work together, have your own specialty, and just grow off each other and learn and build. That’s ideal.

Chris: Okay, so our umbrella we’ve established is very wide and we kind of, as a group, wanted to make that point because of how strange it is that front-end development not so long ago perhaps was a specialty and now it’s like, “Ehh? What even is it??”

Una: [laughs]

Chris: So that brings us into...this is a classic discussion, and a lot of people—it’s tinder for a fire—but job titles in the world of front-end development. There’s a bunch of them and I’ll just name some: front-end designer, front-end developer, front-end engineer, these types of things.

Jina: Front-end architect.

Chris: Sure, yeah. Visual designer. There’s so many of them. So if we took one that says—I mean, the title of this panel is “The State of Front-End Development,” so the job title that goes with that is front-end developer. Is it meaningful anymore? Does that say enough all by itself to understand what that job is going to be about?

Marco: I would say the point that’s important to make here is that—like today, the state of what happens on the front-end today, when you read job titles, you can’t actually get a sense for what they want you to do. You have to learn more to find out what the job actually is because the lines are so blurry and there’s so much there.

Rebecca: Yeah, I would agree with that, and I think that on the one hand it’s really exciting that front-end developer has become this profession unto itself. When I was starting, it was not a role that had as much credibility as I think it has now; I think it has so much more credibility now. But I agree with Marco, that you just don’t know what someone means when they say it. Just like the list of things we went down, some people mean all of those things. “Oh, and you also better know Java.” And some people really just want you to do more on the design side, and they don’t expect you to be implementing SEO strategies or getting into Ruby view, those sorts of things, so.

[20:00]

Una: Front-end developer is kind of the “webmaster.” That’s what we’re calling ourselves.

Marco: On the topic of titles, this is a really interesting one, because I remember the point where I wanted to call myself a front-end developer but would not answer to, like, “webmaster” or any of those. Like, it has evolved, I think, to a certain extent.

Jina: It definitely has. When I was at Apple, my job title when I first started out there was front-end developer. Would I call myself that now? No, because it’s become such a different thing. Like, I learned HTML/CSS, I never learned JavaScript but I knew enough to work around it. Now—we’re talking about job titles—when I hear “front-end developer,” I’m going to assume you know a lot more than me. [laughs]

Chris: So is it fair to say, Jina, that you straight up don’t call yourself a front-end developer?

Jina: Not anymore. I used to; I don’t anymore.

Chris: Wow, so you have removed yourself from the circle of front-end developer. What if I said, “Jina, are you a front-end designer?” Would you take that?

Jina: Uh, yeah. And you actually introduced me that way, which I thought was interesting, ’cause I would potentially say yes, even though that’s not technically my title now, ’cause then that kind of gives insight into that I’m a lot more focused on the design side of things, but I’m still doing HTML and CSS to build my UI.

Chris: Mhm.

Una: I think it’s the flexibility of it. To me, front-end development is...a front-end developer is just a problem-solver who uses web technologies to solve those problems or to build with. And that, I like having flexibility to be able to sort of go into a new language or a new field or idea, still this idea of problem-solving on the internet.

Chris: That’s one that we didn’t put into the bucket yet, but we could: is Photoshop, is Sketch, is Illustrator, is Affinity Designer—the knowledge of those tools part of the front-end bucket? I think maybe the day that the world split between backend developer and front-end developer, certainly those tools would’ve went with the front-end side! But does it anymore, or is that yet another third branch...?

Marco: This is why I feel like I’m extremely comfortable with Jina calling herself a front-end developer because, you know, there is a wide range of skills and all of them are valuable in order to get the thing done, right? And so, like for me, my relationship with Photoshop is I can open it and cut images out of it...

Rebecca: [laughs]

Marco: ...You know what I mean? But still, I need someone to be able to work with me to do that work, and we can both be front-end developers because we’re both required to get the thing done, and I’m comfortable with that. And so, I just don’t...I think this is kind of an interesting conversation, but I want to be clear that it doesn’t even really pay to try to draw a box around these things.

Rebecca: Yeah, and I think I’m kind of on the opposite end of this, where front-end developer, it’s a role that... There was a tweet the other day that Una mentioned that we were talking about before the show too, and that I retweeted, about how front-end developers—

Chris: You should read it, read it out loud.

Rebecca: Oh, well that would mean I would have to have it in front of me to read it out loud.

Una: I have it in front of me. Do you need me to read it?

Rebecca: Yes! Una, you read it and then I’ll talk about it. [laughs]

Una: It said, “Front-end developer is a job title that spans people who could barely use jQuery to people who could recreate it. This is a big issue.”

Rebecca: Yeah, I don’t know if I agree with the “this is a big issue” part of it, but I think it’s such a good encapsulation of the problem, that this term has kind of lost a lot of meaning. And I’m at a point where I’m kind of a wary of a front-end developer job, when an employer reaches out to me and says, “Hey do you want to be a front-end developer on our team?” What I do now is so different from what I did a few years ago when I would’ve used this front-end developer term that I kind of stray away from—I don’t know what to call myself instead, but front-end developer doesn’t seem right, either. It seems like it’s going to actually really limit the kinds of things I get to work on if that’s the title that I have. And I’m with Una in that this is about “I know how to solve problems using web technology.” The end.

Chris: Interesting. So I wonder if that’s going to lead us into a discussion about maybe not the titles not mattering so much as the descriptions and the actual, “what you do for work.” But let’s move to this just for a moment: there’s probably people out there who want to be front-end developers. I’m sure some portion of the people listening into this are interested in the role of front-end developer, want to know more about it and thinking, “What is it? Can I be one of these things?” Let’s roll with that for a bit. What type of person is good for this? Rebecca, you said that what you do now is totally different than what you did two years ago. Do you think that factors in? Do you need to be willing to reinvent yourself every two years to be a front-end developer?

[25:00]

Rebecca: Yes, I think so! I mean, I was working on something over the weekend that was like “I did not know how to do this two years ago.” Like, what I just did, this was scary and intimidating to me two years ago and now I’m just doing it, like, on a Sunday afternoon and not really thinking about it. I think you have to constantly be learning new things, and that has to be exciting to you, and you have to be okay with not knowing everything. You have to kind of accept that there will always be people better than you, and there will always be people who you have stuff to teach, and just be comfortable in this constant state of learning.

Una: I think a good front-end developer is always embarrassed by code that they wrote even six months ago, and I think that’s a great thing.

Jina: I’m embarrassed at the code I wrote yesterday. [laughs]

Una: [laughs]

Rebecca: [laughs]

Chris: Marco, when was the last time your job changed in a significant way? Was it last year, last month, three years ago?

Marco: Well, again, like I’ve said, I’ve been an engineering manager for a bit. And this is a tangent not totally germane to this conversation, but going from being a developer to being a manager is a job change, it is a career change, and people should think of it that way. But I won’t spend too much time on that soapbox. So just in the realm of front-end development, I would say that I actually kind of got into it from the opposite direction. Rather than kind of being interested in front-end development generally, I got into JavaScript, I kind of learned JavaScript as a language. I was actually doing JavaScript on the server in 2005, before it was cool, right?

Jina: [laughs]

Marco: ...And we were kind of on the JVM and using Rhino, and it was this kind of weird proprietary thing that they had built at the job that I worked at, and I really liked JavaScript as a language. And so, even when I left that job, I was kind of looking for more opportunities to do JavaScript. And then the front-end was the place where you got to write JavaScript all the time, so then that was kind of my intro to being like, “Okay, what is front-end development and how do I do that?”

Chris: Nice. You knew what you liked and then sought out more of that. I think Una, you’ve mentioned that same kind of thing before, right?

Una: Yeah, it’s kind of something you discover as you go since the field is so big, and it’s important not to go into it thinking, “I need to learn Angular, or I need to learn React.” It’s more important to sort of understand the MVC model, and understand why you’re solving problems in certain ways instead of just thinking very narrow-mindedly about certain technologies, which like we said, change every six months.

Chris: Wouldn’t it be rare to read a job posting that said, “I want somebody who’s willing to reinvent themselves every two years and understands the underlying concepts of...just generally knows MVC.” Like, you’re never going to read that, right?

Una: [laughs] It’s like, “We need SQL, Angular, Ruby work.”

Rebecca: But I think that’s a problem with the ads as much as anything. Like, the people buying developers, people that are hiring developers, they don’t know what they want either and they haven’t really distilled these down into these fundamental concepts and these fundamental skills and attitudes that you have to have. And I was talking with a manager at another company recently and he was saying, “We really found that we need a manager who understands front-end and understands UI development, because people who are used to managing back-end developers, they don’t even know how to manage this.” So, I think that change has to happen. At the same time we’re talking about this, the people doing the hiring have to be thinking a little bit differently about the real fundamentals they’re looking for.

Una: The other problem with hiring is oftentimes you just tell a hiring manager, “Hey, we need to find developers,” and they try to Google what that means, write something in the job description that doesn’t match up with what their employees are doing, and that’s where you get this confusion.

Marco: Yeah. So, this is actually a topic that’s pretty important to me, too. So in my last role, I was director of front-end engineering, and we had other kind of teams with functional expertise. Like, you know, we had the web layer and APIs and they worked in Ruby on Rails, and we had core services and they did the Java and JVM stuff. But the front-end team, people would kind of be talking to me about what skills you need to be on the front-end team, and people felt weird that I couldn’t give them a straight answer. Because we had to go through this whole spectrum that we’ve been talking about, like “Okay, I need people who just know JavaScript really well, and I need the HTML and CSS people.”

[30:00]

And it was also kind of a source of tension sometimes for the devs on my team because they were kind of given expectations by other people, like, “You can do the whole spectrum of front-end things,” and I had to kind of constantly try to convince people that that’s actually just not possible. Like, “Here are the people who do this kind of stuff and here are the people who do this, and together we do all the things,” right?

Jina: Right. That’s why you build a team in the first place. I was on the “front-end engineering team” at Apple. I was the least “engineering” person on that team, but I knew how to do HTML/CSS and how to architect the files, like how it’s organized and all that stuff. But then we’d have somebody who I’d work very closely with who was incredibly strong at JavaScript, is the type of person that can write his own jQuery. And so by having people on different sides of the spectrum, you can work together. I think that’s what I would ideally do if I were to build my own front-end team, is try to have—obviously you’re going to have some generalists, but try to get some people that are just incredibly strong at architecture, incredibly strong at understanding accessibility, or we mentioned SVG, things like that. That’s going to make an awesome team.

Chris: So do those people start as...well, who knows how they started, right? But we have this concept of maybe when you’re really early, you’re a baby front-end developer and you’re learning stuff, and you’re learning little bits and pieces, you’re for sure learning HTML and CSS because we’ve pinned those down as pretty fundamental front-end developer things. And then you reach what you might consider the midpoint of your learning as being a front-end developer. Is it at that point that it might be a good idea to become a specialist at one of those things, like you were saying, Jina, becoming an architectural specialist, or...? Do you think that’s a good move? Or do you just do what the job requires, or...?

Jina: I think it’s up to you. Like, you might enjoy being a generalist and stay that way, or maybe you just figure out you just really love SVG and that’s all you want to do all day.

Rebecca: I also think you don’t have to be intentional about this. Like, I didn’t set out to, “oh, I’m going to be good at architecture.” I think that it just kind of—for me, at least, maybe it’s different for other people—but for me, it just kind of emerged that I’m good at architecture and please don’t make me make something that actual users have to use in a user interface sort of way. Like, please. I’m terrible at that.

Jina: [laughs]

Chris: Which is different than Marco. As Marco said, “I’m writing JavaScript on the server. I like it. I want to continue doing this, please give me a job where I can continue doing it.”

Marco: Yeah. Well, and in the same vein, though—so, getting into front-end development and calling myself a front-end developer, and I learned kind of the HTML and CSS as well, but when it got to that design-y part and people were like, “Hey, can you make it look pretty?” I’m like, “No. No, I can’t. That’s not...” You know? [laughs]

Jina: That’s where I would come in. [laughs]

Una: You can’t become a “master” of something or a “specialist” if you’re not good at it; you can’t just do it because it’s what something tells you to do. You discover it as you go.

Chris: Let’s bring a new word into this thing. We have a question from Vito Goh, who writes here, “Front-end developers are usually associated with being a jack-of-all-trades, but masters of none. Do you think that a front-end developer should try focusing on a single area where he/she is most strong at?” So it’s the same thing we were just talking about, but what do you think of this “jack-of-all-trades”? Can “jack of all trades” be your specialty? [laughs] That’s weird to say, but...

Una: I think the “jack of all trades” is the awareness of all of the parts of the front-end. But you can always be a point person for a specific technology or a specific aspect of front-end development within your work.

Rebecca: A lot of my role these days is not to know how to do everything, but it’s to know all the things that need to be done and to know the questions to ask and then to appoint a specialist maybe and say, “Hey, can you go figure out how to actually do this thing? I know that we need to think about it.”

Chris: Project-level awareness.

Rebecca: Yeah. And so I think that’s what being a jack-of-all-trades—I think being a jack-of-all-trades comes in when you’re starting out, it’s really good to try lots of things and see where your specialty is. After that midpoint you were talking about, I think it makes a lot of sense to specialize and continue to specialize, but broaden that “awareness” word that we keep using...

[35:00]

Chris: I like it.

Rebecca: ...as you focus on your specialty. Some people call it “T-shaped skills,” which is such a manage-y thing to say, but.

Marco: You’re right about that, because I was also going to say that.

Rebecca: Ah, I beat you to it! Sorry, Marco! [laughs]

Marco: If I was weighing in here, what I would say is that developers in particular, we have this kind of really awesome luxury in that we can actually have some say over what kind of job we do. In most places, when you go in and they give you a job, you can’t say like, “I don’t do this, I only do that.” Like, that’s not really a thing. [laughs] And so, in a lot of ways I think people should take advantage of this luxury by having an opinion on the kind of things that they feel like they want to get good at and going deep into that, or being the best kind of version of that that they can be. And that includes whether you want to dive deep and be just like that really awesome JavaScript engineer, or whether you want to be that really awesome front-end designer who can kind of run circles with CSS and HTML and also kind of put it into a nice design and UX. Like, those things are highly valuable and it really depends on finding the job that’s going to let you do that, because there are—like across the board, people need these skills and you can find that role. But you have to look. You know, we were kind of talking about the job descriptions, and you have to find out if that’s the role that they need because the area is so kind of gray today. But yeah, all of those things are hugely valuable today, so I don’t even know if it pays to kind of try and pin it down, like I said.

Una: Here at IBM, we’ve sort of split up “front-end developer” into places on the spectrum. So there are different types of front-end developer that just fall in different places along that design-through-engineering back-end spectrum.

Chris: This is related to this and I think it’s really interesting: so far we’ve been talking about what is front-end development and the particular skills and stuff, but we haven’t talked so much about what is it like to be that job in the context of the organization you’re at. And we’re all from very different contexts: Marco at Clover, Una at IBM, Rebecca at Bazaarvoice, and Jina at Salesforce, and I’m like on a tiny little team of my own little devising. We all come from very different sizes and scopes of places. So Christopher Jones writes in, “What is the difference in responsibilities with working at a small shop, a medium shop, or a giant enterprise, mega-multinational corp?” Is the job still the same or does even the job change a bunch?

Jina: That’s another one of those “it depends” questions. I’ve been on small teams, big teams, small companies, big companies, startups, agencies, enterprise. It’s all different. Even comparing one startup to another, it’s just all different. I’ve been the sole front-end person plus sole interaction designer, so I was doing a little bit of everything. When I was at Apple, I was on the front-end team, so all I did was write HTML/CSS and I missed doing design, so I had to move to the design team to do design. The team I’m on now, it’s really awesome. The role that I have didn’t really exist the way that it exists now at the time, but I knew what I wanted to do. Now we have a team of people doing it and it just came out of knowing what you want to do. In my case, I love style guides, I love design systems. I just chose to work on it and now we’re working on it, which is awesome. [laughs]

Chris: You chose your own destiny there, which is fun.

Jina: Yeah.

Una: And also just because you work at a huge company doesn’t mean that you’re on a big team.

Jina: Yeah, my team is actually pretty small.

Rebecca: And there are also huge companies that still have teams that just have one front-end developer on them. For a product team to have one front-end developer, I think that’s not a reasonable thing, but it happens. [laughs]

Jina: [laughs] Yeah, I wouldn’t recommend that.

Chris: I love this one by Anastasia Lanz on Twitter: “Should front-end developers have three monitors?”

Rebecca: [laughs]

Una: Wait, what?

Jina: [laughs] I have three monitors. I love it.

Chris: [laughs] How many monitors does it take to be a front-end developer?

Marco: I think all developers should have at least two monitors.

Rebecca: Wait, does your laptop count as one, or is that...?

Marco: It can, I guess, if you, you know, you wanna...

Jina: Yeah, in my case, my laptop counts as one.

Rebecca: Alright. I only have two. Three might be a lot...

[40:00]

Chris: Max Pshenichnikov is a professional HTML and CSS person, he considers that as part of his profession; is good at responsive web design but not so much JavaScript, and he thinks the words “front-end developer” mean Angular, Ember, React. I tell you, there’s lots of people like that; you just name the technologies right now and that’s the requirement right now to call yourself FED. Are we rejecting that as a concept, or...?

Jina: I am.

Una: I think that’s a problem that happens when you read job descriptions super closely and use that as a basis of what you’re going to learn, because there’s nobody that’s going to be using every single one of those technologies at a single position probably, unless you’re teaching it.

Jina: There was a really cool thing from—I was on a panel at CSS Dev Conf, and I forgot who said it, so I apologize to whoever said it, but they said that the job listing of all the things that they want is just a wish list, it’s not a list of requirements, it’s really a wish list, and I thought that was really cool.

Rebecca: But I think it’s an interesting question. Like, what should you call yourself when you’re really good at HTML, CSS, and responsive design? Like, is it a front-end developer role, should you put that, and will you be discounted if you put that, and you don’t have Ember and Angular? I think that’s the thing this person is worrying about, is, like, “What do I call myself that people will respond to and not have wrong expectations of me?”

Una: I feel like I struggle with this all the time, like this whole...I don’t really do any visual design, so am I designer when my specialty is really, like, working with HTML and CSS? I use JavaScript, but I wouldn’t say I specialize in that compared to other things. But then, I think I’m a front-end developer. I don’t think I’m an engineer, but I’m not a designer... It’s just...

Chris: Does it give you anxiety or not? You feel fairly—

Rebecca: She looks a little anxious! [laughs]

Chris: Your work speaks for itself, though. You’re a confident—you’re doing good work and have a good job and stuff. Not to say that you don’t deserve to be anxious sometimes, but do you... There’s a question that goes along with this, is the idea of feeling overwhelmed. So Jim Webb writes, “How do you personally learn about new tools and frameworks without feeling overwhelmed? It seems like every month brings a hot new JavaScript build tool or application framework. It’s easy to feel like you’re not good unless you already know it.” So, I know tons of people feel like—there’s jokes right and left about it. You can’t go to a conference without somebody making a bunch of jokes about, “Days Until Last JavaScript Framework Dropped” and it’s always one, or whatever.

Una: [laughs]

Chris: Does it matter? Because you can’t just say it absolutely doesn’t matter, because it is breeding anxiety in this industry a bit, about not knowing those things.

Una: That’s why the concepts are the most important thing, and then choosing technology as that becomes a problem that you need to solve in your work.

Rebecca: Yeah, I think this goes back to what I was saying earlier, that you kind of have to—to survive in this field, you have to be okay with not knowing everything. It’s important to be aware—and we keep using that word—aware of these things, but you learn to be—I learn to be okay with not knowing all of this. And I think a lot of it is just, make sure that you are working with new technologies frequently, but don’t feel like you have to work with every new technology that comes out. But just the practice of working with some new technology on a regular basis will make you good at working with other new technologies in the future.

Chris: Is it because you’re a good problem-solver, then? Lindsay Lee Siovaila: “When looking to hire someone for a developer-type role, would you agree that the ability to solve problems with technology is as important as knowing a bullet-point list of languages? Someone might code well but not know how to apply them to solve a problem.”

Marco: This is kind of a really important question, right? I’m learning a lot, over the last several months I’ve been having similar conversations with people and not really understanding that this is a source of anxiety for some people, where they’re like, “Are my skills the ones that are actually in demand?” It’s really kind of eye-opening for me. I’ve talked to those people who have kind of said, “I’ve gone really deep in Angular, and I know Angular, and that will get me a job.” And there are places where knowing Angular really well will get you a job. But, if you were to kind of, say, come and apply for a role with me, I’m going to say, “Well, the team’s using React. Are you cool with that?” That’s where you want to be; you want to be able to say, “Oh, I’ve been doing Angular for six months, but if I gotta switch to React, yeah, I think I can handle that.”

[45:00]

There will be some learning process, but yeah, it’s all the same stuff, right? Like underneath, you’re doing the same thing and building out kind of front-end capabilities. And so when we talk about having that foundation, that’s really what it’s about, is kind of knowing the foundation of how the browser works, how the web works, and then that will give you the basis that you need to learn any of the new technologies that are popping up. Because they’re just not doing different things, right? Like, the browser really only kind of does what it does, and then you can put a bunch of stuff on top of it to make it look different, but it’s the same stuff. It’s DOM, it’s CSS, it’s all the same stuff.

Rebecca: I think too that these frameworks mean that a lot of these other skills become more important. Because the frameworks take away a lot of the complexity, and once you learn one, then you learn another, and then you learn another, and then you start to see how they’re a lot the same. But there are things that they don’t solve for you, like perhaps how you do your builds, or how you write tests, which we haven’t talked about at all, or how do you engineer for performance, and how do you do accessibility? All these things, there are so many things that frameworks don’t answer for us still. They answer a ton of things, but having that broad set of skills becomes valuable in the framework world.

Una: The ability and desire to pick up these new skills and concepts as you go is I think the most valuable thing that a front-end developer can bring to a company.

Chris: So let’s go on that for a minute. Can you interview someone and get the correct answer to that question? Do you think a good interviewer can figure out if someone’s a good problem solver?

Una: I like to ask how they learn and where they learn. And if they can come up with a bunch of answers to where they’re getting their new technology information from, it shows me that they care and that they’re interested in it, like legitimately and sincerely.

Chris: You’ve done some interviewing, right Rebecca? Do you look for that?

Rebecca: Yeah, we absolutely look for that; we look for how people approach a problem. And we’ve actually been switching to more of a take-home exercise approach rather than a “stand in front of the whiteboard and write some code for me” approach to try and let people have a more realistic experience and let us see what they do in a more realistic environment. Yeah, we try to give them a real problem to solve and then see how they approach it and see how they think about it. We’re having some success with that; it’s a little bit early to tell.

Marco: I would agree. So we switched to kind of doing take-home exercises a while back, and I would highly recommend it for anybody who is interviewing. It does a lot to eliminate that kind of performance anxiety of coming in and performing code on a whiteboard in front of people. Like, not everybody is going to be good at that, and I think the traditional interview kind of optimizes for people who have gotten good at that. But I would echo what Rebecca’s saying, absolutely. Like, we want to try to evaluate for people who have that learning ability and that adaptability. I’ve interviewed a lot and none of them test for frameworks—like none of it.

Chris: Oh, really? So that’s actually kind of a good sign, isn’t it?

Marco: Yeah.

Rebecca: Yeah, and if you tell me that you’re an expert in a framework then the first question I’m going to ask you is, “What are its shortcomings?” because I want to know that you’ve thought critically about this and not just jumped on a bandwagon, but that you’ve thought critically about it and you can see its flaws, and you can tell me where it shines, too. We definitely don’t talk about frameworks here while we’re doing interviewing.

Marco: Oh man. I apologize, but I have to be that person who runs and gets the power cord, because I’m going to run out of juice here in a second.

Rebecca: [laughs]

Chris: “How many power cables does it take to...” That’s good, it’s worth it. So, one of the things that’s just a fun little hot topic that we could bring up is the idea of junior versus senior versus whatever’s in the middle of that. Is there a...I don’t know, what is like the moment in which you become senior, or is it 100 percent arbitrary?

[50:00]

Jina: [laughs] A little bit of both.

Una: ...That’s what you want, you want somebody who can extend their expertise on to others and become a multiplier.

Chris: Is that it, is that the thing? Like, you only get to be senior once you’ve leveled up your ability to teach?

Una: Yeah, I think—I used to work at a company called Viget, and something they looked for when they hired was people who are good educators of others. I really liked that approach to looking at front-end development, plus these senior positions.

Rebecca: Yeah, I think Una’s word of being a multiplier is a huge thing. And I would also say that even when you—I don’t know, I have “senior” in my title, but there are so many ways that I don’t feel senior. The more senior you get, the more you realize how many people are still better and smarter than you, I think. [laughs]

Chris: Okay, okay. So, let’s go with this. I think we should broach salary, but compared to rather than an exact number for now, how much more “money valuable” do you think a senior person is compared to a junior person? Is it like a 2× kind of scenario, or...? Or is that too uncomfortable to talk about?

Jina: I live in a weird city to talk salary because people make a ridiculous amount here in San Francisco. [laughs]

Chris: But that’s why we’ll use a multiplier instead of a number.

Jina: I’m not actually sure what the multiplier should be.

Chris: I feel like this always shuts people down.

Una: Look at the value of the work. A senior developer who is teaching others and becoming a multiplier is extremely valuable in a lot of ways.

Chris: Right.

Marco: Yeah. I just walked back into this conversation, but I obviously have a lot of opinions—

Chris: We’re all just naming our salary, Marco. You’re last.

Marco: [laugh] I did that; I actually did that last year. There was this whole #talkpay thing on Twitter, it made people extremely uncomfortable, but I think it’s important to talk in real terms about salaries. I’ll try to answer your question as a hiring manager. It’s not going to be 2×, but it is going to be a significant difference in salary if you can demonstrate that you have not only kind of senior technical capabilities but that you can be that force multiplier—you’re going to make everyone else around you better, you’re going to do that mentoring, you’re going to provide that leadership and direction on the team. Those are highly valuable and I think people kind of deserve to be compensated for that, not just because it’s valuable to the company but you want people to aspire to be that, right? Like, you want everyone kind of saying, “How can I actually be a multiplier on my team?” and that is going to bring rewards. So, I think it’s really important.

Chris: I love that we’re using the word “multiplier” a lot. If anybody is confused by that, what are we saying exactly when you say multiplier?

Marco: So, the way that I define it is—I talked early on about how I see my role, my job as how do I put engineers on a growth path, how do I build a team that is super effective, and that tomorrow we’re going to be more effective than we were yesterday because everybody is kind of learning and growing? Continuing to learn and grow as an engineer is not a trivial thing, particularly in front-end, because we’ve talked about how the pace of things is moving so quickly. So when I talk about being a force multiplier, what I mean is the people who can grasp these concepts really quickly and then help bring other people along in doing that.

So there’s a thing where you can have the really smart person that goes off in a corner and they kind of build tools, and then they kind of deliver them to the rest of the team to use. Or you have that person who kind of goes and connects with the team and says, “Hey, let’s really learn how to do this stuff in React, let’s really learn how to develop these patterns,” right? Doing code reviews for people, pairing with people and creating more engineers that can actually be kind of fully independent and autonomous. I have people on my team, like I said, who this is their first engineering job ever, right? And part of my role and the role of the team is to provide them an environment where they’re growing. Like six months from now, they should be teaching other people, right? And so people who enable that growth are really valuable, and those people should—that’s just kind of how you should look at it, is they’re a force multiplier.

Una: And maybe reaching out to designers and teaching them how to code and becoming an enabler of other people around you. The best way to grow a technical community is to introduce it to non-technical people, and there you’re even growing past your little community of front-end developers. You’re becoming somebody who’s multiplying across the company.

[55:00]

Chris: Can you be senior and still have imposter syndrome?

Jina: Absolutely. [laughs]

Una: And don’t think you have to be senior to be a multiplier as well. You can do that at any point, you can always make your community around you better. Like, the job title is not a requirement. We kind of talked about how job titles in this whole session are a little arbitrary in this field.

Marco: I’m glad you mentioned that, because I guess the point that I’m trying to make that I think is a really important distinction is being that force multiplier is a requirement for senior, right? Like, it’s not just the deep technical knowledge, right? A person can be senior on my team even if they’re not rebuilding jQuery. Like, that’s just not what it’s about; it’s about having that impact on the rest of the team and the rest of the org, and that’s really important, and you don’t have to have the deep technical knowledge to do that.

Chris: Very, very good. So, nobody thinks here that being senior means five years. Nobody thinks that?

Rebecca: [laughs]

Una: I hate those things so much! [laughs]

Jina: Yeah, I don’t think it’s tied to a timeframe at all.

Chris: Interesting.

Una: There’s no sense of being able to pick up skills. Just because you can pick it up in a month, I think that makes you a better front-end developer than somebody who would need to take the five years to pick up that skill.

Rebecca: I want to say, I don’t think that there’s a “Five years? Check. I’m senior.” But I do think that there is some amount of experience that you can’t cram, you can’t get it in a month. And having that experience and having that perspective and being able to say, “I remember two years ago when I tried this thing that you’re talking about. It didn’t go well and here’s why,” some of that you just can’t cram that into a month, or six months, or a year. And I think that a lot of times when people come to me and say, “How do I get better at JavaScript? How do I get better at front-end development?” it’s like... It just takes time. It takes time and experience and learning things and failing, and you can’t do that in a month.

Una: Yeah. I would agree with that, actually. That’s a great point.

Marco: I would agree with that. I do think when I say experience though, it’s less about time worked and it’s more about the actual things that you’ve built and shipped. So, you know, I’m very much kind of in that camp, where there’s five years of experience kind of doing the same kinds of things and you haven’t learned a whole lot outside of that box that you’ve been in, and there’s like a year of kind of really intense and dynamic environment where you’ve learned a ton and you’ve had a lot of failures, and you come out of that being a lot more experienced than if you had kind of stayed in a certain space for a long time.

Rebecca: For sure.

Chris: There was a question in here, that as we come to wrapping up a little bit, that asked us to kind of revisit that list of things. We started this whole thing out as, “let’s talk about the umbrella,” or the bucket or whatever that kind of turned into, a swimming pool of things that are all front-end development.

The only ones that were 100 percent agreed upon really were HTML and CSS, and then it branched out from there to things like design and JavaScript and preprocessing and build tools and backend technologies. And then we started talking about this concept of awareness, like server awareness and network awareness and accessibility awareness—or maybe not even awareness for that one. There’s a lot of questions in here that are saying accessibility is not an optional skill in here. So just to give the community more of a voice there, I think a lot of people feel pretty strongly about that one, and good on ya. There might even be kind of legality awareness that goes with that. And then we started on about testing—we didn’t even touch DevOps—we barely touched testing.

So, there’s the swimming pool of stuff that all kind of lives under front-end development, and job titles are failing us, job descriptions are failing us. I don’t mean to sound too negative about all of this, because certainly people are working and getting paid and work is getting done, so maybe it’s just a conversational weakness. But I thought we could perhaps do final thoughts on some of that, if y’all have any dying things you have left to say.

Una: It seems like front-end development is just like Finding Nemo, you know? You’ve gotta “just keep swimming.”

Rebecca: [laughs]

Chris: [laughs] That’s so good.

Jina: Yeah, I guess in a way you can kind of look at it as like talking about photography: you’ve got film photography, you’ve got digital photography, you have phone photography. There’s so many ways you can take it, but you’d still consider yourself a photographer I guess, no matter which route you take. So, I don’t know. It’s just one big, giant pool. I like that metaphor. [laughs]

[1:00:00]

Rebecca: I think I would say just be patient with yourself. This is a long road and it doesn’t end, which is really exciting and fun.

Chris: Sounds like a Grateful Dead song or something.

Rebecca: [laughs] Yeah, just be patient with yourself and help the people around you and you will get better.

Jina: Absolutely.

Chris: Marco?

Marco: Uh yeah, so, final thoughts. I guess for me, it’s kind of acknowledging that the space of front-end development is kind of exploding right now, it’s a really exciting time to kind of be in this space. And I think people should kind of embrace how dynamic it is and how in demand it is, and just really kind of find where you fit, right? There’s really no rules for this—if there’s nothing else you got out of this, there’s no rules for this. Like, the thing that you like to do in the front-end is valuable. Learn it and then go find the people who are going to pay you money to do that, because this is the time.

Una: Yes!

Chris: Great final message. Thank you viewers, thanks to everybody who tuned in and listened and is listening later on YouTube or wherever this thing gets syndicated to. We didn’t even talk about RSS. That’s important, right?

Jina: I forgot all about RSS. [laughs]

Chris: [laughs] It’s like Twitter. Mark your calendars for December 2nd. Captain Jeffrey Zeldman—I should say Dr. Zeldman, because he’s bringing back “Ask Dr. Web,” which predates probably anybody in here; I’m aware that he did it but we’re all too new school for that stuff. But he’s going to be reprising that for a special Q&A event called “Ask Dr. Web” coming up December 2nd.

Watch for updates; they’re going to add the video of today’s panel in the next couple of days with a complete transcript of all this for, you know, accessibility reasons and SEO reasons. Thanks to Pantheon, that’s the logo for them. I hope that’s the right corner. I’m going to point to this one just in case there’s some weird flip thing that happens. But they’re the hosting sponsor for all of this. Check them out at Pantheon.io. Thanks to Jina, Marco, Rebecca, Una. That was a really excellent talk, so hopefully we’ll do it again sometime.

Una: Thank you.

Marco: Thanks.

Jina: Thank you.

Rebecca: [waves goodbye]

Format

Google Hangout
30-minute panel chat
30-minute audience Q&A

Aired

Wednesday
04
November 2015
1-2 PM EST

Featuring

Chris Coyier

Chris Coyier is a web designer and developer. He writes about all thing web at CSS-Tricks, talks about all things web at conferences around the world and on his podcast ShopTalk, and co-founded the web coding playground CodePen.

Jina Bolton

Jina Bolton is a Senior Designer on the Design Systems team at Salesforce. She is passionate about style guides, Sass, and whisky. She organizes The Mixin, a San Francisco Sass & front end meet up, and she also leads the brand & website design for Sass.

Marco Rogers

Marco Rogers is head of engineering at Clover, a data-driven health insurance company. Formerly, he was director of frontend engineering at Yammer, where his team made terrible browsers do awesome things. He's been building web applications for more than 10 years, and he liked server-side JavaScript before it was cool. He gives conference talks, publishes articles, and sometimes writes small novels on Twitter.

Past Events

Web Typography & Layout: Past, Present, and Future

Can typography encourage long-form reading—not just scanning? What are the most exciting areas of cutting-edge experimentation in typographic technology and digital layout, and what new skills will we need to design tomorrow’s web content? Three experts—Mozilla’s Jen Simmons, publication design legend Roger Black, and ALA’s Jeffrey Zeldman—discuss typography and layout on today’s web: where we are now, and where we’re going.

Ask Dr. Web—Live

Design your career like you’d design a website. Listen in on this recording of our fearless leader Jeffrey Zeldman and his co-host Sarah Parmenter answering audience questions about their web careers.

The State of Front-End Dev

Front-end dev is changing quickly, and plenty of readers are asking: what do we need to know now? During this event on November 4, an expert panel ranging from designers who code to engineers working across the development stack explored the skill sets, career paths, and technologies that make up this diverse field.

Love Your CMS

Selecting and configuring the “best” CMS can bewilder and confound, but worry not. Eileen Webb, Karen McGrane, Jeff Eaton, and Ryan Irelan take you through customization, traditional versus “headless” CMSes, design, backend UX, and more in this hour-long event recorded live on August 25.

Pattern Language: Responsive Style Guides

We know we can’t just design fixed web pages anymore—so how can we manage efficient workflows while accounting for the intricate systems and infinite variability that are today’s responsive sites? Style guides to the rescue! Well, sort of.

Sass Talk

Sass. Less. Compass. Grunt. Gulp. If you’re overwhelmed by tools like preprocessors and taskrunners—not to mention all the complex setup advice out there—you might be wondering: can we even write vanilla CSS anymore? In this event from Wednesday, May 6, 2015, we asked a panel of developers to share their stories, strategies, and case studies.

Designing for Performance: Can We Have it All?

Everyone wants sites that are responsive, beautiful, and fast. Do we need to make tradeoffs? And whose job is performance, anyway? In this event from February 26, 2015, we asked a panel of designers and developers from both in-house and agency teams to share their stories, strategies, and case studies. Watch the video or read the transcript here.

About our events

Bringing the feel of a local web meetup to the online space, our community-focused sessions discuss the events of the day—or hour. We bring together experts and readers for realtalk—not just presentations. Join us to hear new voices, ask tough questions, and take our community’s conversations further.