Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier. Chris, how are you today?

Chris Coyier: I am doing so well. A nice day.

Dave: What a wonderful another week. We're in the month of May here.

Chris: I bought a new bicycle. I feel like I have too many bicycles. I have to sell some, but I live now, recently-ish, in Bend, Oregon, here like up on a big hill, like a really tall hill.

Dave: Okay.

Chris: Which I feel like there's plenty of -- especially in this land of fitness that I live in here that there's plenty of people that power their way up this hill all the time, but it's just too much for me. As much as I like bicycling, [laughter] it's very ambitious hill to climb on a daily, and I wanted to, so I bought an electric bike. I feel like that's how I'm connecting it to this technology program. It has a motor on it, and it helps me power my ass up that hill on the daily.

Dave: Oh, yeah. You got the hybrid there? That's nice. That's a good move.

Chris: Yeah, it's pretty cool. It's pretty cool, and I got a kid's seat on the back of it, so we can plunk around on long journeys and it won't kill me.

Dave: Well, and I think that's crucial, right? [Laughter] If you've got to get up the hill and with a kid, you're going to need some power.

Chris: Yeah.

Dave: I just bought a bike, too. A lot of my friends, one weekend, showed up and they're like, "Hey, we all bought gravel bikes off of Craig's List."

Chris: Hmm.

Dave: I was like, "Oh, okay. I guess, do I need to do that?"

Chris: Gravel is the funnest.

Dave: They were like, "Yeah!" And so, I was like, "Okay." Then, thankfully, I found one and it was great, so that's a good bike, so it's a nice little hobby.

Chris: Highly appeals to me.

Dave: I need more hobbies that aren't….

Chris: I made sure that this one was very gravel capable as well, which is good. I still am keeping my regular bikes. I like normal bicycling and mountain biking as well.

Dave: Yeah. Well, so I went down to the bike shop near my house, which is kind of, you know -- those in Austin will know the 360 loop. It's like a bike loop that goes down this street called Mesa, and then up this highway called 360 on the west side or town or, like, northwest side of town.

There's a bike shop there. I walk in and it's owned by an Italian guy named Nello. He's like, "Uh…"

I was like, "Hey, do you have gravel bikes?"

He's like, "Why would you want one of those?"

I just was like, "Well, you know, my friends have it, you know, and Austin, because--"

He's just like, "No. Or I could make you one from this $10,000 road bike, but no."

He was almost refusing it, but I just was like, Austin is very, like, you'll be riding on a street, a path, or a trail and then, all of a sudden, it'll turn to literal gravel. [Laughter] So, it's like you literally want a gravel bike for it because that's the terrain. So, anyway, it was weird to convince this guy who was so in the road bike scene, and so when you start getting into bikes, you realize this is a full-time job to know about all this stuff because there are different brakes, different shifters, different components. It starts just getting wild and more expensive and more expensive.

Chris: Well, you're happy with it. That's good.

Dave: I got a good one, so I feel like I lucked out. The bike gods shined upon me, so I just need to take it out more. I don't have e a great regimen and schedule. This goes into probably a developer health conversation, right? I just don't have, like, okay, for lunch I just go ride my bike.

Chris: I know. That really would be nice, wouldn't it? It's so easy to convince myself that I absolutely just don't have time today. There are a million things vying for my attention and it's very easy for me to fill my day with all of those things. Going for an hour bike ride is not one of them.

Dave: All right. This is the new show. Okay, we're just complaining. But I think this all touches on dev problems.

The other day, I got a call, a phone call, and it was like, "Hi, this is State Farm. You haven't paid your homeowner's insurance policy and it's due today by midnight or else you don't have house insurance." I was like, "Oh, no. How did I miss that?" I think I'd seen a bill for it come through, but I obviously didn't act on it.

I was just sucked up into work tasks and things like that, I just didn't even have bandwidth to pay my house policy, which keeps me in my house, like I don't default on my loan or whatever. It was just such a shocking moment for me that I went into Notion. I love Notion, right? I went into Notion and wrote down every responsibility I could think of on a daily, a weekly, a monthly, a quarterly, and an annual basis.

Chris: Woo!

Dave: Just wrote down every single thing I think I am responsible for in my life. You know?

Chris: Yeah.

Dave: I have kids. Not all of that stuff was on there.

Chris: A lot of it was, though?

Dave: A lot of work stuff. You know?

Chris: Yeah.

Dave: Stand up for this team or this project has this thing or this project has -- you know?

Chris: Yeah.

Dave: My mind was melting, and so it was like, okay, I need to quantify this because I'm obviously drowning if I am defaulting on my homeowner's policy. It was a bit of an embarrassing moment for me, but it all factors into this exercise stuff, too. It's like I don't have time. I don't even think, like, "Hey, I have 2 minutes or 20 minutes. I should go for a little bike ride." I just think, "Oh, I should check Twitter and make a joke." That sucks, so what do I do?

I don't know. It's all kind of factoring into this developer health thing. How do we do all the things we do and do work and--? I just don't know, so….

Chris: Well, it's the most painful when you feel like your aspirations are at odds.

Dave: Mm-hmm.

Chris: You're like, "I just want to be the kind of guy who says he goes mountain biking every day because that's just so cool. Why did I choose this life that I get to make all the choices in my life and I'm trying to be entrepreneurial and make it in this world if that doesn't also equal some interesting freedom?"

Dave: Mm-hmm.

Chris: But instead, this choice, it's almost like the people I know who just work 9:00 to 5:00 have way more freedom and do way more interesting things that I do and aren't pulled a thousand directions all the time. I have these aspirations to heavily succeed in business and be as good of a manager as I can be and get the best out of people that I think I can be and just have all these goals that I want to achieve and have all these life goals that have nothing to do with business. They are family goals and health goals and friendship goals and things. They fight each other, and it sucks that they have to.

Dave: Yeah, because there is a limited amount of time, right?

Chris: Yeah.

Dave: You just literally can't fill up anything, and I think about things like agile or whatever, right? Clearing tickets off a Jira board. I think that only works if you're an employee, like you work for one company on one team and have a very limited set of objectives that you're trying to accomplish in that team. Otherwise, it's so much stress to have 60 issues in the backlog just waiting for you. You finish this issue. Guess what? You've got another one. You jump. That's so much stress to kind of bear.

You can survive it and pace it and say, "I only care about what's actually on here," but then I feel like you don't see the holistic product. You lose sight of the whole entire product if you're just looking at the board. That's, again, very specific to my life, but I'm just like, "How do you accomplish this?" I don't know. "How do you meet these goals?" is sort of the question.

I don't know, so I started. I just took all my responsibilities and I just wrote them out because I just was like, this is what I want to do. I'm going to consider biking a responsibility. Who knows if I'll get to it, but at least, hey, I have a responsibility. I think the next step would be, I'm going to schedule time on my calendar to go bike and maybe I'll stick to it, so ha.

Chris: [Loud exhale] Good luck to us all in these tricky times.

We got one from Kurt Petrick who is asking specifically about a JavaScript API. He asks, "Is it ever okay to use the dot innerHTML method on an element? I understand that you would never want to display anything the user generates using innerHTML since it can lead to cross-site scripting attacks that use innerHTML to update the DOM directly."

Meaning, if you wrote a really basic application that had an input in it and you typed "Chris" into it and all that you did was grab that value and innerHTML it to some H1 tag somewhere or save that to a database and showed that to your friend in a chat app that, yes, that is an XSS vulnerability because I couldn't just write "Chris." I could write "Chrisp" end script tag, start script tag, alert, cookies. Meh, you know. Certainly, yeah, when you're just jacking stuff into the DOM, which is something that the innerHTML method is for that you do have XSS stuff to be thinking about.

He goes on to ask, "One thing I've tried is creating a container element with .createelement instead and then using innerHTML on the container to create child elements." I guess you're working with a document fragment at that point or some kind of in-memory element, temporarily.

"Then I add classes and I do all that stuff and then just do one innerHTML at the end or append child or whatever to do it," So I guess you're kind of avoiding innerHTML if you do all the creation of elements and stuff and then append it at the end.

I think Kurt is just afraid of innerHTML. Maybe he's read something or something that suggests that this particular JavaScript API is just dangerous to use for various reasons. What do you have to say about that?

Dave: Well, I think you're right to kind of be a little hesitant, right? You think about Facebook. They actually renamed or, in React, it's not innerHTML. It's dangerously set innerHTML or something like that.

[Laughter]

Chris: Right.

Dave: That's the API because it's basically like, "Hey. You can. It's okay if you have a piece of trusted DOM that you wrote, I guess, or got returned from an API." In theory, I think you could just chuck that in there. But if you're just like, "Hey, user, write whatever, and we'll just spit it out on the page," CodePen is probably an amazing example of this. A JS app that you write whatever code you want and it'll spit it out on the page. That can be dangerous.

In general, I think you just kind of have to be careful with that. This is where formats like Markdown really shine.

Chris: Yeah.

Dave: You don't have a WYSIWYG writing HTML. It just writes Markdown, which then you parse or translate on the server side. Even on the client side, you may want to use a Markdown filter or something.

Chris: I don't know that create element and append child and stuff is inherently automatically safer in any way. They're not. That's not. I think that's a false statement.

Dave: Yeah. I tried to remember, but there's a new thing called insert adjacent HTML or whatever, which is supposed to be like a replacement for just innerHTML or insert adjacent element or whatever.

Chris: It feels like wherever you chuck new stuff into the DOM, re-rendering is going to happen and none of those APIs promise you that what you're injecting into the DOM is safe.

Dave: Mm-hmm. Yeah.

Chris: All of that stuff is on you. Maybe there are other problems with innerHTML that don't immediately come to mind, but I feel like to have some trepidation, like you said, is good. Of course, you should. Even data from an API, even from your own database, you should be careful about what you just toss onto a page. You should probably have some safety mechanisms for that.

These are really low level APIs. This is as low as it gets for manipulating the DOM in JavaScript in the browser. Other things use that. I'm sure somewhere in React's code is it innerHTML things sometimes.

Dave: Mm-hmm.

Chris: Maybe there's some new way to do it, but you have to use this stuff. It's not like this API is automatically bad. That would be irresponsible for us to say, "Oh, you say innerHTML in a tutorial? It's time to leave a comment that says that's dangerous and should never be used." I don't know that there are any JavaScript APIs that just get a blanket "don't use it." Occasionally.

What's a really bad one? Document.write or whatever, I think that one is pretty ubiquitous in, like, this is so problematic for websites that it maybe should be outright banned. [Laughter]

Chris: Yes.

Chris: I don't think innerHTML is on the outright banned list. It's on the "know what you're doing" list.

Dave: You know a good thing would be something like a to-do app or whatever. I think you have to learn how it works. If you can type a script alert, "Hi," in a to-do task and then the website, when it renders your alert, it now just says, "Hi," you have a problem. The trick is escaping that data. You need to kind of, like, okay, I have a user input box so, any time somebody types into this, I need to make sure I escape it either when I save it to the database or save it to the object in memory.

Chris: Or both.

Dave: Yeah, or both. Yeah. Just make sure you -- what is the saying in security land? You basically never trust a user. I think we all do that ideal state.

What was it last week? We were like, oh, we're doing playdates. We made a playdate app for our friend. I think everyone is like, "Oh, yeah." I think you just have to be in a more defensive posture for any kind of user input and assume somebody is going to try to hack this playdate app or post something not safe for work or malicious. You just have to kind of assume that posture.

You can't just assume the best of people. I think that's just kind of how it goes. That's almost just responsibility 101 in both design and development. You can't just be naive about it.

Chris: Mm-hmm. Mm-hmm.

Dave: You have to be cognizant and ready for that.

Chris: That's a good way to put it.

[Banjo music]

Chris Enns: An Event Apart is the premier Web design conference for UX and front-end people just like you. Each event they put on is three days of design, code, and content for interaction designers and developers packed with tips, techniques, and insights into the future from industry shakers and shapers. If you've been in the past, this year they've adjusted things so that all their shows in 2019 will be 3-days long with at least 17 speakers for each. If three days is too long to be away from home or the office, they also offer a one- and two-day conference passes as well.

The next event coming up is in Washington, D.C., from July 29th to July 31st. There'll be folks like Jeffrey Zeldman, Sarah Parmenter, Eric Meyer, Rachel Andrew, Jen Simmons, Sarah Drasner, Laura Martini, and a guy named Dave Rupert and more, all giving talks loaded with information to help you just build websites. They've also got conferences coming to Chicago, Denver, and San Francisco. For full details and registration information, visit aneventapart.com today.

Our thanks to An Event Apart for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: Dan Shields, I guess, writes in here. What does he have to say?

Dave: Dan writes in, "It's easy for me to understand that adding an ARIA label makes the page more accessible but understanding what the ARIA label should be is more difficult. For instance, is it best practice to use the ARIA label for different information than it would be in an alt tag or an image or a title tag on a link? Should the ARIA label read more explicitly? Example: a photography of blah-blah-blah document in a case or blah-blah-blah document in 1919."

Chris: Yeah.

Dave: Dan is looking for best practices around … assistive tech.

Chris: There's an attribute. It's an HTML attribute. It's ARIA-label. What does it do, Dave?

Dave: ARIA label is cool because it is the label that the screen reader will read.

Chris: Isn't it rather powerful? It overrides what otherwise would be said for that…

Dave: Yeah, it's like text important. [Laughter]

Chris: Yeah.

Dave: It's how it works.

Chris: All right. I'm closing my eyes.

Dave: Close your eyes where I'm going to be the screen reader, right? We're going to go through your home page. Ready?

Chris: Mm-hmm.

Dave: Click here. Click here. Click here. Click here.

Chris: [Laughter]

Dave: Click here. Click here.

Chris: Yeah.

Dave: That's not helpful, right? Visually, it probably makes sense because it's like some product and then you're saying, "Click here." It's like, "Oh, that makes sense because it's all tied together visually."

ARIA-lly, especially in this podcast medium, it is not connected together, so you would want to, basically, use ARIA label there on the button because you need to understand how people navigate with screen readers. There are ways to navigate screen readers just by, "Show me all the links on the page," or, "Show me all the form elements or form buttons on the page."

Chris: Yeah. Yeah, yeah. If you put ARIA label on a link that says, Click here," and you write in there, "Go sign up for product," when you tab to it or get focus on it, I will not say, "Click here," right? The "Click here," is gone.

Dave: Yeah. Yeah, so let's say it's a pizza website. It would say, "View pepperoni pizza. View sausage pizza. View meat lover pizza." There is a way you can inject more information. Even programmatically, from a database, it's kind of like, you have to be like, "Okay, how can we do it a little better?"

An accessibility purist might say, well, all those buttons shouldn't just say, "Click here." I think they may be right in most cases. But real world, you don't get to decide the label on the button text, but you want to do a good job, so ARIA label is awesome for that.

One limitation of ARIA label is it's not translatable, so like if I run the site.

Chris: I've heard this. Yes, right, because it's an attribute. It's not actual content or whatever.

Dave: Right.

Chris: Yeah.

Dave: I would hope Google Translate can fix that, but if you go to a foreign language page and Google says, "Hey, this is written in German, do you want to translate this to English?" You say yes, of course, because I'm not good at German.

Any ARIA label would still be in German, the native language of that page. I would hope that this can eventually get fixed on the tech side because that's kind of an arbitrary limitation there, but it does make sense. It's just concerning itself with the text.

Chris: Yeah, well, I've heard that -- and I learned this from Sara Soueidan just recently because let's say the use case for this is an SVG icon and you need to put a label on it because you're not putting text next to it. Usually, the correct answer with iconography or whatever you might want to say is to put a word next to it that's the interactive development. The icon is just there visually because it's a nice design and might enhance some understanding. Whatever. Every website in the world uses icon, so I don't think I necessarily need to defend them.

Let's say that you don't have room aesthetically or, aesthetically, it's not what you want to do or something. This is a standalone icon that's interactable. Hopefully, that's not confusing anybody, but let's say then that you focus it with assistive technology. You could use ARIA label on that SVG that says, "Hamburger Menu," or, "Open Menu," or, "Toggle Menu," or something so that it's labeled, so that when you're focused on it, it says what it's going to do, which is an improvement.

But there are two ways you could do it. You could use ARIA label, or you could use ARIA labeled by. "ARIA labeled by" then takes a selector that it's going to point to, probably the ID of an element that exists kind of within it. In SVG land, you can say, "ARIA labeled by," the title element. In the title, you could put, "Toggle Menu." Now it's not an attribute anymore, so it will be translated. Yeah?

Dave: Hmm. Yeah. Yeah, see, that's like a trick, right?

Chris: Yeah, which opens up the question of, why would I ever use ARIA label if "ARIA labeled by" allows for translation, in a way? I think somebody asked Sara that at the conference and she had a very eloquent answer to that, so watch the Smashing Magazine San Francisco 2019 show to hear her answer that.

One of the answers was, "Well, sometimes I'm a little lazy," or that kind of thing. But she had a better answer than that, and now I forget what it was. Sorry.

Dave: Yeah. Well, I'll definitely check that out. Yeah, "ARIA labeled by" is pretty cool. I think the weird part is it uses IDs and you're like, "Oh, I have to put an ID on this little piece of text."

Chris: Yeah, right. Do you point it to span that you then visually hide and it becomes a little ergonomically tough? Is it always an idea? I feel like, in SVG land, you just put ARIA labeled by title. No, but you have to put, then, like ID title on the title element to point to it properly.

Dave: Yeah, yeah.

Chris: Yeah, okay.

Dave: Yep. Yeah, but that's not the end of the world. I would say, title tag on a link, Dan mentioned that's kind of an anti-practice. It was very popular a long time ago, but people abused that so much that screen readers kind of quit reading the title tag on an anchor link, so that doesn't even work anymore. You need to have text in a link.

If you have a link with an image inside and the image has alt text, it'll read that alt text as the label. The tree kind of goes down and says, "Oh, yeah, this links label is the alt text on the image," so that's cool. Not all images need alt text or the need the alt attribute, but they don't all use….

Chris: What about this? He's kind of asking about, "Should an image have an ARIA label on it?" I think not, right? That's what the alt text is.

Dave: An image? Yeah, that's what alt is for. I would use tried and true alt, but Dan specifically asks, "Should it read explicitly, like, a photograph of blah-blah document in a case?"

The advice I've heard is, you don't need to say, "A photograph of," or "A screenshot of," or, "A picture of." People get it. The screen reader just said, "Image." It just said, "Image: a photograph of blah-blah document." It's like, "Yeah, duh, it's an image."

It would be better to be like, "Image: blah-blah document, 1919." Then if the user is more curious, like, "Okay, I'll go look up blah-blah document." But if there is more context that you're trying to get, like, "Oh, look how ragged this Constitution is. It's all fallen apart," you could say, "Tattered Constitution, 1919." That would be a little more descriptive. If there are adjectives you're trying to pull out of that thing, do that.

Sometimes, if it's text, screenshots of text, you'll want to just kind of relay the text like, "Two people talking. One says this. One says that," or something like that.

It's tough, and how far do you go? Do you explain the whole gif? Like, "Jerry Seinfeld awkwardly leaving a theater unimpressed," or something. How far do you take it? I think it's kind of up to your judgement. What information does the user need from this image? It's tough, but I think, "If you do a good job, you win over customers," would be what I say.

[Banjo music]

Chris Enns: This episode of ShopTalk Show is brought to you by Discover.bot. Discover.bot is an online community for bot creators designed to serve as a platform agnostic digital space for bot developers and enthusiasts of all skill levels to learn from one another, share their stories, and move the conversation forward together. Discover.bot was built by Amazon Registry Services and it's an informational place for novices and experts in the bot development space.

Discover.bot regularly publishes how-to guides and the latest bot building resources. Some recent guides are: How to Design a Bot Personality, How to Set Up Payments Through Your Bot, and How to Stop Shopping Cart Abandonment.

Discover.bot also shares expert advice and provides insights on all things bots. For example, what KPIs are worth measuring, why emojis may be breaking your bots, and how to write an engaging chatbot dialog. They cover all sorts of topics and genres including bot development, bots for business, chatbot news.

If you're new to the bot development space, Discover.bot will teach you everything there is to know about bots. There's a guide called Beginner's Guide to Bots, which will teach you how bots were invented, the basics of how bots work, what bots can do, and where bots were developed and published.

If you've already got a few bots of your own, Discover.bot can help you choose a framework that's aligned with your business. For example, e-commerce, travel, finance, hospitality, and more. They've got a great guide just for you called Guide to Bot Building Frameworks. From NLU features to platform connectors to APIs, there is a lot to consider. Find out what all the major frameworks have to offer, so you can choose a chatbot framework that fits your objectives.

To find out more, go to Discover.bot/shoptalk so they'll know you came from us and check out Discover.bot. Our thanks to Discover.bot for sponsoring ShopTalk Show.

[Banjo music]

Chris: Let's do another one. Shall we?

Dave: Sure.

Chris: Will Loose (phonetic) said he's got his first senior developer job at a company. Congratulations, Will. The company itself is moving from "move fast and break things" kind of thing like, "Ah! Deliver all the code! Let's get market share!" phase to growing up a little bit.

He says, "Now, we need a professional code base phase." "It's an Angular site," he says. I don't know if that matters. Maybe we'll think about that. Maybe we won't.

He says, "The things that need to change are somewhat obvious, like let's add tests. Let's reduce duplicate code. Let's clean up logic where we can. But I keep finding that I'm asking myself the same question."

Here's that question. "How can I prove that one version of the application is better than another; that my change has improved this to be a more professional code base than it was before? As of now, there are no metrics being gathered that I can use to drive my decisions on what needs to change. I don't believe that there's a need to change something on a hunch or because the community says I should or that there's chatter that one framework is better than another or whatever. I'd like to hear how you would approach this problem."

I am fascinated by this. It does seem obvious to reduce duplication and write a test for something and clean some things up. Some of these things are a little at odds with each other. I'd say that adding a test on top of existing code is just a straight up improvement because you're just verifying that something works. You're adding some new code that doesn't touch the code that you've already written. You're just making sure that it doesn't break in the future. I'd say that's great.

To just go in and be like, "I'm going to change up this logic to a way that I think is better and more logical," that to me seems in the territory of just like danger for danger's sake, almost. I understand complicated logic being a problem and something that is heavily desirable for desires to clean up, but it's dangerous. Maybe wait for it to break and then fix a bug when it does.

I don't know. I want to pass this to you in a minute because I think this will be fascinating, but I wanted to share a little anecdote. I'm just stealing this from Twitter. I can't remember who said this, but it was somebody who says, instead of referring to code as legacy code, they referred to it as legendary code [laughter] because it should be honored for doing its job. It's battle-worn code. Maybe it's not as beautiful as you think it was, but it's been doing its job, probably.

If it hasn't been doing its job, sure, great, fix it; refactor it. But to change something for change sake because you think it's a version of growing up, I think maybe growing up is knowing when not to refactor code. [Laughter]

Dave: I have a lot of thoughts on this. Where do I start? [Laughter]

There was a great post by Dion Almaer from Google Chrome called The Doomed Rewrite. I can put a link here in the show notes. It's a good story because he works with companies through Chrome, like helping them with their perf, you know. Basically, he's like, what happens if you do the rewrite and it's not better, it's slower, it's worse, it's not even easier to work with? You're like, "Oh, yeah. We made a prototype and the prototype is awesome. Therefore, it's better. Therefore, we should go all in on this."

But you get there and it's like, "Yeah, it's even harder to work with. Webpack keeps breaking on us," or something. "We have to do everything all over." There can be other problems you don't know about yet that make it even worse. The rewrite doesn't always result in success, and I think that's an important thing to realize.

In that post, he references The Monty Hall Rewrite by Alex Sexton. Alex Sexton is referencing the Monty Hall problem, which is this idea of, you are on Let's Make a Deal, and I show you three doors. Chris, pick a door. Pick a door. Behind one of these doors is a Ferrari.

Chris: One. Yeah.

Dave: Okay, one. Okay, there's a goat.

Chris: Awwww!

Dave: Womp-wa. Would you like to keep the--? Maybe it's not a goat. Maybe it's a Cuisinart. It's a new blender, Chris.

Chris: Yeah.

Dave: A new blender. Would you like to just keep this new blender or pick another door? That's your choice. Pick another door. One has a Ferrari and one has a goat. Which would you like to do?

Chris: [Laughter]

Dave: You have this Cuisinart locked in. Which would you like to do? Would you like to stay with the Cuisinart or would you like to pick another door?

Chris: I'm going to pick another door.

Dave: Okay. Well, you made the right choice, so the idea there is you had three options, right?

Chris: Mm-hmm.

Dave: One, two, three, and you opened the door. Now you know one of your options, right? Now it's just a bet. Either you're going to win or you're going to lose. [Laughter] But you've now seen a third of the board, so you now kind of have even better odds.

Chris: Yeah.

Dave: It's kind of a weird probability thing, but now you have better odds of winning because you've seen more of the board. You know?

Chris: I love this.

Dave: It's a weird statistics thing, but the statistics say you're better off at picking a door even if you lose. The statistics prove out that you have a better chance of winning if you open the next door.

Chris: Is one of the doors a pit of despair at some time? I feel like I kind of can't lose. I'm either going to get a goat, a Ferrari, or a Cuisinart, and I'm kind of cool with any of them, really.

Dave: Yeah, and the Cuisinart is kind of what you have.

Chris: Yeah.

Dave: It's kind of the thing you already have. Then Alex's thing is, maybe just go for the rewrite because you have a chance of winning, like getting out of your technical debt.

Chris: Mm-hmm.

Dave: That's my feeling right now, working on this legacy Java app. We are at the point where the tech debt is exploding in our faces. Knowledge loss has happened, and people have left. We're hitting that point where it's like, okay, we need to actually make a huge change. Who knows? Maybe Angular isn't going to be fast enough, but something needs to change because we need to update this.

I think rewriting for rewriting sake isn't good. Is there incremental improvements that you can do? That would be one thing, but you need to improve things.

Who was it? Was it Karolina Szczur who wrote about technical debt? Is that right? Uh…

Chris: Oh, yes. Fox.

Dave: Fox. Yes. I murdered your last name, Carolina. I apologize.

I was trying to find this post because it was on Medium, I believe.

Chris: It might have been on a company blog, though. Wasn't it? I don't know.

Dave: Company blog. This is getting even harder.

Chris: Sorry.

Dave: Anyway, @fox on Twitter wrote about technical debt. It was a good point, I felt. She was saying, a lot of the times we call things technical debt and they're not. You're just saying, "I don't like it," [laughter] and that's not technical debt. Technical debt is kind of like--going back to the original definition--you said, "I'm going to make a shortcut here. I'm going to borrow from the future, right now. I'm going to make a shortcut and borrow from the future."

Chris: Right.

Dave: Stability or best practices or the ability to code myself out of the problem from the future. That's technical debt. You've willingly made a decision to code fast and break things. Now you have to rethink it.

Chris: Yeah. I feel like I almost need a better understanding because I throw it around pretty regularly because it feels pretty real to me at CodePen this far in is that we're fighting some of it, but still experience plenty of it. Our decision-making, I feel like, is guided by technical debt sometimes.

I had a bug this morning that came in where somebody was looking at a pen in full page view and their regular view, but it used kind of like a complicated combination of features and they were comparing it to a different one. The staff was kind of looking at the bug and trying to figure out what it was. It kind of came down to, there's a couple of different ways that this pen can be rendered. In one way, the logic just didn't account for this weird combination of technologies in the way that the other way that the pen can be rendered did.

Why do we have two ways to render a pen at all? Why are there two different views that do this? The fact that there was at all was an early version of technical debt, which was that, "Oh, this solves some now problem to have these two views because it's somehow easier to get done."

Now, us looking at that now, I'd call it technical debt. The debt is that there are two ways to view this pen and they're fighting each other. There are inconsistencies between them. The fact that there is two of them at all, to me, feels like the definition of technical debt. To refactor this is to make it one view such that these type of problems can't exist because there is either a bug or there's not. It's not this, like, "Oh, there are bugs sometimes and there's not." The sometimes bugs being the worst kind of bugs, you know.

Dave: Mm-hmm. Yeah. Yeah, and I think I consider that technical debt, too. I think Karolina's view is maybe more strict on what is and isn't, but I think what she's driving at, too, is this idea of bad design, like putting out a bad design or something, isn't technical debt. That's just doing bad. You know what I mean?

Chris: Right.

Dave: She's kind of like, "Please don't call being bad, technical debt. You made bad decisions and you need to now dig out from your bad decisions." I think I like that.

Yeah, for me, technical debt is when you're afraid to work on it. Afraid is sort of, I guess, a subjective term, but people just kind of avoid it or don't want to refactor it or fix it or even work on it because it's just such a gnarly little piece. That, to me, is technical debt, to me, just because it's like, "Okay, that's something we coded and the rules around it aren't very clear or the tests aren't there," or something. That, to me, strikes me as the technical debt. We made a choice to write this without really documenting what it does or why it does it. That's technical debt.

Anyway, I would say, it sounds like maybe you did, Will. You moved fast and broke things. Maybe it really is helpful to clean things up.

I will say, just in my recent experience, adding tests is big, especially for refactoring, so you know that when you fix something, it'll be easier to fix something with those tests in place. You don't have to go and ask, "Hey, what did this thing do, again?" You have the tests in place.

Who is it? Oh, I'm blanking on her name. Oh, she's a Rails developer, Ruby-ist.

Chris: Sandi?

Dave: She is very good -- Sandi Metz. Is that right?

Chris: Yeah. Mm-hmm.

Dave: Metz, Sandi.

Chris: I don't know, but I've read a bunch of her work somewhat recently because of how good she is at identifying complexity. She writes very boldly about this and be like, "I can look at your app and know what breaks based on metrics," [laughter] which I think is baller.

Dave: Yes.

Chris: [Laughter] And she's probably right.

Dave: I've watched so many Sandi Metz talks on YouTube. Go look up any of them. She just kind of walks through refactoring and gives you practical tips on how to dig out of bottlenecks and stuff like that. Yeah, baller is the perfect way to describe it because you're just like, "I want Sandi to come and fix my code." [Laughter] "Can I please have that?"

Yeah, so she's really good at it. I definitely recommend that you go and find any YouTubes you can with her.

Chris: That's great. Good luck, Will. I think you've got your head on your right shoulder.

I feel like it's an irony. I was thinking about this in the last episode, too, about how people that write into the show with their thinking about the problems they're experiencing are almost inherently on their way to solving those problems already. It's nice for us to talk about and, hopefully, we can be helpful sometimes. I think we're probably, generally, more helpful to the random listener of this problem than the person who actually has the problem themselves because I feel like sometimes people write in and then miss us talking about them. [Laughter] Unfortunately, we don't send you an email receipt saying when we're going to answer your show and in what episode and at what time stamp. You've kind of got to just listen for it.

Dave: Yeah. That would be pretty nice if we did that. Maybe we can figure it out.

Chris: It would. It would be good. Whatever. The fact that you're thinking about these things and writing up your thoughts on them in the context of sending us a question, I hope is unlocking some thinking for you anyway, so good luck with that.

Dave: Yeah. Thank you, listeners, for writing in because A) that gives us something to talk about but B) I think it helps, too, to share. Your problem can help. Other people can benefit from, I guess, hearing your problems and knowing they're not in a boat all by themselves. I think that's very helpful.

Also, I wish -- I don't do this, but I wish I did more is just ask whatever question I have on Stack Overflow. I don't have that skill, and I wish I did because I do like to use chatrooms or Twitter for lazy Web questions. Man, I wish I just would go to Stack Overflow and be like, "Why is this thing weird?" You know?

Chris: Yeah, especially if it's straight up a question because then you're contributing to the knowledge base of the world. Thank God enough people do that that it's already pretty nice anyway.

Yeah, I work with Cassidy Williams and I feel like Cassidy does that all the time. She has some muscle memory to just be like, "Oh, here's a problem we're having. I'm just going to write it up quick and throw it on Stack Overflow."

How many times have you landed on a Stack Overflow that doesn't have 692 upvotes? It has two, but it's still useful.

Dave: Mm-hmm. Yeah, all the time. Well, and then you don't -- like, you're just documenting your problem, almost. You can still work on it and think it through, but you've just said, "Hey, here's a backup plan. I've initiated protocol X that somebody will maybe answer my question in one to five days," or something like that. You know? At least give us a direction on it. That's kind of killer, especially if you're slightly out of your wheelhouse on a Rails app or a Nuxt app or something like that.

I wish I just was a little more bold. I think Stack Overflow got popular just after I started learning. Does that make sense? My learning phase, my three, five years of learning, intense. It started right after that. I wish it was more of a habit, is what I'm saying.

Chris: I like it. Let's ask a Stack Overflow question. It's almost like a power center of that kind of thing. Nobody talks about it that way, which is fine, because I think it's a great company and whatever. The fact that you're saying that and not saying, "Just ask the question on your blog with your comment thread or something," is kind of us just saying, "No. Maybe a power center is good in the land of a developer hive mind." I don't know.

Dave: Yeah. Yeah.

Chris: Dangerous, unless they do something super shady or whatever, which I don't know that they have, so far, at least in my knowledge, which is something to say to be around for that long and not have screwed the pooch. [Laughter]

Dave: Not have some kind of venture capital scam. [Laughter]

Chris: Yeah.

Dave: Maybe we just don't know yet, but all right.

Chris: This is an interesting one from Victoria Radishkova (phonetic). She's been at her job for 12 years and writes, "I know in this industry is suicide."

Dave: Uh-oh.

Chris: I'm like, is it really?

Dave: [Laughter] Paravel just hit the 12-year mark.

Chris: Well, it feels like -- you know, what did we learn recently? That the average time to spend as a developer in Silicon Valley is a year, or was it less than a year?

Dave: Something like that, yeah.

Chris: I don't know, but even a year feels like, really? That's as much dedication as you have to these companies? Okay, I guess. Maybe there's something weird with career ladders.

To be in there 12 years, I would think, like, doesn't that prove that you're super loyal and you get bonus points for that? Maybe not these days. I don't know.

I would value it. I think that's cool, Victoria.

Anyway, I found that there is -- I love this question because this is what I've been talking about in my conference talks recently. I found that there's no such thing as a Web designer anymore. You're either a UI/UX designer, purely visual, or a Web developer in which case you need to know Angular, React, or something as a must.

She's finding this kind of middle ground not a thing anymore, so looking for a job has been super challenging, starting with the job title. "I've seen so many titles that just don't even make sense like UI technologist, UI engineer, UI developer, and sometimes things like senior Web engineer that somehow doesn't require JavaScript. I feel almost embarrassed if I dare to call myself a front-end developer not being particularly fluent in JavaScript. I really don't know what I am, which is HTML, CSS, and some JavaScript and some design sensibility," you know, like a front of the front, I think.

Dave: Yeah. This is where it gets tough. This is the thing, like front of the front-end or back of the front-end. This is sort of the great divide, kind of.

From the perspective of somebody who has been nose to the grindstone for 12 years and lifts their head up like, "Maybe I do want a new job," not saying you're looking for a job exactly, but just is now like, "Oh, geez. What happened? My job doesn't exist anymore. That's wild."

Chris: It is wild.

Dave: There are not people who just make websites anymore?

Chris: Is it really true, is the thing? Maybe it is. It seems like it may not be. I don't know. There are so many -- Victoria, just know that you're not alone. I've heard from countless people in this situation, through emails that we'd gotten after we did the How to Think Like a Front-End Developer series and from the conference talk that I've been giving, How to Think Like a Front-End Developer, in which I've been giving all over the place and kind of pointing to this divide of these heavily JavaScript-focused style of developer and then whatever everybody else is that just has a whole bunch of interesting skillset stuff, except for that.

It seems like there's almost more of you, Victoria, than there is the truly JavaScript-focused people. I don't even know what to make about that except for that, in the talk, I point to the idea that the hiring thing is the biggest pain point for people. People are taking it personally because there is nothing more personable than being able to provide for yourself and your dependents and not being able to get a job because of skillset requirements kind of moving underneath your feet even though you feel like a competent, get stuff done kind of person. Being able to not get a job because of some lack of what seems like a brand new skill is weird.

Dave: Yeah. I think there are companies who just want a Web developer or front-end Web designer. I think they just maybe don't know or maybe you have to kind of put your -- I feel like we had a question recently or perhaps last week. It was just like, "Hi, I'm a designer who does code." I feel like so many people have trouble translating their designs into code. There are enough bottlenecks there. I feel like this should be a discipline or some kind of word for it, some sort of UI but can code, or something. You know?

But then, you get into UI developer, and it's like, oh, okay; I'm whatever. I'm 20,000 node modules deep on this UI. You're like, do we need that?

Maybe it is a chance for you. I'm picking up, like, "I almost feel embarrassed to call myself a front-end developer, not being fluent in JavaScript." Maybe it's like half the great divide, but half like, hey, I think you've exposed some gaps in your knowledge, so maybe it's time to fatten up those T's. That's a post by Mark Dotto. If you can fatten up those T's, your shape of knowledge can kind of fill out.

Chris: Mm-hmm.

Dave: I think that's a really important thing. I think, if you just are skills -- the Fatten up the T analogy is, basically, you have a baseline skill of everything that's lower. Think of a graph. That's the bottom, right? Then you have one skill that's really good, and so you have a bar chart in the middle that's poking straight up. It's like an upside down T.

Mark's point is kind of like, well, maybe you start taking that skill in the middle and try to make the things complementary next to it wider and wider and wider. Maybe you've exposed a deficit in your JavaScript knowledge, so maybe try to fill that up.

I think Wes Bos's JavaScript courses are always good for that. He has an ES6, ES7 JavaScript course that teaches you all the new stuff in JavaScript. I found that to be a really good way, even though I know some of that stuff, I found it be a good way to kind of like catch up on, like, okay, this is actually everything that's kind of new, so that was helpful for me just to round out my understanding.

Chris: Heck, yeah. Yeah, yeah, yeah.

Dave: I don't have time. Dave Rupert, LLC. [Laughter] We were talking about time at the top of the show. Dave Rupert, LLC doesn't have time to be like, "What's every new API in ES6, 7, and 8? Let me just go through. Let me just cruise MDN by chronological order." I don't have time for that, so it's pretty helpful to have resources, CSS-Tricks, or the stuff Wes does to kind of round out those knowledge gaps.

Chris: Yeah. Well, let's just finish up with this last one by Sam who is asking. Sam Kulper is asking. He says he's found a series of blog posts called Base CS, CS being computer science. It covers the basics of computer science such as binary and data structures. He finds them really interesting. "As someone with only front-end experience, I'm wondering if my time is better spent learning about React or Vue or just general JavaScript stuff more deeply."

Sam is saying what he wants to work on is complex Web apps, not just brochure sites or whatever. He wants to understand fundamental data structures and things like that. He wants to be a front-end developer, but just working on more complicated things and just kind of wonders what we think about that.

I think that's fascinating because what's already happening here, again, is some self-reflection of the fact that you are reading a series of blog posts called Base Computer Science and finding them fascinating is like, well, maybe chase that course then. You know? I don't know.

Dave: Yeah. I mean I read Vaidehi Joshi's blog, Base CS. There's a podcast she does, too, that's really good. It's cool because she just takes a computer science topic, almost one a week. I think it sort of changed. That was the plan, I think, but then it changed. It's kind of just like one topic, just kind of dive into it, explain it in human terms, and kind of just start kind of building knowledge there.

I think that's good. I think if that interests you, go for it. I'm looking at the stuff and this is all stuff I know or have come across, like abstract syntax trees, ASTs. I'm just like, uh, it's a good article. I'm not slighting that, but I'm not provoked to be like, "Yeah, let me round out my knowledge about that." But if you are, jump on it, like parse trees and stuff like that. If that sounds interesting, go for it.

I am not currently interested in ASTs but, actually, now that I say that, it's come up in conversation recently. I'm like, oh, maybe I do need to actually understand this because JavaScript has an AST or React has an AST or whatever.

Chris: Yeah.

Dave: Maybe I do need to understand this stuff.

Chris: It's not everybody that wants to go there.

Dave: Mm-hmm.

Chris: I think it is, generally, kind of valuable, I found. I think it does come up in job posting sometimes, or it comes up in hiring discussions once in a while. I know we've had those conversations even at CodePen before where we're just like, sometimes the complexity of things feels very weighty and you're like, "Gosh, I wish there was somebody around here that totally understood computer science so that they could swoop in here and wrap their computer science-y brain around this problem and solve it in an elegant way that we have thus far feel like we haven't nailed. You know?

I feel like a lot of companies have that feeling internally, like, gosh, it should be nice to have somebody around here that really understood the science of these things. Maybe that's not -- maybe just because you know what binary is, that doesn't unlock that knowledge in you, but it starts you on a path that maybe does let you become that person if you think very abstractly.

To some degree, it's at odds with really practical stuff. To some degree, this stuff is so theoretical sometimes that you need to spend a bunch of time in the theory of it before moving on to the practical analysis of it. That's tricky for some people to pull off. That's what turns me off to the idea. I have no desire to do that.

My focus is so wide, anyway, between kind of developer outreach stuff and marketing stuff and design and practical solutions for things and thinking about features and thinking about management. I feel like I have enough on my plate already that I can see the appeal of computer science stuff and wish I had more resources at my fingertips for that type of stuff, but it is not something that I'm going to be actively pursuing because I'm choosing to outsource it to maybe people like you, Sam.

Dave: I think, yeah, if it interests you, go for it. If you get bored or it's too much, bail out. You know what I mean? [Laughter] It does sound like if it seems attractive or it is piquing your interest, you're maybe discovering a little bit more about what kind of developer you are. You're like, "Maybe I am more on the algorithmic side of things." I think it was Rachel, animation Rachel -- hold on. I got it. Nabors - there it is, Rachel Nabors, Animation Rachel, we call her. [Laughter]

Chris: Yeah. Congratulations, Rachel, on your new job at React.

Dave: Yeah, so she works at React now.

She was kind of tweeting about a year or two ago. She was just kind of talking about she got a book on algorithms. She's just like, "I love this. This stuff, I love." She comes from a very animation, UI, CSS kind of background. Maybe I'm over-speaking, but she started there, and now she works on the React team helping round out the docs and stuff like that. That's awesome, right?

Not that those were separate tasks or whatever, but she just was kind of live tweeting how much she was just enjoying learning about these heavy computer science algorithms, and I thought that was really cool. If it interests you, you should do it.

Chris: I love it. Listen to yourself.

Dave: All right. Yeah.

Chris: Yeah.

Dave: Listen to that inner voice telling you what to do. Go eat a sandwich. Get a milkshake. Stuff like that.

Chris: [Laughter] Yeah.

Dave: Go for a bike ride.

Chris: Ooh, about that time. [Laughter]

Dave: All right.

Chris: Yes.

Chris: All right, well, thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShoptalkShow, for tons of tweets a month. If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. Chris, is there anything else you'd like to say?

Chris: They sure do. In fact, they're on sale during May. They're $100 off to be on the ShopTalk Show job board, which is also the CodePen job board and CSS-Tricks Show job board. We just redesigned it and redesigned the sign-up flow for what it's like to post a job, making it a lot simpler and stuff. We battled some of our own technical debt, although it wasn't that heavy, but it was just to make the flow extra smooth for people posting jobs.

Yeah, we very much want you to try it out, thus our offering $100 off all of May. It's only $199 to post your job, and it'll run for 60 days. If you hire somebody within those 60 days, which I very much hope that you do, then just take it down, which you can do, or edit it as needed. But, you know, it'll run for 60 days, which is cool.

Dave: Hey, Shop-o-maniacs, go to that job board. Check it out. Find jobs. Post about success stories.

We have employers all the time--

Chris: Yeah, that's the funning thing running a job board. It's for both people. It's like I want you to post, but who it's for is for people looking for jobs.

Dave: We have people who write in. They're like, "Hey, I found a job. I just want to say thank you." That's not really a question. "I found a job on the job board through this podcast. Thank you."

Or we will have employers just be like, "Hey, we actually had too many talented people apply, which is a problem you don't usually have. Too many Shop-o-maniacs applied, and we actually had so many that we have a backlog and we got more work and started part-timing people, getting them just a little bit of work, like whatever we could just to kind of hang onto these talented candidates."

"People want to hire people like you," is, I don't think, an overstatement. Hopefully, good luck out there if you're looking for new jobs.

All right, Chris, do you got anything else you'd like to say?

Chris: Nope. That's it. ShopTalkShow.com.