Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another holly jolly episode of the ShopTalk Show. I'm Dave Rupert and with me is Chris Coyier. How are you, Chris? I almost jumped straight to the, "How are you?"

Chris Coyier: I'm all right. I'm all right.

Dave: (Indiscernible)

Chris: I actually feel almost normal, okay today. It was a whirlwind week this week because, what was it, Tuesday night I had some folks come to town that were doing a little planning. They were going to record some video with me and stuff. It was great.

Dave: Cool.

Chris: We planned it all out; did some location scouting stuff. It was fun. Went out to dinner that night and I went home and, by midnight, I was hugging the toilet, you know, just done.

Dave: Whoa!

Chris: You know? Just food poisoning disaster. You say, "Food poisoning." It seems like that, but there's been a virus going around too. Who knows what it was?

All these people are from out of town so, the next morning, I'm like, "I literally can't do the thing that you flew to my city to do." Oh, my gosh.

Dave: Oh, man.

Chris: But they all were able to readjust all their flights and so we kind of did the work the next day instead, but I'm still trying to do my job as well and not get behind on things. So, I just took the whole day and just rested. Now I'm fine. I'm back up, so it was one of those 24-hour deals at worst. It was intense!

Dave: Ouch. That's always tough when you, yeah, get hit with an unexpected sickness. My sicknesses always happened on the weekends.

Chris: Oh, yeah.

Dave: I lose my weekend.

Chris: [Laughter]

Dave: To being sick, which is such a waste, such a complete waste.

Chris: It is, kinda. I used to have this friend -- well, he's still my friend. That felt weird to say.

Dave: [Laughter] Ex-friend.

Chris: He's like, "You know what I could use? You know what I've been really waiting for?" He's going to tell you, "Oh, I haven't been to a baseball game in a while." He's like, "A good flu."

[Laughter]

Dave: Just a great purging, huh?

Chris: He would love a good flu. Well, and I kind of felt him yesterday because there was this rollercoaster to it while I was like, "I don't even want to be alive anymore," you know, so bad.

Dave: Mm-hmm.

Chris: To when you crest it, your body still feels bad, but there's such a relief when you stop feeling nauseated that you almost feel good.

Dave: Mm-hmm.

Chris: But then your body is so tired that all it wants to do is lay in bed. So, I'm watching his Dark Materials on HBO or whatever, like the new Golden Compass thing. But I'm just so perfectly calm, at rest, and just watching TV in bed that I'm like, "There's actually some sweet weird pleasure to this."

Dave: Because you can't do anything else.

Chris: No. Yeah, I literally can't.

Dave: You have to sit in bed and pass out.

Chris: I can't even answer an email, but yeah. It was a weird, like, slow down pleasure to it. Not that I could do it all the time, but I think that's what my friend was getting at.

Dave: Yeah.

Chris: Hey, great. Dave, did you know that the color gray in CSS is actually darker than the color dark gray?

Dave: I did know that.

[Laughter]

Chris: It came up today.

Dave: That is super messed up.

Chris: Why?

Dave: Yeah. No, what? Named colors are interesting. It's early technology that, "Oh, we'll just come up with names for every color." [Laughter] There are only 300 of them. There are only 300 colors. We'll just name them all.

Chris: Was that nerds? Can we fault nerdy thinking for that or was there actually a good reason?

Dave: Possibly, yeah. I don't know. Maybe there was.

Chris: There's something about the language design of it, but it does seem like--

Dave: Well--

Chris: I think I can solve this. [Laughter]

Dave: "I got it. We'll name them." I'm sure it came from, I'm going to probably say, Dream Weaver or something like that where you use a dropdown to specify a color or something.

Chris: Oh, sure.

Dave: I bet it came from something like that.

Chris: Even now that it exists today because the Web is extraordinarily backward compatible, there's some temptation to use it. I answered an AMA question the other day. I can't remember the exact context of it, but I remember typing out that I'll even change it in pull requests if I see some CSS that uses 000 or fff. I just make them black or white because, for some reason, my brain has never been able to grok it fast enough which one is which, but the words black and white make perfect sense to me and so who cares.

Dave: it's a free variable. It's a free named, like namespace….

Chris: Yeah. This came up because you were trying to settle on a perfect name color. I don't know why.

Dave: Yeah. No, so I'm doing -- so, you know, I've had this little theme switcher on my site for a long time. It used to be a little artistic palette that you click and it would change the theme in … CSS variables just to change various themes. I switched it to be my logo just because I was like, "Oh, I'll just eliminate a button and then the logo will do the changing."

Then I had some JavaScript that would save that theme to the local storage, read local storage, apply the theme, unload, et cetera. It's all happening but, eventually, it feels like the machine is kind of confused. It's like, "Hey, I don't know which theme to use on this page. I'll just try one." It just wasn't working like I wanted it to, if that makes sense, or just wasn't -- I don't know. It felt over-engineered, if that makes sense.

Chris: Sure.

Dave: I kind of was like, you know, I like it on my iPhone or iPad. I bought an iPad recently. I like it on that when your phone goes to night mode or whatever, a blue light dark mode or whatever, night mode, you can set a setting to where it goes into dark mode. Windows has customizability. You can have a dark OS and a light browser or go all dark or have a light theme in a dark browser.

I just was like, you know, I'm going to switch it over to prefers color scheme dark because, when I originally did this, that didn't really exist. It was like maybe talked about in Safari a couple of years ago.

Chris: Yeah, the CSS media query that determines the user's preference.

Dave: Yeah.

Chris: That's controlled at the operating system level and I believe it's settable in both Mac and Windows, right?

Dave: Yep. It's all kind of working across the board. A lot of people like it. I would be curious about your thoughts if it's a fad or not.

Chris: Yes.

Dave: I know I've said that and people get mad at me. They're like, "It's actually very good for my migraines and stuff like that.

Chris: Sure. That's all true.

Dave: I actually do respect that. I can sense that as well. If you're reading on a thing at night and just getting blasted in the face by white light, it's frustrating. It's not enjoyable as much and it could hurt you, I guess.

Honestly, if non-dark mode websites hurt you, I feel like you need something maybe more, more extreme.

Chris: That's the thing; 99.99% of websites don't offer anything like this at all. If this is going to be our new accessibility crusade, so be it, but I think we can all agree that there are bigger problems than this.

Dave: Right.

Chris: The fact that there's so much mental energy going into dark mode right now and thinking around it, it just feels like, yes, there are elements of a fad to it. But you're having fun with it on your personal site, and it's not light and dark mode. It's crazy pink mode and blue mode. You're thinking out the problem.

Dave: I'm going to probably back away from that. I'm going to have three themes, I think. I have the main one, which is kind of like a white, you know, black text on white background. But the reason that came up was, I was looking for a CSS name color for the background because sometimes I just want -- I don't know. I was looking through and it was like, oh, floral white is good, but then it's kind of yellow. Then I was like, oh, I don't like it. But then settled on white smoke and feeling pretty good about white smoke, so I'll probably ship it.

Chris: That's nice. I've done little things like that.

Dave: Just a little off.

Chris: You know the user agent style sheet has different sizes for H1 through H5 and spacing for them. I was just like, just for fun, I wonder if I can do a website where I change some type, maybe but, for whatever reason, I'm not going to change any font size or any margin or padding and just let it be the UA style. But otherwise, make it look like a fully designed website. See if I can get away with making any spacing choices. It was kind of fun. I don't think it totally worked out.

Dave: Well, no. It's fun. Anyway, then I'm going to use prefers color scheme dark to automatically start in dark mode.

Chris: Right.

Dave: Like if your device going into nighttime.

Chris: I think that's a prereq. You have to do that. You have to respect the media query. In fact, I got an interesting article pitch today that looked at using workers for this, in a way, because a lot of the thinking around this, too, Dave, is not just respect the media query and you get that them. It's that I want twitch or two, and that's advocated for.

Dave: Mm-hmm. Mm-hmm.

Chris: Even if I don't set the media query, there's got to be some UI control to do it too. Fine, but now when you mix those two things, you have two things that can inform which thing the website should be in and you have to kind of dance that dance, which can be a little funky monkey. Both of those things are client-side and it's nice to not have to ask client-side questions. A UI toggle is data that needs to be stored somewhere, so where do you put it? Local storage? Cookie? I don't know what you do.

Dave: Mm-hmm.

Chris: It's tempting to put it in a cookie because then you can respond to it server-side, meaning that you don't have to download light theme, check local storage with JavaScript, determine that they want dark theme, then switch over and potentially get weird flashes, right? This was a cool thing where, you know, respect the media query, put that default value in a cookie. Then you can use cookie in really cool, modern things like Cloudflare workers. You can check that cookie at the worker level and then make sure that you send all the correct classes down in the HTML to make sure that, immediately upon load, the most correct choice is being made and it loads in that state.

It's an awful lot of fancy dancing for something like this. That's what makes me feel like it has elements of fadness that people are willing to take on this level of technical debt right now because it's kind of cool, like, "Oh, I know how to solve this problem."

Dave: Mm-hmm.

Chris: A couple years down the road, people are like, "You have what set up to do what?" I feel like sometimes technical debt gets chopped off when it stops being the hot new thing.

Dave: Yeah. Well, and it's fun to make a bunch of infinite themes or something or even get into art direction. It's like, I want this post to be purple because it's about Twitch or something. Then, yeah, who takes preference?

Chris: Does purple win? Yeah.

Dave: Your art direction or prefers color scheme? Which one? Which one?

Chris: Well, and then if the argument is, "The Web is getting so boring," you're like, maybe some of the reason it's getting boring is because we're trying to be better about stuff like this. If everything is so bespoke that we're taking control away from the user.

Dave: But maybe the right answer is your purple art direction has a light and a dark mode to it.

Chris: Right.

Dave: But that's double the work on your art direction.

Chris: Yeah.

Dave: That could get kind of intense.

Chris: So was responsive design. We just have to double our workload every few years. [Laughter]

Dave: Yeah, just double the workload every couple years and that's how we stay on point, Chris. You know that's how I make money.

[Banjo music starts]

Chris: Hey, hey. This episode is sponsored in part by Percy. That's Percy.io. It's a visual review platform, meaning that let's say you're working on a Web app. You do a merge request that changes some things. Perhaps it changes a little CSS.

What Percy is going to do is compare a screenshot of that with the new changes to what's already on master or what you're merging into and show you if anything changes. Let's say you changed the background color of a button or whatever. That's very intentional. Percy is going to catch that and it's going to show you a dif between those two images. There is going to be read over that button that's going to be like, "This has changed." In Percy, you can be like, "That's okay, Percy. That's what I was trying to do."

Percy will catch any visual change. Let's say you changed some margin or padding on some class or something and it affected more than you thought it would across the site. This is why people are sometimes kind of "afraid" of CSS and making global changes because CSS does have a lot of power in that way. Well, Percy is going to catch all that and show you all these pages.

You configure all this, like, "Go here to this page. Click this. Look at this," whatever, or, "Here's a list of URLs I want you to keep track of, Percy," and it will take screenshots of those. You tell it to take a screenshot. The configuration is easy. It's no big deal.

Then it's going to look at that page. Then any time there's a visual change, even if you change a headline or something, it's just going to let you know. Then in that merge request, it's going to be like, Percy just saw these five changes or whatever. You go look. You go click-click-click-click, okay.

Or you go, "Oh, crap! That's totally a change that I did not expect to happen on that page." It helps you refactor code and just be really sure that the code that you're pushing, the way that it visually changes your website, that you are sure of. It just catches these visual changes in their dashboard.

It's great. It's totally integrated into your Git workflow, your continuous integration kind of style, which so many people work in. Check out Percy.io. I've got a whole Screencast on how to set it up and get working on it over on CSS-Tricks. If you want to search out and find that, you can really dig deep here if you're interested.

[Banjo music ends]

Chris: Well, readers, you're happy to know here that we're going to do a rapid-fire show.

Dave: Yes!

Chris: We like to just chat with each other at the beginning of the show but, for the rest of this show, I believe Dave possibly even has a timer available.

Dave: Oh, yes I do.

Chris: We are going to not get caught up on any one particular question and just get through as many questions as we have because, first of all, we like it. Second of all, we've had feedback. In fact, I got one just before we started recording. Somebody was like, "Whatever happened to rapid-fires?"

Sometimes, when I pop back in and out of the show, I like to start with a rapid-fire to just get my bearings on your show again, so we're happy to oblige, dear listener. Let's do some. These won't be one minute. We're going to cap ourselves at, you know, four or five minutes.

Dave: We've got five minutes. That's for not each of us discussing and taking sides. Five minutes per question and each of us has a card. We have an extendo card, so you can extend the conversation for, let's say, another three minutes or something. I don't know. Sure. You can extend the conversation by playing your extendo card. Does that sound good?

Chris: It does sound good, but feel free to not hit five minutes, too, if we just have less to say about a particular question.

Dave: All right. We'll just cancel it before we get to the timer. All right, so should we get going? I'm going to start the timer after I finish reading. Okay, so here we go.

Brian Cunningham writes in, "What are your thoughts on adopting less popular frameworks for projects like Svelte or Mithril? Sometimes they feel like a better fit for me in my projects, but I'm concerned about being the only person trying certain use cases and I know they're less compelling on a resume." Go!

[Clicking timer]

Chris: Oh, my gosh. Uh-uh-uh… I'm so nervous about stuff like this. Uh…

Dave: I will set this up and say, [laughter] any time you'd say, "I made something in Vue," somebody says, "Oh, have you tried Svelte?" You know? You're like, "Golly," so I think I would say there is a lot of interest out there. I don't know that you need to always worry about the longevity of it but that is something good to think about.

I think people also don't choose Vue because they're like, "Well, no big -- it's not Apple, Google, or Facebook, so I won't use Vue," but Vue is a really good choice.

I think you should try it. I think you should do it per the scale of the project. If it's the flagship project, maybe not. Maybe vet out Svelte on maybe a more disposable or kind of short-term project. That's what I would say.

Chris: Let's dig into that just for a second. The scale of the project, you're saying, I would put something like hiring into that bucket. If you need to assemble a team around a project, you're going to have an easier time with it with bigger name languages. I think that's not to be forgotten.

Dave: Mm-hmm.

Chris: Although, that's a little bit of a bummer if you have to hire people based on a particular framework. We're like, "Is that how you should be hiring at all? Why don't you just hire good developers?" I'm sure they are multiframework adaptable. But, still, we don't all have that luxury.

I don't know. You're saying a smaller project. Brian is saying, "I'm wondering if this is right for me and my projects," so I get the sense it's a smaller scale.

Dave: I would say you and your projects is the ideal place to experiment. Just experiment on your own blog. Start there and then, when the conversation comes up at work, be like, "Hey, let's figure this out."

Chris: Right.

Dave: I know multiple-multiple-multiple engineering managers who are getting hired by companies, going into teams, and they're like, "So, what's going on?" They're like, "Oh, we've got a Vue app, a React app, an Angular app."

Chris: Mm-hmm.

Dave: They have the whole suite of apps just because somebody wanted to code it up that way. Now the Vue team doesn't talk to the React team. They just do their own things. The design system….

Chris: You've seen problems there. That seems like an obvious problem, right? You're not sharing expertise.

Dave: I think it happens. Day one, you're like, "Let's try Vue," or try something else on this project. I think if you have a plan, I think when you go in without a plan, that's a problem. When you have a plan, it can be resolved.

Chris: Mm-hmm. Mm-hmm. There's some irony here, though, isn't it? I think sometimes these smaller frameworks exist. Their struggle and their message, it's almost like don't relegate us to the small little baby projects. We exist to try to unseat some of the damage of bigger problems. I know that's a bold message, but if the message out there is saying React's time is over, it's doing too much on the client-side, there's way more we can do on the build side, which is Svelte's message very clearly, don't relegate us to a side project. We want you to go big with us. We want to prove that this is a better, faster, just better way to build for the Web. What would you say to that?

Dave: I think that's a good point. I think, for you and your organization, it gets into that Monte Hall refactor. Oh, we'll just use Svelte and we'll solve all our React problems. You don't know that yet because you're going to do a prototype of Hello World, and you're like, this is the best thing ever. I made the counter go up and it's smaller.

You don't know until you start pulling in a lot of your business and a lot of all that functionality into the same project. Then you'll see the pain points. You have to hit the pain points before you--

Chris: Yeah. At some point, do you let somebody else prove it out for you, though? Not everybody vets every framework in the world. Is it just too early days for these smaller frameworks and eventually it will become more clear if they really are replacements for the bigger libs?

Dave: Yeah. Why do people use React? Well, Facebook uses React, so we know it works and so we're going to use it. You need a Boston Globe for your project.

Chris: Mm-hmm.

Dave: This big thing is written Svelte or this big thing is written in Vue.

Chris: Would it be smart for Mithril or Svelte to say, "We're looking for our Boston Globe. Please contact us"? Is that too thirsty?

Dave: Yeah, they should. That's pretty thirsty, but I don't know. You should, I guess. If you're a framework author, you should probably be not greasing palms. That's the wrong quid pro quo.

[Alarm bell ringing]

Chris: Oh….

Dave: You should be thinking about that when you want to scale up your project. That's all I was saying. All right. Here we go.

Chris: Eric Sagmar writes in.

Dave: That was fun.

Chris: Yeah, that was cool. Yeah. "I'm working on an Electron app for a client and they want to offer a 30-day trial on their software. After the trial has expired, the software should no longer be useable. The client is aware that determined hackers will always be able to hack their way around things. They just want something to make it somewhat difficult for the average user to crack."

I guess I can start here. I haven't really built much in Electron myself, but I'm aware that lots of apps are built that way and they're built that way on purpose because you can use Web technology to port your app then to multiple platforms kind of "for free," which is nice. I get the appeal there. In fact, I get the appeal very highly.

Anyway, here's one: Slack. Slack has got a native app. I open it as an Electron app every day and leave it open every day on my computer and it works pretty great.

Here's how Slack works, though. If I don't have any Internet connection at all, it's pretty much useless. It's only an online app. It communicates with Web services in order to work.

No, can you make a totally offline Electron app? You probably can, but you didn't say that your app is an offline app, Eric. I'm kind of assuming that you're using Electron to talk to Web services and stuff, which is probably what most Electron apps do.

If you want to turn off this thing after 30 days, why don't you at least have something in that app that needs to go out to a Web service and authenticate its usage? Like, you log in with a username and password. Then you can use the app.

Even if it does something like sets a cookie or does something loosely like that that has to check again after 30 days and, if it can't, the app doesn't work, that doesn't even seem hackable by hackers, really. I mean, I don't know. Maybe it is. But it's your Web app has to auth it to work. That seems like the way to go.

Dave: There's probably a utility. You could use local storage, right? Control Shift I or whatever, Command Shift I will probably get around that even inside an Electron app, maybe. Does it have Web inspector? I feel like I've seen it before.

Yeah, I think you'd have -- people would get around that and crack it, I guess, is what you're saying. I think what, Chris, you're saying like maybe put an email, put some kind of OAuth authentication. It's very common, like, signing you in, or something like that. Have that.

Then you can just gate it on the account side of things. But then you need maybe another server or serverless sort of thing that's like, "Okay, when did this person create an account? When was the install event? Then what do you send to register the computer? I'm sure there's some kind of instance, Mac address, or something that you could use.

Chris: Mm-hmm.

Dave: The hacking inclined have ways around that, but that would be probably the best way to do it. Then your authentication flow has, like, if you think of like a flowchart, it's like they sign in. If 30 days, okay, throw up the warning modal. Otherwise, just let them into the app.

Maybe before that step, have they paid? Yes. Okay, throw them into the app. Okay, are they still in trial? Yes. Okay, throw them into the app. Has the trial expired? Okay, now get the paywall.

Chris: Yeah. Yeah. It assumes there's offline stuff at all happening, right? If we made CodePen an Electron app and we just decided to turn off features for you if you aren't paid, I'm not worried about a hacker being able to get through that. It wouldn't be much of an app if you could just set a local storage thing and have pro features on CodePen. That's just not how the Webworks.

Dave: Yeah. Maybe I'm selling Electron short, but I think of it like a progressive Web app, sort of. It's basically, you pre-download the files needed to run the app. [Laughter] That's sort of how I see it. Then, beyond that, everything is a Web request. Even for content or views or Ajax or getting JSON from somewhere, I think everything should probably be a Web request. Now you just have to gate those Web requests.

That said, I hate that stuff. Authentication, I just hate it. That's my least favorite part of making websites.

Chris: Yeah. Yeah. Yeah. It's such a vital thing now. It's like you almost wish you loved it. Not you, necessarily, but people because it's kind of like that's the Tinder that makes the money, really. You have a thing you can log into.

Dave: Yeah.

Chris: You compel someone to pay for it.

Dave: I need to just sit down and make myself do OAuth 20 times in a row or something, just some sort of flow. Anyway. Or make something that costs $10 that you have to pay for. That'll be cool. So, uh-oh. Here we go. Timer up. Did it make a noise? It did, right?

[Faint timer dinging]

Dave: There it goes. Okay, okay, okay, okay, okay. All right. It's my turn, huh? I've got to read one.

Collin writes in, "I've been a long-time proponent of having my own domain name and owning my content. I never really got into the Facebook or Twitter scene too much and I've been keeping an eye on this indie Web movement for a while, which I feel complements my own thinking. It looks like it has been around for about five years. There are a number of related concepts surrounding this like microformats, syndication, Web mentions. My question is just, what are your thoughts on this? It doesn't seem to be something people are talking about but maybe people should be." Go!

Chris: Yeah. I'm a big fan, obviously. Although, I don't know that you need to make all the checklist of indie Web to benefit from it. It's like a progressive Web app in that way. I think the most important thing is the thing that you are already doing. You have your own domain name and you own your own content; obviously valuable.

I can only speak from personal experience, but I've seen it time and time again with other people that what really helps them, especially if your goal, the stated goal is, like, "I want to be a person of some influence. I want to jump up my career and make it easier for me to get new jobs. I want to be invited to conferences," and all these things that you see some other developers enjoy.

There's one way in. There are not ten ways in. There's pretty much one and it's writing.

Dave: Yeah.

Chris: Doing that writing on your own site also makes a lot of sense because writing on other sites tends to kind of come and go in a way that your own site doesn't. You can always make your own site beautiful, work in different ways, change it up, repromoted content how you want to, and link to it how you want to. You just have all this control over it.

If you know that all this writing thing is a one-way ticket to the things that you want in the world, do it on your own site. That's the most fundamental ingredient to indie Web stuff, I think.

You also mentioned some other stuff like micro-formats. I think I've pretty much stopped caring about microformats. Sorry, but I've dabbled enough. I don't think I've ever seen any big value from it, necessarily. Maybe the closest thing I've ever come is, like, marking something up as an article nicely enough such that reading buttons don't have a hard time finding the article and stuff like that.

Meh. Meh. I don't care about microformats. Sorry.

Syndication, have an RSS feed for your site, I'll personally just say I want you to do that because chances are I'll read your site if you have RSS. Is RSS a big deal for the world? Probably not, but I like it so please have it for me. [Mischievous laughter]

Web mentions, I want to like it; I just can't. It's really weird. What I really like about the idea of Web mentions, so they're kind of like pingbacks. Let's say Dave writes something and mentions my post in it. Magic happens, literally, like post requests on the Internet. It tells my blog; Dave wrote about me. My blog puts a little blurb on there that says, "Oh, hey. Dave mentioned you in this post. That's a Web mention."

I think it's just about as simple as that, really. It's kind of like you can do it without necessarily needing to -- it's like up to everybody who to post and who to be watching. There are a lot of handshake deals that have to happen for this to work.

Dave: There's got to be a bunch of trust that people aren't just going to spam their way onto the CSS-Tricks site. Then you have to have a third party service or server, something that collects all these pings. Then you have to have something that triggers a build or puts those pings on your site. For me, that's a lot -- I haven't seen a really elegant solution.

Maybe, if something was, like, "Hey, I collect all your Web mentions and I give you a JSON feed per URL that you request," dude, that's the place I'm interested in. If something does that, I want that. I'll write some, whatever, HTML templates.

Chris: Sure. I think Remy Sharp, not long ago, wrote a thing because one of the big asks is, you collecting Web mentions is great but it's not everybody that posts all their Web mentions. I think his little tool was, like, give us the content and we'll look through that content and post to all the places that could or should be listening for Web mentions. You're kind of being a good partner on both sides, which is nice.

The appeal to this to me is not just other bloggers blogging about you back and forth. It's social media. It's somebody tweets and says something interesting about your blog post. Can that be a part of the reading experience in some way, like part of the comment thread or shown to users in another way because I think a lot of publishers like me are a little -- they want -- it bums us out a little bit that there's all this good conversation happening around the article that's then lost to the original article, especially in time.

Dave: Mm-hmm.

Chris: In one day, it might be fine. You can follow all these conversations happening about the article. A year from now, that stuff is gone forever.

Dave: Yes.

Chris: That sucks. I'd like to grab that stuff while it's hot, ideally programmatically so it's nobody's job, and get it back into that original article so all those conversations aren't lost.

Dave: Yeah. No, I agree. I've got some bad news.

Chris: Yeah?

[Alarm bell ringing]

Chris: Oh!

Dave: But I want to extend this. Can I do the extend?

Chris: Yep. Yep.

Dave: I'm going to pull the extend card. What are we doing for extensions, three minutes?

Chris: Sure.

Dave: Three minutes.

Chris: I took all your time, so I feel bad.

Dave: A three-minute extension. No, no, no. I think this one, in particular, we have to kind of explain what indie Web is. Obviously, I'm a big fan of RSS. I sort of agree with you on…. It was a big thing. It's still useful, but maybe it's more search engine tech at this point.

Web mentions, Zach Leatherman does a really good job with Web mentions on his site. There's also a hierarchy issue for me. If Tim Berners-Lee says, "Oh, this is a really good post about the Web," I want that testimonial to be at the top, right? You kind of just get a chronological sort of anyone who ever said anything about anything.

It would also help me as a blogger to kind of have social validation. Does that make sense? Not like social validation is everything because that's not really why I blog. But, like, oh, okay, 20 people found this thing interesting on Twitter. That actually helps me. That helps me figure out what I want to write about next - stuff like that. I think there's a lot of cool stuff in that.

The original question asked by Collin was, like, I haven't gotten into Facebook and Twitter. For me, I see Facebook, Twitter, Instagram, and TikTok; these are complementary to your blog, too. I wouldn't write those off.

Chris: Right.

Dave: But there is that thing where you go to some tweet thread. I've done this in the past. It's like, ugh, I just dumped a bunch of thought into Twitter. The UI is terrible. The thread is just garbage. [Laughter]

Chris: Mm-hmm.

Dave: I wish that would have been a blog post instead. I think I'm going to try to find some of those and kind of pull those out into blog posts and stuff like that.

Chris: Yeah.

Dave: I think that's the thing is, like, the spirit of the indie Web is at least, publish on your own site, syndicate those thoughts elsewhere, or you can do it in the reverse too. Publish elsewhere, syndicate at your own pace. But then, yeah, there are both ways. You could do that. I think there's value in that too, so don't write off social media is what I want to say.

Chris: But then if you do that, it doesn't necessarily help the original post, which is what Web mentions is trying to do, in a way.

Dave: Yeah.

Chris: Yeah, every time I tweet -- you know the people that take this the most extreme, like you said, you don't even tweet. You just publish on your own site and then it tweets or do the reverse of that. That seems extreme to me because it's like maybe a quarter of what I tweet would be a good little blog post, but not always. The format is different enough that it's not one-to-one for me.

Dave: Yeah, and that gets into microblogging, which we should have Manton Reece on.

[Alarm bell ringing]

Dave: Uh, shoot!

Chris: Oh, that's okay.

Dave: All right.

Chris: Well, let's see. What do we got? Anonymous writes in. Are you ready?

Dave: I'm ready. It takes a few taps, apparently. Okay. It sends an alert, a push notification to my phone that my alarm went off and I can't engage with the app until I dismiss the push notification. Anyway. Cool.

Chris: What even is UX?

Dave: Cool.

[Laughter]

[Banjo music starts]

Chris Enns: This episode was brought to you by GiveWell. Imagine that you want to help children. You found two trustworthy organizations but they run different programs. One can save a child's life for every $300,000 donated while the other can save a child's life for every $3,000 donated. If you could tell the difference, you'd donate to the one that was 100 times better at saving children's lives.

But in reality, it's often hard to know what charities will actually be able to accomplish with your donation. GiveWell spends 20,000 hours each year researching charities. They review academic studies, charity budgets, and visit charities on the ground to figure out which ones are the best at saving or improving lives. All of their research is public and free on their website.

Go to GiveWell.org/ShopTalk to find out more or make a donation. First-time donors will have their donation matched up to $1,000 if they donate through GiveWell.org/ShopTalk. Our thanks to GiveWell for sponsoring this episode.

[Banjo music ends]

Chris: This person who is totally anonymous is working for a large, well-known organization in the U.K. as a full-stack Web developer, but less than six months, so a newbie there. He says, "I love working here, but I can't help but feel frustrated with the technologies they're using to build things. The things that we build end up relatively slow for the end-user, difficult to develop in terms of debugging, and have known limitations that we're occasionally struggling with and cost the organization money in annual licensing. I'd like to propose to this company I work at to move to a different technology stack, maybe something like Vue, Angular, or React on the front-end, Node for the back-end. But as only a junior developer on the team of several senior developers, I don't feel like it's my place to shake things up as other developers seem to be content with the current technology. How would you go about proposing a new collection of technologies?"

Now, this anonymous person has a couple of ideas here, but let's leave it at that. Go.

Dave: All right. Going. This is, I think, a dilemma that if you're not already facing, I think a lot of people face with these websites that happen five, ten years ago. They bought some big CMS thing and so now they're kind of stuck with it or they've grown and they've hit the limits of it. It's bad.

I think, at this point, you probably should start conversations about chipping away or, like, "Hey, can we kind of federate this or break this up a little bit just so we don't keep hitting problems with the main thing?"

That said, I think it's almost becoming a trope to me that people blame their CMS. "Oh, my CMS was so bad. Oh, my CMS was bad. We had to switch off of WordPress." "Oh, the CMS was bad. We had to switch off of Drupal." That is true, but some of it is how you're using the CMS.

Chris: Mm-hmm.

Dave: Maybe there are points where you could figure out where the problem you're hitting or, like, what could be better. Again, I think we kind of mentioned it in the earlier thing like the Svelte question. You could switch to React, but maybe you're going to hit the same problems or similar problems once you hit the whole spiel of what that app….

Chris: Right. Are you saying that, okay, anon, you have an idea of how to fix some problems but you're suggesting throwing out the entire organization's technology stack for something new and unproven for your company? You're going to have problems with that too. You might think that these new tech choices that you pick are going to solve all our problems, but that's a pretty big change for something that's unproven.

Dave: Yeah. I think, too, there's probably an organizational thing. You have to prove. You're six months into the job. You have to prove maybe that you have the tech prowess to actually kind of make these decisions like, "Oh, hey," and that's probably through, one, getting budget from the organization.

That's the hardest thing, getting budget to actually go fix something. You have to do that a few times and then people will build trust in you as somebody who, like, oh, this person is super good at fixing things. Maybe we should listen to them now when they say, "Hey, we should pivot the whole tech stack to something way more maintainable." I hate that answer because it's like a four- or five-year long-game and that's terrible. [Laughter]

Chris: Yeah.

Dave: But let's say, Chris, you hired me today to work on CodePen and I'm like, "Pfft. Rails is dead, my dudes. We're going to Elixir." I'm sure everyone is just like, "Probably not."

Chris: It depends on who you are. If you roll in with a massive amount of experience, I might trust you. But chances are, you're not going to roll in with no plan at all. You're not rolling in and be like, "Have you guys heard of these new technologies? Let's do those." You wouldn't do that because you just don't have that air about you anyway. Not that anon does, necessarily, but knowing that he's a junior dev, been somewhere less than six months, and it's at a large, well-known organization, which has probably been around for a bunch of years, probably going to be around for a bunch more years too. I'm picturing like a BBC kind of scenario here.

Dave: Yeah, BBC Guardian was what went through my mind.

Chris: Yeah.

[Laughter]

Chris: Right. You can't. These lifers might seem like they're old and have all these problems, but they can't be the ones in charge of a mess when you're like, "Let's switch up some tech. Oh, actually, I got a new job over at New York Times. Bye." You know?

Dave: Mm-hmm. Right.

Chris: You haven't proven that you're going to be around to help with these changes anyway. Why don't you just piecemeal it a little bit? Why don't you build something a little smaller in it to demonstrate, in a way? That's actually part of their follow-up answers anyway, so I'm not trying to steal credit from them. They're saying, "Should I build a little proof of concept?" Yeah, sure.

Dave: I think there are three places. There's always end-of-year reports or something.

Chris: Yeah.

Dave: A whatever. This is what happened this year, if it's a news organization or something, or even internal reports, internal websites. There are a lot of places, little projects where you have a little bit more freedom that you can sneak into or say, like, "I want to do that," or get into and kind of prove not only your value, but your decision-making as well. It's hard, and it doesn't always go smooth, but look for those opportunities is kind of what I'm getting at.

With that, Chris, hold on. Here we go. It happened. Uh-oh. We hit it, but my watch vibrated, apparently. This is--

Chris: Ooh.

Dave: This is just--

[Laughter]

Chris: Super reliable alarms. That scares me a little bit.

Dave: I love … computer. Here we go. [Laughter] Steven Nickson writes in, "When I'm working on a project and I need to make different variations of a single page to compare either side-by-side or in multiple browsers.

Chris: Sure.

Dave: For example -- actually, I missed the period there. "I need to make variations of a single page to compare either side-by-side or in multiple browsers. For example, in one recent project, I was designing and coding up a simple homepage. I needed to show several different options in a meeting with coworkers. If I were working in a visual design tool like Sketch, this would have been easy. I would have simply made artboards and put them side-by-side or exported multiple PDFs to flip through.

"However, when working on such a scenario in the browser, is there a best practice for this kind of comparison? For example, is it fine to just put multiple pages, like index one, index two, index three rather than using Git branches for the variations? I worry that a multipage approach might be hacky or messy. But when comparing different designs, flipping through browser tabs is a lot faster and less confusing for everyone in the room than pulling up my command line and switching between these branches."

Chris: Hmm.

Dave: Here we go. "How do you demo Web page variations?"

Chris: Multiple. Yeah, I mean it seems like the only strike against the Git thing is because Steven is picturing having to bring up a design and then, okay, it's time for design two. Let me go back to my command line and check out a branch and then refresh the page or whatever. Okay, that does sound janky. Don't do that then.

Check one out. Load the page. Open a new tab. Switch branches. Load a page there and just don't refresh the page on page one. Maybe that's a little dangerous. What if you accidentally refresh it or something? Hey, presentations require a little finesse sometimes, so don't do that.

To me, I'm imagining, and maybe it's just because I'm a bit more on the developer side but doing the branch thing is the right way to go just because it's probably not just an HTML file that has to change. There's a bunch of assets that have to change and CSS that has to change. Doing that as a branch is good because then if you decide on version three, you can just move forward from that branch and you're not having to clean up a mess from version one and version two. Version three is already this clean, isolated version three that doesn't have any remnants and crap from versions one and two. Doing it as a branch is nice.

Now, it depends on where you're deploying and what kind of app this is and all that. If it's just a little prototype, great. Have it on your machine, whatever. But that means it can probably go to Netlify. What's nice about Netlify is that you get prebuilt URLs from your commits for all these things, so you don't even have to worry about doing it locally. You just bring up the URL from that commit that Netlify will build for you, which is really nice for that case.

If it's a project that just can be on Netlify anyway, well, then all the better. Then you'll have URLs from all these commits - just as a little trick. Even if you're not hosting on Netlify in the end, the fact that they do these per commit builds for you might be really useful. J

Dave?

Dave: Yeah, well, I use all of those. Index one and index two, we use that. We do Netlify branch deploys. If it's kind of more like -- we usually use that for, like, hey, this is going to change. New font stack, we just changed the font stack. What do you think? Get ready for this.

We use it as sort of a broadcast sort of tool, like, "Get ready. A big change is coming." We'll have a separate prototypes folder or whatever. Then people kind of know, okay, this is just a prototype of the thing we're actually going to build. We'll do that like index one and index two.

Can I blow your mind a little bit? Have you heard of this tool called CodePen.io?

[Laughter]

Dave: It's an amazing tool. You can fork your own work inside of it. You can even import style sheets from a master file and then build a collection of the thing I want to demo dot whatever. You can use CodePen to demo things.

I found, not to -- whatever -- not too much of a commercial, but when people see it in CodePen they're like, "Okay, this is not the real thing. This is just ideas inside of a CodePen." That's awesome. That's the place you want to be when showing off an idea. You want to be like, "Hey, this is in the browser and this is what it looks like when it squeezes and stretches." You have the code window right there. You don't have to drag a browser window…. It's great.

Anyway, I would recommend trying out CodePen, too, for this sort of stuff. Getaway to consume your system. I hotlink the production CSS all the time to stuff and then build out a page, copy/paste it all in there, and just be like, this is kind of what it looks like, so I recommend doing that.

Chris: Yeah. Prototype-y stuff. Thanks for the ad, buddy.

Dave: CodePen is perfect for it. You just build it in there and then people are like, "Oh, okay. That's cool. Let me take that." Fork. Done.

If you have an organization, it gets even better. Private pins. Pro. Anyway.

Chris: That's right. Pro features are great.

Dave: All right. We saved some time. We have 40 seconds left. I'm going to give you 40 seconds back here, Chris.

Chris: Okay.

Dave: [Laughter] Next.

Chris: Is this the Steven Munsey one here?

Dave: Yeah!

Chris: Yeah, Steven Munsey. "Open source is great but, when combining technologies, the water can get murky. If you want to have a website built with a static site generator such as Jekyll or Hugo and use the framework such as Bootstrap or Foundation, you run into duplications, vastly different build tools, and file structures. Can you suggest online courses that teach how to integrate these technologies and how to keep them current for a beginner?" Let's hit the button.

Dave: All right. Starting timer. Go.

Chris: Well, I'm imagining what they mean here is that, okay, you got Jekyll. That means that, at the command line, you've got to run something. Run Jekyll. Jekyll, run.

Dave: Yeah. Jekyll, serve. Jekyll, serve.

Chris: Yeah. Hugo, the same thing. Okay, whatever. Now you have Bootstrap and Foundation. Depending on how you use them, they might expect you to have a build process that builds them like Sass. Now you have two things you've got to do.

Dave: At a minimum, NPM install Bootstrap or whatever, right?

Chris: Yeah. Sure. There are a lot of different stuff going on here. There are different languages, different things building them. I could see how that -- people talk about these things so independently of each other, but there's confusion in the combination. I think that's very fair. What do you think?

Dave: Yeah. Whatever. I've been making websites for a damn long time. I've given talks on command-line tools, but I always find myself in that situation where it's like, what's the easiest way to do this? It's hard.

Chris: What about your site? Do you have a hot reloading? How do you style DaveRupert.com? Is it just CSS? Do you use a pre-processor these days?

Dave: It's Jekyll and Jekyll comes with Sass for free, right?

Chris: Oh, okay.

Dave: I can put all the Sass in a Sass folder and it'll compile the Sass. However, that is very slow, so you don't want to do that all the time, I guess, because it's Ruby Sass, not the new Sass. I guess Jekyll 4 maybe fixed that.

But I am in the situation where I have a critical CSS file. I put that in my includes directory. Jekyll Sass doesn't even know what that is. It's like, "I don't get it." [Laughter]

Chris: Mm-hmm.

Dave: "I've never seen that. I don't even see that file." In my includes directory, I have to run the Sass command, like Sass--stylecompressed. I just manually run--

Chris: Interesting. Okay. You rely on Jekyll's -- or, no. Did you install Sass separately?

Dave: I manually, yeah, installed Sass separately and I manually include that and, boom, spit it up eventually.

Chris: Okay.

Dave: I am trying to get away from that. Where I'm kind of -- you can do all this stuff and I think it's a rite of passage to build some giganto Grump file that also compiles a Jekyll or something like that, or Gulp file or something like that. That stuff is kind of not fun.

I've gotten into 11ty. This is part of the reason why I like 11ty and why I may be moving stuff over to it is because it's built-in Node, so right there I'm using Node.

Chris: Yeah. Yeah.

Dave: I will use Node Sass and something to piece together my JavaScript, CSS, and stuff like that. But I went on a big quest like, what's the easiest way to do this? I'm using Sass just to compile Sass and then, to bundle JavaScript, I found parcel-bundler to be the kind of simplest way to do it.

Chris: Mm-hmm. Okay.

Dave: It's maybe naive, but it's the simplest way to just no config. You just take a JavaScript, spit out a bundle….

Chris: Yeah, there's some buy-in, though, I feel like. I was compelled by it because I'm thinking Gulp is still the only way. I feel like people think Gulp is old, but if you have some site that you've got to run 11ty build and your Sass thing and a Babble thing because you want to write future JavaScript or whatever and you have an SVG icon system, some stuff that is really garden variety stuff you want to do on a website, what builds it all? Tell me. It's Gulp.

Dave: Mm-hmm.

Chris: Webpack is not going to do all that stuff, not really, not if you're not using a JavaScript focused build, you know, you're not building a Create React App or whatever. It's still Gulp of some kind or something like it.

Dave: Yeah.

Chris: Maybe Grunt. Grunt actually feels old because Gulp just feels a little bit more like Node modern stuff these days.

Dave: Yeah.

Chris: But it feels like a pain in the butt to have to handwrite your little functions because Gulp doesn't exactly have a little marketplace of, like, "Oh, you're doing Sass? Well, just do it this way then." It's still just like, "Well, here's an example snippet of code of how you might do it."

Dave: That would be a great open source project, like Gulp recipes or whatever.

Chris: Yeah.

Dave: Just like, hey, do you want to compile Sass? Oh, you've got this weird Jekyll too? Here's how you do it.

Chris: Yeah, it would be nice. That's what Steven is asking here is courses. I would say, if people say, "Oh, I don't use Gulp because," usually the because is because I use NPM scripts directly.

Dave: Mm-hmm.

Chris: When you were saying, when Dave is like, "Oh, I just run Jekyll serve. Oh, I just run Sass-v- whatever," those are just things that you're typing into your terminal. You can put those in a package.json file under the script section. You make little aliases to run those things.

Dave: Mm-hmm.

[Alarm bell ringing]

Chris: You can just say, like, "Yarn, run whatever," and put them.

Dave: Oh…

Chris: Steven, if you're looking at this, look at NPM scripts. I think the tutorials you find around that will be along the idea of combining technologies. That's all I've got.

Dave: That's all I could say. I would just repeat everything five more times.

Chris: Yeah. [Laughter]

Dave: All right. Next question is Mike. "I am wondering if you guys have any advice on working on multiple projects and ideas. For example, I work a full-time job as a Web developer. In my off hours, I do freelance because it's hard to say no to extra cash. The thing is, I want to spend my time learning backend programming languages and working on cool, Bohemian side projects to get out of the Web developer grind and move to back-end software engineering. Any advice on bouncing the three?"

I feel like we've answered questions like this in the past, but we can tackle it. Five minutes. Go!

Chris: Oooh, this is the juggle machine.

Dave: How to invent time.

Chris: [Laughter]

Dave: You get this crystal. You put it in a little locket that hangs from your chest.

Chris: Yeah.

Dave: That's how it works.

Chris: Mike, I think you're putting this engineering thing up on a pedestal a little bit, like, "Oh, I should be learning this because it's going to future my life so much better, but I'm not allowed to get paid for it as I learn it," kind of thing. I'm like, dude, you're already doing a bunch of freelance. It sounds like you're drowning in freelance. It sounds like you got this full-time job and people keep asking you to do for-pay stuff.

Roll with the paid stuff, dude. That's a nice place to be. Not everybody is being asked to be paid all the time.

Dave: Yeah, well, and I would take a step further and say, double your freelance rate. That sounds terrible but get paid well for your free time. You have a job. Get paid really, really as well as you can make it for your free time. Don't go cheap. Don't do friend rates.

Chris: Yeah.

Dave: I say that as somebody who does that stuff.

Chris: If you're trying to learn some engineering stuff, can't you sneak some engineering into these paid projects; get paid to learn them as you go? Just little stuff.

Dave: Yeah. If you doubled your rate, then you could buy your own time. You're working on a project for two weeks. You can buy your own time for two weeks to learn back-end programming and make a side project that your own thing. Just charge; charge, charge money, charge money, and then take time.

I will say, from experience, you're going to burn out real bad. [Laughter] Careful there. You're burning the candle at three ends.

Chris: Yeah.

Dave: You've got to be careful about your energy and mental health. If you're 20, it's great. You're having fun. But also, go meet friends outside somewhere.

Chris: Yeah. Regarding that burnout thing, I think that is interesting in that you're more susceptible to burnout if you're doing this because you think you have to and your future hinges upon it. You're at less danger for it if you're doing it because it's fun as heck. If you're spending a little time after work building a little calendar app with cloud functions or something because it's super exciting for you, you're probably not going to burn out quite as fast. You're still burning yourself out in an interesting way, though. You're still straining your eyes and straining your back. Perhaps any excitement you have about coding, you're not building up any excitement because you're just using it all up the second you have it.

Dave: Mm-hmm.

Chris: Worry about the burnout a little bit, but if you really hate every second of it and you're just doing it because you think there's some money at the end of the rainbow, your risk of burnout is a lot higher.

Dave: Well, how about this plan? You take the freelance work and then you hire your friend to do it. You pay your friend and you take a little bit off the top. Now you're getting paid for your friend coding. [Laughter]

Chris: Yeah.

Dave: Start a business. You know what I mean? I don't know. Unless you really like helping people.

Chris: I wish I had the balls to do that.

Dave: You can pitch in on the project and make money but buy your time back. That's what I'm saying. Pay your friend. What's the Tom Sawyer thing? There are ways to make money that aren't exactly you doing everything. That's how companies work. You hire people to work on things that you don't have time to do. Time is money.

Uh, anyway, but I've been in your place and I love doing side projects. Websites are my hobby. It's tough because you're just like, "Oh." Somebody comes up to you. They're like, "I have money. Do you want to build this thing?" Yeah, I do. Sure. Yeah, I was going to sit on the computer anyway.

[Laughter]

Dave: You need a Squarespace? Well, I was sitting at the computer all night anyway, so, sure, I'll do it.

Chris: I'd be happy to work on your thing for a third of the time and screw around on Twitter for another third of the time and, like, read dumb blog posts for another third of the time but charge you for 100% of the time. Sure, that'd be great. [Laughter]

Dave: Yeah. Yeah, well, okay.

Chris: [Laughter]

Dave: I just think -- I don't know. I think, keep this day job, but make money on the side or even come up with ways either doubling your rate or paying somebody else to do the work. You can come up with a way to buy your time back, basically, so you don't feel like you're negative earning and stuff like that.

All right. Hey. We have zero seconds left.

[Alarm bell ringing]

Dave: There we go. All right.

Chris: Well, this next one is pretty--

Dave: Do you want to do one--?

Chris: What's that?

Dave: One more. One more and we'll wrap it up.

Chris: Okay. Let's do Eric E. How about that one?

Dave: Okay. Eric writes in, "How should pull requests be managed? I work at a company that provides software as a solution, SaaS. We frequently have a problem where pull requests slowly build up to the point where the manager tells everyone to stop what they're doing and review until they're gone. We have about ten people on the team.

"At a previous job, PRs were handled differently. The author had more responsibility of making sure the PR was merged. The author would ask another developer if they could explain the PR to the other developer. Often, the author would realize their mistake by explaining and the reviewer had to listen to make sure it made sense to them later and they would review the code privately for a little bit. I thought the system at my previous job was a good system, so how are PRs handled at other companies?"

Chris: Hmm.

Dave: Whoa.

Chris: That's pretty fun. The new company, the setup is, they just pile up and pile up until a manager freaks out and makes everybody do a review on them until they're gone, which does seem a little weird to me. In my experience, PRs are kind of exciting. They're a representation of a finish line for something. They're like, "Wow, you did it! That needs to go out."

I know they can be as simple as a single line of code or big, complicated, 400 files changed kind of thing. Whatever they are, they're something that's destined for production. There should be something kind of exciting about that, like, "We did it, team!"

Dave: Mm-hmm.

Chris: "This is going to go live!" I would say, at CodePen, they're pretty exciting. Things change so much and it's just nebulous. I wouldn't say we have written documentation on how we handle them, but we try to make it a pretty high level of priority.

If there's a pull request going, you should probably be on that a little bit ahead of whatever your own work is at the moment unless you're just so heads-down on what you're doing that it's a weird distraction to have to switch. But for the most part, especially if you're coming in fresh for the day or something, look at PRs first because somebody is just waiting for that to go out, so get it out.

Dave: Yeah. I have a current situation where one client does have ten PRs waiting, but I think that's a volume of work. You also need to recognize PRs exist in different states. Some are just kind of softballs like, "Hey, everyone look at this." [Laughter]

Chris: Yeah.

Dave: Is this anywhere near where we're trying to do or whatever? Some are nitty-gritty huge refactors like, "Hey, I replaced every semicolon in the project with obscure Hungarian Unicode."

[Laughter]

Dave: People need to, like, "Everyone take a look and make sure. Pull this down and try it out."

Chris: Yeah.

Dave: It might help in your issue tracker to have labels on the type of PR it is, like a good first PR or something like that. Maybe you put estimates on the level of the PR. Other than that, I would say, a squeaky wheel gets grease, right? Every day in chat or standup or both, you just say, "Hey. Got this PR, everybody. Got this PR. Got this PR." If your company doesn't allow it, you should have a little Slack channel just for developers because that can get kind of noisy. Then just be like, "Anyone have 30 minutes to go over this PR?" Just be a squeaky wheel and get it merged in.

Another thing you could do -- this is all organizational, right? The problem is not the code, per se. The problem is the organization and how you all are dealing with it. I would talk to that manager who is calling the fire drills and just say, "Hey, can we just schedule an hour every Friday to go over PRs and do code reviews or whatever so that this doesn't keep happening? What you're doing is crashing our day and that makes everything else late. If we had a plan for reviewing or a cadence or a schedule, it probably would happen in a better manner."

I think you have an organizational problem in addition to a, like, "Well, I don't have time to look at this code," problem.

Chris: There does seem to be something fundamental about it, though. If you can't get PRs out, then what? That's how work happens. That's the last moment.

Dave: Yeah, well, and again back to the labeling. There's a high priority, right?

Chris: Yeah.

Dave: This is a feature. This is a bug fix. This is blocking this whole entire arm of work. Your tool hopefully has a way of communicating that. I find GitHub issues is pretty good. You can do that pretty well and casually. Jira, not so much.

Chris: [Laughter]

Dave: That's just me. [Laughter] Good luck. But, yeah, I mean--

Chris: Maybe we should develop a system, though. All we have is WIP, work in progress, or not. But there are these--

Dave: Yeah.

Chris: They really should be tagged better. I like that, like softball. Just floating this by. I like softball as a tag. That's nice.

Dave: Yeah, just softball or, like, just because it's like, "Hey, really, just somebody look at this. Let me know. This is not actually ready to be merged in at all."

[Alarm bell ringing]

Dave: Hey. Okay. Times up.

Chris: Hey, we did it. We did a rapid-fire.

Dave: That's all we've got. We did an actual rapid-fire. Let us know if you like the five-minute time limit with the extensions. [Laughter] We'll try to do maybe one more of these in the future. That's how things go. Yeah. Hey, Chris, I'm looking at my calendar here. It looks like we've got one more show this year to come out.

Chris: Is that it? Oh, my gosh.

Dave: I think there's just one more show this year, so anyway.

Chris: Yeah. We'll wrap up a nonexistent season.

Dave: Well, yeah. We'll wrap up, I think--what is it--the eighth year or something like that.

Chris: We're going to more series, though. We have a really good series idea that we've been poking at.

Dave: We've been poking at it and then we've been talking websites with our friend Dan Mall and Nophia.

Chris: Yeah. In fact, we actually have designs. They're early, but they're kind of like--

Dave: Oh, boy. Yeah.

Chris: --early and there's going to be some, as Dan puts it, hot potatoeing, I'm sure. It is, at last, in Dave and my ballpark, which is a terrible place to be.

Dave: We have to block out….

Chris: Yeah.

Dave: Yeah.

Chris: We haven't even talked about how to block off that time yet, but it'll happen.

Dave: Oh, boy.

Chris: We need to make some technological decisions.

Dave: Buy our own time?

Chris: We should almost be doing it because, you know. I need a way that we can both work on it that's totally painless that neither of us hate. Whatever that is, we've got to figure that out first, which it feels weird to make tech choices first, but there's enough established tech here that that's okay.

Dave: Yeah, we can figure it out and we can do -- maybe we'll do it. We should do a video and we'll put it on the website for you, how we came up with the tech decision dot CSS dot Tricks.

All right. Cool. [Laughter] We'll wrap this up. 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 for the new year because people want to hire people like you. Chris, do you got anything else you'd like to say?

Chris: Oh, ShopTalkShow.com.