Transcript

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another analog episode of the ShopTalk Show. I'm Dave, and with me is Chris. Take it away, Chris.

Chris Coyier: Hey...

[Banjo music plays]

Chris: [Humming]

[Banjo music stops]

Chris: Lazy John.

Dave: Lazy John. Man, that's great. I was going to try to sing over it. I don't know the words to that song, but I was going to make some up. And it was going to be like, "I went down to the river and I drank a bottle of wine." Or something. You know?

Chris: Yeah.

Dave: Just something just kind of like... But knowing latency and the effects of an online recording product, I was like, "Nope! I'm not going to do that." [Laughter]

Chris: Yeah. Can't be done. Can't be done. Although, gosh, was it you who sent me? Somebody sent me a thing, like during the pandemic, that was like, "We solved this," basically. But it required having some hardware.

Dave: Oh, okay. Interesting.

Chris: You had to get a box in your office, and there was literally geographic concerns.

Dave: Yeah. Yeah.

Chris: I could do it with somebody in Seattle here from Bend because it was close enough that they could kind of guarantee it. But across the world wasn't happening. If you sent them to everybody in your band, there could be multiple people do a whole band thing.

It's cool that tech stepped in there and kind of made it happen. It makes me think of the email, the 500-mile email, or whatever.

Dave: Mm-hmm.

Chris: I'm sure you've read that story.

Dave: Oh, I love that bug where somebody at Berkley, or something, or MIT was like, "Hey, I can send emails. It's all working. Unless I try to send it over 500 miles." They were like, "Uh, excuse me?"

Chris: What? [Laughter]

Dave: That's not true.

Chris: But it turned out to be true because of some weird timeout or something. I can't remember the details. It's actually better to forget and then re-read that story so it's awesome next time. You know?

Dave: Yeah. Yeah. That's probably true with most stories, huh? It's fun to forget the ending, so you're like, "Oh, yeah. That's cool." Or a big chunk of it. I don't know. Maybe that's why I watch Goonies every time. I don't know.

Chris: Yeah.

Dave: I can quote it end-to-end, but I'm still like, "Oh, yeah. That part is funny. That's good."

00:02:44

Chris: Heck yeah. Well, just a normal week. Just me and you.

Dave: Hanging out.

Chris: Miranda calls it the Christopher and David Show!

Dave: Ooh... Good. That's good.

Chris: That's how she refers to ShopTalk Show. The Christopher and David Show. Has a little hip shuffle that goes with it.

Dave: My wife almost knows when we record this.

[Laughter]

Dave: No, I'm just kidding. We change it up a little bit here and there, so she's always confused. But she was like, "The kids get out at like 1:00, so... uh..." and I was like, "No, I only podcast until 12:00, so...

Chris: All good.

Dave: It's fine. I'll take the kids. It's fine. Anyway--

Chris: All good. All good. Yeah, it's summer. Summer. A lot of surprise childcare.

Dave: Camps. We go back to school. Anyway, it's really hot. But yeah, been heading back to school and stuff, so pretty exciting over here in Austin, Texas.

Chris: Yeah!

Dave: When you're listening to this, my children will be in school. That has no bearing on your life, but that is a huge one on my life. [Laughter]

Chris: [Laughter]

Dave: Because now childcare is solved and free.

Chris: Heck yeah. Yeah. Even if it's only six hours or however long kids go to school these days.

Dave: Yeah.

Chris: That's okay. Yeah, we've been loading up the camps, too, doing what we can.

Dave: You've got to. You've got to. Gotta survive the summer.

00:04:09

Chris: There's lots of software to talk about. God, I could talk about software forever. It's just on the mind lately, not that it shouldn't always be.

Dave: You want to talk about how Apple numbers is total trash because I could probably do a whole hour on this thing.

[Laughter]

Chris: Oh, no. I unfortunately had a good experience the other day where I had--

Dave: Oh, really?

Chris: Well, there's a website with a table on it, right?

Dave: Mm-hmm. Mm-hmm.

Chris: Like a table element. And I really wanted to add up the columns in one of the columns of the table. But the website didn't feature that. There's no quick HTML way to do it. Maybe I could have written a query, a clever query selector and done a little JavaScript math or something. I was like, "Why is this so hard?!"

But I selected, just from the upper left, click and hold my mouse, and just copied down to the bottom right of the table. I was just like, "I bet numbers will just know what I mean when I hit paste."

Dave: Oh, really? It did?

Chris: You know what I mean? And it just totally did.

Dave: Huh.

Chris: Then it's one second to just select the one cell after the end of the last row and then hit equals and then drag your mouse up the column and be like, "Add all those things up," and it did it just fine. But that is a tiny little thing. I'm not trying to actually really truly use the software, which I don't know what your pain is.

Dave: This is back to tech.

Chris: Yeah.

Dave: We have a memory issue in Luro, like a cron job that runs in production only is timing out or it's saying, "Keep allocation used," or whatever, and so it just crashes. It's a production bug hooked up to a cron job, and yikes. [Laughter]

Chris: Yeah. The worst kind of bug, for sure.

Dave: The worst. The most hard to reproduce. Still don't quite have a repro locally and stuff like that because I'm not going to be able to max out my MacBook Pro. You know? [Laughter] Probably can't.

Chris: Yeah. Okay.

Dave: But whatever garbage intel the servers.

Chris: But it has to do with files somehow, you think?

Dave: Yeah, like a file read. I think it's just reading a very giant file and falling over. That's sort of what we're having to deal with.

But anyway, we've gotten to the point where debugging memory checkpoints to just make sure we have no leaks and stuff like that, so we're logging out process.memory-usage, I think is what it is. Yeah, in Node. And tracking all these numbers. I have a table of like 1,600 rows for this one loop or for this one pass.

Chris: Yeah, okay.

Dave: I dump it into numbers, and it's actually five values you get from process memory usage: the RSS, the heap total, the heap used, and two other ones. Anyway, I don't care about those other ones. They're just kind of like allocation things.

So, I'm looking at these values, and they're all in bytes, so it's like 70 million bytes. I'm just like, "It'd be so cool if I could just read this in megabytes or kilobytes or whatever. Something similar to a 12-digit number."

Apple numbers doesn't let you format like that. I feel like any software would let me figure that out. Notion probably works. [Laughter] Bytes to kilobytes.

Chris: Right.

Dave: I write a little formula or something. Anyway, I guess I could get more savvy with Apple or whatever and figure it out. Anyway, it was just frustrating. I was just like, "I bet other software does this just fine." Lets me write a custom format that's megabytes.

I couldn't find anything. There's no docs about Apple numbers. The website is literally a page.

Chris: Yeah.

Dave: Anything is in Apple support form.

Chris: There's no customer support.

Dave: Yeah, there's no customer support. There are no people making TikToks about how to get the most out of Apple numbers. There's nothing. Anyway, that's my gripe. It could be... I think it does get an upgrade here in the next OS version. We'll see. We'll see if it can redeem itself.

00:08:25

Chris: Yeah. Isn't that funny that the bigger the software the almost guaranteed worse the service is? You know you can't get somebody from Google on the phone.

Dave: Mm-hmm. Mm-hmm.

Chris: That's not happening. Right? Actually, remember when they sold their domains business? That's all still kind of happening, I think. They sold it, Squarespace, and whatever.

Did you see Matt Mullenweg was salty about it? He was like, "I should have bid on that." Which I'm like, "Yeah, you should have. That would have been better." Although, people would have had the same opinion.

Dave: Probably would have gone over better. I think it would have gone over better.

Chris: Better? Yeah, maybe.

Dave: Yeah.

Chris: But people were saying, well, part of the reason is because you kind of have to have customer support for a domain service. That's so important. You can't just be like, "Yeah, good luck with your DNS. Hope that works out for you." There needs to be customer support of some kind, which you'd think would be true for your business email or whatever, too. But just somehow isn't.

Dave: Mm-hmm.

Chris: If you're having trouble with your entire company's email, too bad, I guess. They probably have some semblance of customer support. But I wouldn't assume that I could talk to somebody from Google.

Dave: Right.

Chris: That's not going to happen.

Dave: Right.

Chris: Facebook, too. I had a buddy whose Facebook account got hacked. He's like, "Well, I'm me, though, so surely there's some way, something. Can I send you my driver's license? Something to...."

Dave: Mm-hmm.

Chris: It's like, no. There's no process. There's no email. There's no phone number. There's absolutely no way. I'm sure if you went and sat a chair outside of their offices, they would just call the police on you or something. You're not getting your account back. It's too late.

Dave: Yeah. That happened to my friend. His account got hacked. Started posting the bad porn, the worst one, and he just was like, "This sucks." You know? His account was shut down, deleted, basically. He can't get back to it. All his friends, all his photos and stuff like that for years is just gone.

Chris: Just gone.

Dave: Just gone.

Chris: Yeah. I don't know. It can be tricky. If you wrote to us at CodePen and on free accounts, it's like what do we have to verify you? You could send me your driver's license, but there's nothing I can compare the details on your driver's license against to know that that was you who originally made that account.

Dave: Mm-hmm.

Chris: It's hard. If you've paid, you're in forever. I can absolutely do it. We can check the credit card details. There's a trail we have that leads directly to you, so you just never have that problem, which means you should go Pro on CodePen.

Dave: Yeah, like, "Hey, man. If you want to pay me money for Luro, I'll personally do an SQL dump with all your stuff every night." [Laughter]

Chris: [Laughter] Right.

Dave: It's like, yeah, you pay me money; I know who you are. We have an interaction. We have a paper trail. I could say, "Give me the transaction from 20 to whatever.

Chris: Yeah.

Dave: We could just cruise bank statements and try to verify you or something. But yeah, when it's free and anonymous, that's hard.

Chris: Yeah. Tricky. At some point, do you just make a judgment call? If your photo is full of ten years of photos of a person who matches the driver's license photo?

Dave: Mm-hmm.

Chris: At some point, you're like, "All right. Here. We'll let you back in."

Dave: Let's screen share and--

Chris: Or if it matches patterns of obvious spam, like one day, all of a sudden, started posting nutritional supplements. What do you think happened?

Dave: Right. Right, right, right. You got big into getting yokes. They had to get there.

Chris: Right. It's got to be hard to know, but I'm sure each one of those cases then is hours of work for someone or something. They're like, "Well, that doesn't make money, so why would we do that?"

Dave: Right. The irony here, Facebook makes money if somebody hacks your account and then you have to go create a new one because new user signups go up. [Laughter]

Chris: Yeah. True. Insidious, though, because that's a sad story and the more of those that happen, the more people are like, "You know what? Forget that Web app," which is the very worst thing that could happen to them.

Dave: Yeah, that's true. It's hard, though. Also, as the website owner - or whatever - you have some responsibility. But it's not your fault if somebody's password is password123. I can only help so much. You know?

Chris: Speaking of big software making changes.

Dave: Hey! Let's go.

Chris: Lots of stuff, though, actually. Well, let me just... Instead of getting scope creep immediately. I'm going to do the one.

Dave: You're launching CodePen right now.

[Laughter]

Dave: Just kidding.

00:13:15

Chris: I'm going to do Figma. Figma launched--

Dave: Yes.

Chris: --P3 colors in Figma, which is good.

Dave: Oh... Nice.

Chris: It's design software. It runs on the Web. Websites support P3 color these days. Your monitor might not, but it probably does. Monitors, the way that it trickled through the ecosystem, I think, was kind of like video formats and photo formats kind of first.

Dave: Mm-hmm.

Chris: Kind of the most incentive to capture the most color as they could, so they did. Then displays started catching up. Well, if we have that color information, why don't we show it on the screen? It actually probably sells monitors because they look great when they have more and richer colors and all that. It makes for good marketing. Then the technology is catching up last. For example, CSS and other Web tech need to be able to specify a color that is in that P3 color space.

All that was starting to happen. Now it's software's turn. You know? Photoshop already supports it. I think it's a little weird how it supports it, but it's in there. Interesting.

Now Figma is too, and they have all sorts of challenges for supporting it, though, because there's kind of this concept of color profiles. I think there was a good thread on it from the fellow who was on our show talking about OKLCH. Andrey Sitnik was like, "Well, it's tricky because different people can open the file that have different needs and setups on their machine."

Dave: Mm-hmm.

Chris: Color profiles was one ... happened. I feel like it's this dialog box that if you've been around the Web and design software for a long time, you've seen it a thousand times without even knowing it. When you used to open up a Photoshop document, there is a good chance it would tell you, "This document has a different color profile than the RGB color space of the current working space," blah-blah. "Would you like to convert it to your color profile or honor their color profile, throw away color profile information?" Nobody knew what it meant.

Dave: Mm-hmm.

Chris: I'm still a little unclear. You're just like, "I don't know. One of those sounds fine." [Laughter]

Dave: Yeah. Whichever one you think, buddy. Yeah like, "You tell me."

Chris: Yeah. Which one do you think? Yeah.

00:15:29

Dave: Well, it's the same with fonts, right? It's like this one doesn't have fonts, so I replaced everything with Georgia. You're like, well, that's not okay.

Chris: I do care about that one. Yeah.

Dave: But what's tricky is having a font on your computer and not on your computer is kind of obvious, right? It's like, "Oh, that's not the right font." Sometimes it's obvious. Aktiv Grotesk and, like--

Chris: Yeah.

Dave: I don't know. Like Helvetica. I don't really know the difference, but I'm sure there is one. But the color profile is... You don't know. I could be plugged into an external monitor that does not have it but my laptop does have it.

Chris: Right.

Dave: Who is right? Who is God? I don't know. I think it's the monitor.

Chris: Very tricky.

Dave: Yeah.

Chris: But all that stuff has been handled by the technology and is ready to go. A non-support situation where the software knows, supports that color, but the monitor doesn't, that's a good one, generally, because the software can sense that situation. It pulls the color back into a color space that can be shone. It's a nice fallback instead of just showing white or black or nothing or something, they know how to shift a color back down to the color space. Pretty cool, really.

Dave: Yeah. I just wonder if it's rough seas here because I choose the coolest pink, the hottest pink, laser pink. Right?

Chris: Right.

Dave: Then Jeff opens it on his computer that's an old, bad one. [Laughter] Just kidding. He's an RGB basic bitch, and so he opens it. Then he's like, "Ooh, that pink just isn't cool. I'm going to switch to lime green because that's popping on my computer."

Chris: Right.

Dave: I go to my computer, and then it's like, "Dude."

Chris: Exactly. The collaborative aspects of this are rough.

Dave: Yeah.

Chris: Yeah.

Dave: Yeah.

Chris: Yeah. Um... So, yeah. It's hard for me to summarize this perfectly, but one of the interesting things is that even a hex code, we think of in CSS now as RGB-only. That's true for CSS. You cannot say, "I want this hex code to exist in the LCH color space or P3 color or whatever," one of the other color. It's not exactly in my brain right now, but I'm sure you can imagine what I mean.

Dave: Rec. 2020, P3, Rec. 2020.

Chris: Right, but there are color models and there are color spaces.

Dave: Yeah. Okay.

00:18:04

Chris: P3 is the space, and then you can model the color differently. Those tend to map to functions in CSS. Like LAB is different than LCH.

Dave: Mm-hmm.

Chris: There are other ones. But what does Figma do? They don't really have... They don't put the OKLCH function in Figma.

Dave: Oh, interesting.

Chris: They just do the hex codes. Sometimes even the eight-digit ones, but that's just alpha. It doesn't matter that much. They can display the P3 colors but the hex code values go up into P3 space, which is a little unfortunate because then if you copy and paste that out, it's not going to work in CSS.

Dave: Yeah. Right. That was my thing because the hex code is RGB, literally. Right?

Chris: Yeah. It doesn't have to be, but it is in CSS.

Dave: It is in CSS, and so it does kind of flatten the colors to some degree. You can get up into the space, I guess, in some things, like yellows maybe, but you can't. Right? It more or less flattens the P3 space.

Chris: It does. It's a little weird. Here's another thing is even the same hex code can mean different things depending on what your system supports and what your monitor supports.

Dave: Mm-hmm.

Chris: Andrea is using ff0000, which is red in a hex code.

Dave: Mm-hmm.

Chris: That's just straight up different. That exact hex code in P3 is way more richly red.

Dave: Oh, so if I do color from - or whatever--

Chris: Right.

Dave: --it would look super different? Interesting.

Chris: But it does solve the issue of somebody else opening the same file in Figma.

Dave: Mm-hmm.

Chris: It's not going to show you two different hex codes. It's the same hex code. Hopefully, it stops them from changing it, like, "That doesn't look as good. I'm going to move it around." Then they're moving it around within the confines of RGB, whereas you're like, "Ah! Don't do that!"

Dave: Yeah. Yeah. It's a brain-melter, man. I've tried to communicate to my coworkers how cool it is, but I don't do a great job. We'll get there eventually, but it's hard when the tools aren't there yet either. I'm glad it's now in Figma to some degree.

Chris: The saving grace is Andrew was a little incentivized to get you to use oklch.com.

Dave: Yeah.

00:20:39

Chris: They just think it's a cool tool, and it is a cool tool. It's not like a paid thing or anything.

But the cool thing is you can take that. No matter what kind of computer you have, you can take that Figma hex code, paste it into oklch.com, and select Figma P3. Then it will convert it to CSS, so you're not totally screwed here.

Dave: Oh, really? Okay. Interesting.

Chris: You've just got to know to do that. You'd think Figma would have a slightly better story than that -- unless I just have it wrong. Then someone from Figma, please email me to understand. But it does seem a little weird.

It's nice that Figma has P3 color in it. But as you know from the conference thing you were just at, they're pretty big on Figma to Web design. They want to help that flow. It's a little bit of a bummer that you might grab a hex code right out of it that doesn't work.

Dave: Mm-hmm.

Chris: That's not good.

Dave: Yeah. Oh, man. Weird times, huh? Weird times.

00:21:40

Chris: Weird times. Tom writes in. This all came from a question, believe it or not. He says, "Can you imagine a color space CSS property? It could be set on the root of the page or even in a meta tag." He's excited about the color features coming to CSS but can't help feel that there's a tricky disconnect between the design software and the Web.

He says, "You've mentioned copy and paste ability of hex, which is no small thing." I still feel strongly about that. I feel like design software don't make the more complex color formats easy to copy and paste. Then people just won't do it. I find myself even just being like, "Ah, just give me a hex code," because of how easy they are to grab.

Dave: Mm-hmm. Yeah.

Chris: Right. Anyway, I think Tom has a good point. Wouldn't that be interesting if you could set the page to say this element (or probably the whole page is probably the way to do it) is in this other color space. Then you could use hex codes that are outside of SRGB, and that would certainly help Figma's case.

I don't know. That's beyond my pay grade.

Dave: I picked P3 orange, right? The Figma P3 hex code is fb6222ff. Right?

Chris: Okay. Yeah.

Dave: An eight-digit hex code, fb6222. But then the fallback hex is ff6832. I guess I don't understand how it's punching up into the color space, but that's just my brain here.

If I type fb6222, I don't get the same color. [Laughter] I'm so confused. Oh, well. Hey. We'll figure it out one day.

Chris: [Laughter] Will we?

Dave: I don't get it. Nope. I don't get it, Chris. I don't get it. Anyway--

Chris: Hard world. Yeah, indeed. Maybe we should do another one here. Interesting. I know what it's like trying to design software for designers and developers. A little tricky.

Dave: Yeah.

00:23:47

Chris: A lot of stuff to catch up on there. We do have a fellow, Chris Weiser, like Budweiser without the bud. Nice, buddy.

Dave: Mm-hmm. Mm-hmm.

Chris: He had a question for you specifically just about productivity tools. Curious. He said you've had the run of the gamut of productivity tools, to-do apps, bullet journaling, sticky notes, Ugmonk's analog card system. You do and think about this stuff a lot, so he's just wondering, are you still on analog? Do you recommend it for other people? Talk productivity tools, Dave.

Dave: I think you could probably pick a productivity tool if you understand your own brain a lot better. I think that's what I've been understanding.

Again, this is undiagnosed ADHD. Not from a doctor. It's from TikTok, so don't take this... Don't self-diagnose yourself off of this.

What I've noticed is there's this thing called optimal stimulation. If I have too much stimulation, I become overwhelmed and I shut down. It's this weird thing about ADHD. It's not so much an attention deficit, but it's attention starvation. And so, it's kind of like when you are full, when you've eaten too much, you're like, "God, that sucks. I'm in a bad state." But when you're hungry, you're just like, "I need more. I need more."

Chris: Ooh... Okay.

Dave: Anyway, that's sort of this--

Chris: How does this work? Can you do, for example, just one thing at a time only?

Dave: No. I'm doing ten things right now. [Laughter]

[Laughter]

Dave: I've got a code editor. I've got a blog post. I've got a podcast. Yeah.

Chris: Yeah, I get you. I get you.

Dave: A database tool and, yeah, I've got ten things going right now.

Chris: That's good to know about you, too. You have something to do today. You're going to get it done, but not through exclusive focus on it. Because you could hear that as advice, right? You've got to get something done. Focus, man. Focus.

Dave: Focus up, dude.

Chris: You're like, "I actually need to focus on three things in order to get that one done. Sorry, but that's just how I have to roll."

Dave: Well, and that's the thing, too. The trick I'm learning with ADHD (my undiagnosed ADHD that I self-medicate with caffeine) is there are moments of unfocused, like you're doing ten things at once, and then there are moments of hyper-focused. That's where the superpower of ADHD comes in. You can almost get an eight-hour stretch where you forget to eat and you're just working on stuff.

Chris: Hmm...

Dave: Hard core just hammering stuff out. Learning that rhythm and stuff is important, too. All this to say, before we get into productivity systems, know thy self, I guess. Right?

Chris: Right. it does seem a little cart before the horse - or whatever - to just be like, "Hey, you know what you need? You need--"

Dave: A bullet journal. Yeah.

Chris: Yeah. Because how would you know what you need? That's weird.

00:26:51

Dave: Understanding what you do or how you operate is the most thing. Now I'll go through the thing, like a bullet journal is very cool. I'll just describe it, but it's basically like you do planning. You basically draw five columns for the week (or seven if you want to do weekends in this thing).

Then you say Monday, Tuesday, Wednesday, Thursday, Friday. What do I have to do? You write down or draw little checkboxes for what you have to do that day. Then you also have this on a month level, like what do I have to do this month. Then you boil all this stuff down at the end of every month.

It's very cool. Maybe you even have a day thing where you sit down and you do, okay, today, what do I have to do? I kind of forget all the aspects of it, but it's very cool.

Chris: Yeah.

Dave: I found out, though, if I don't do it, I fall off the horse very quickly. If I don't open that notebook that all that information is in, it's gone. I'd lost.

Chris: Yeah. You'd be starting over to get back on the train.

Dave: Yeah. My previous productivity system was sticky notes everywhere. I'd put sticky notes with GitHub issues that I need to do today.

Chris: Okay.

Dave: Or feed yourself or walk the dog, whatever. This is cool. This is very noisy. That's where that optimal stimulation thing comes in. It is visual clutter that, when I'm stressed, I actually don't react well. I shut down because of visual clutter.

Even stuff in my house, like whatever kids' shit all over the house. It just drives me nuts because I'm stressed. This is clutter, visually.

My environment and myself are interacting. That's again unique to me. But the Ugmonk analogy system has been great. Here's a card right here. I'm showing it to Chris.

I've got to do something for the TSA. I did that. I got an invoice or pay this guy Phillip. I've got an invoice somebody. I've got to log into my Edward Jones - or whatever - to get some data.

Chris: Right.

Dave: That stuff is... Then I do my meetings that I have at the bottom. There are ten rows on here, and I fill out this card every day. It's sort of like the ritual. I really like this ritual because it's sort of like you take five minutes every day, and you just say, "What do I have to do today? What's the most important thing? What's coming?" That helps my brain, too, to know what's inbound in the day.

If I fill up a card with ten things, that's a lot. Right? I feel like.

Chris: Yeah.

Dave: If I do ten things in a day, crap, that's a lot.

Chris: Especially if it makes... Because there are things that will never be a bullet.

Dave: Yeah.

Chris: But ended up being a thing, like you've got this letter in the mail. Your job is actually to open it, read it, figure out if it matters or not. It probably doesn't. And throw it in the trash.

Dave: Yeah.

Chris: It kind of counts, you know? If somebody is... [Laughter] I used to know a guy who just... He had trouble getting a lot of stuff done in a day. If he checked his mail and went through his mail, that was a good day for the guy. You know?

Dave: Yeah. You can always tell. I mean it's like where are your piles? I have a pile of unfiled crap. That's the stuff I don't like to do. Now it's become a big burden, a backlog. I probably need a little bullet point that's just like, "File ten things," or whatever, just to keep ahead. Or "Open your mail. Triage your mail."

The Ugmonk system has been great. I'm still using it for two years-ish now.

Chris: Wow!

Dave: It's been awesome. Yeah.

Chris: Okay. You're in it.

Dave: It's been a little pricey. There are cheaper versions. But you can use davatron5000 at checkout and... [Laughter]

Chris: Wow! It's kind of like the simple human trash bags of productivity or something. To throw something in a garbage can, you don't need these premium trash bags. Just like you don't need a premium piece of paper to write what you're going to do that day.

Dave: You don't, but it's also... I don't know. I file it under self-care.

Chris: Yeah. Yeah, okay.

Dave: Look. If I, Dave Rupert... Again, my brain. If I say, "That's too expensive. I should make my own," now I have another project I have to execute. Now that's going around in my brain. That's hard. I would consider it. You could probably just get some 3x5 notecards and do the same thing. Just draw ten lines or make a little stamp that stamps out ten lines or something. You can have the same effect, but I don't know. I'm happy to pay Ugmonk for the cards. It's easy for me.

Chris: Yeah. Yeah, I agree. They probably are actually nice and stuff, right?

Dave: Oh, yes. It's like the perfect cardstock.

Chris: It's not like one week it's on a piece of computer paper and one week it's on some yellow graph paper or something. You might lose a little momentum.

Dave: I have that over here. [Laughter] Those sit at the corner of my desk. That one is not good. I started taking notes like that. But these cards are rad, so I would recommend it.

Again, it's sort of that thing. If it's interesting to you, I would do it and bite the bullet.

00:32:27

Chris: Yeah. It's like a limited number of really nameable tasks.

Dave: Yeah.

Chris: And that you have a very strong goal to accomplish all of them.

Dave: And I try to clear the board every day. I mean I don't do it every day, but I try to clear it.

Chris: Yeah.

Dave: It's about being mindful/tactical about your day. What do I have to do today? What do I absolutely have to do today: A, B, and C? Great. Let's go. Let's get at it.

Chris: Would even an email be on that list, to be like, "I really need to get back to Jimmy about the conference in Amsterdam next year," or whatever? That's on there?

Dave: Yeah. Yeah, like if I've been putting that off for too long, I need to do that. Some days, check email is on there because I have - whatever. That's my other secret is I'm really bad at email.

[Laughter]

Chris: Yeah. If you have to have a different... So, you'd never put something that you need to get done. You'd never just email it to yourself for something?

Dave: No.

Chris: Because you just don't look at it often enough to know.

Dave: No.

Chris: Yeah.

Dave: That's not useful for me. I'll maybe mark it as unread or whatever just if it's something I have to circle back to. This all gets into GitHub issues, too. There's not just one funnel of issues in my life. GitHub issues is another thing.

One thing I've been trying to... I firmly believe backlogs have an emotional weight. I don't know if you agree, Chris. I'd be curious.

Chris: Oh, my God, do they ever.

Dave: They do?

Chris: The older the thing on the to-do list, the more I'm just like, "Uh..." and I guess that's an auditory version of guilt or weight or something.

Dave: For sure. No, it is. And so, what I've been kind of asking of my coworkers is we keep the issue queue very tactical. Like try to avoid, "Hey, I had a cool idea," or "Maybe one day we can do this." Try to keep it very much like, "If you're going to pick up this ticket, you know exactly what's going to happen."

Chris: Uh... Right. I think that's important, too. It reminds me of an old 37 Signals thing where they're like, "If it's a good idea, you won't forget about it."

Dave: Yeah.

Chris: Don't clutter up your crap with it. If it's not that good of an idea, then the fact that it fluttered away from your mind is probably good.

Dave: Yeah. For sure.

Chris: It didn't become a card; get artificially too much weight. Somebody actually picked it up and did it even though it wasn't that good of an idea to begin with.

00:35:00

Dave: Yeah, so we're sitting at about 50 issues right now. That's a lot for a small engineering team, I'd say. But then I made a technical debt tag or label in GitHub because I just was like, I just labeled the issues as debt. If we've said, "Okay, this is an issue and we've decided not to do it right now, that's debt." That was kind of the--

Chris: I like that it's kind of a literal definition of debt.

Dave: Yeah.

Chris: Sometimes I think of the things that you do as debt also. You know? It's like we're going to incorporate this new screenshotting technology - or something. That's debt because you now have to maintain it forever. But I guess it's not as clear of a definition of, like, we're going to let this old screenshot system rot. That's more like actual debt because it has to be paid later.

Dave: Yeah. Yeah, exactly. Like if you said this screenshot system is super expensive and wildly out of date and doesn't do AVIF. You identified those things, right?

Chris: Right.

Dave: You're like, cool. I'm not going to do it. [Laughter] That's not right now, but we need to do that because it is costing us actual money in server bucks. It's not a big deal, but it is just interesting.

We'll file the issue, like upgrade screenshot service, but basically, if we're not going to do it, if we've made the decision not to do it now, we'll file it as debt. We can go into our debt label and see 20 issues. But they're not all important, and some are really minor.

Chris: Yeah, that's tricky.

Dave: It's just stuff we're not going to do now.

Chris: See, these are two different concepts. You're talking about a shared system between you and all your peeps, which is interesting, too, because that's not... You can't point to one person's brain and say it just has to work for everybody's brain. Whereas your personal system, you can fine-tune to your own brain.

Dave: Yeah. That's a good point. Your personal system can be as chaotic or whatever as you want. But I think, in the public system, there needs to be just as much rigor as you can get.

We have a few, like, explore this idea or issue, like spy key kind of issues. Those are not my favorite, candidly, just because they kind of go on. But I think if we could... The goal is to pull all those up and say, "Cool. What are we going to do about this?" or "What needs to be done?"

That's been my latest kick is, like, here are these five things we've talked about. What do each of these need? Do needs versus wants, kind of, like what does it need to be done?

Chris: Yeah. Yeah. To be done, yeah. We've even enforced a principle of the card can't just say "screenshot system" or something. that's too broad. It probably needs to get broken up a little bit. It's not actionable, so every card name has to be a thing that you do.

Dave: Yeah.

Chris: It just can't be the name of something.

Dave: Right.

Chris: What would you call that? Like an action. Just to say, "Research replacements for screenshot system." That's almost good enough. I'd say that's a little tricky because research doesn't have an outcome.

Dave: Always, right, yeah? Yeah.

Chris: So much, so it might be, like, "document" might be better because then it's the action item is that, at the end of it, it's been documented.

Dave: See. That's my thing. I could go full... [Laughter] I could go full weirdo, like authoritarian, on the board, to be honest. I hate that about myself.

But it's just like, I'm very big on the verb, X to Y, like add something to component - or something like that.

Chris: Yeah.

Dave: Action object to whatever. Action noun to object - or something like that.

00:39:17

Chris: Right. Unfortunately... Ugh. Some of the best working days, I find, is when there's a bunch of those and they are well-documented and well-understood and agreed upon by the team, and you can just knock them out.

Dave: Yeah.

Chris: That's just not all work, though. There's all kinds of other work where the actual thing that you need to get done (whether it's a card or not) is, like, "Get everyone on the same page and agreeing about the general way that this abstract concept works," which will never be a card.

Dave: Yeah.

Chris: But is what needs to be done. Then once you're at that cool agreement, understanding state (which will never be perfect, but it'll be closer than it was) then you can make more fine-grained cards around it.

Dave: Right. Right. Yeah. Oh, man.

Chris: Impossible. Yeah.

Dave: No, it's hard. But I think that's work, right? I think I've heard the term. I probably said it here.

When you're building a company or working in a company, you're building a product. But I like the idea of you building the machine that builds the machine or that builds the product. How you work together, how you operate, that is just how you get things done.

Yeah, so this memory issue we were having, we were kind of just trying code, like optimizations. But we're at the bottom of, like, how to fix JavaScript list. It's literally the advice is use Rust or Go. That's where we're at on the memory issue right now.

I think the hope here is, like, let's just have a data-driven approach and see if we can make the numbers snap into a form we like. Let's have a talk around objective stuff and not less about subjective stuff.

That's actually kind of built into the ethos of Luro. We're working on a new feature to where we can track your components across your whole website. That's a spoiler. But anyway, we're working on that.

But it's going to basically... When you're having conversations with our coworkers, you can basically have really objective conversations like, "Hey, this component is used once," or "Hey, this component is used 5,000 times," or "The team that owns these sets of pages or views, they haven't used the design system at all. What up with that?"

Anyway, that's kind of the hope there. We're close. I could give you a tour, a secret tour, Chris.

Chris: Yeah. I've got to put that on the calendar one of these days because I've got to do the same.

Dave: All right. We'll do it.

00:42:04

Chris: Yeah, productivity. Interesting. It's interesting that you go analog at all. I would think that's slightly unusual for tech people just because there are so many computer-based solutions.

Dave: Yeah. Like you use Things, don't you?

Chris: Yeah, pretty big on Things, still. It's not the absolutely only thing because Things is personal only. I don't know that they ever even tried to become a team tool. But of course, Notion for the team stuff. Not of course. I don't know if it works for everybody, but I've used it so long that it just seems like the old hound these days - or something.

Dave: Yeah. Yeah.

Chris: And then a little bit of Bear for more freeform, like I just need to write some stuff down. That's about it. Email is such a big part of my life and days that those end up being a little bit of a proxy to-do list also.

Dave: Mm-hmm.

Chris: It's a little spread out, but not in a, "Ugh, this is such a mess," kind of way.

Dave: Yeah.

Chris: I think it's fine for me because you cannot just do one thing. I just can't. So, having lots of things is useful, but not too many. I had a bad couple of productivity days because there was a little too much going on, and I kind of went over the waterfall - or something.

Dave: Yeah. Yeah.

Chris: In that there would be like five things I was working on. I was like, I can't. I can't seem to really push one of these forward.

Dave: Yeah. A personal question: Has CSS-Tricks, offloading that, has that made it better? You're not managing a giant publication anymore.

Chris: You know I wish I could answer that. Doesn't it seem like it would?

Dave: I would think you'd have this amazing--

Chris: I think I've even written that it has.

Dave: Yeah.

Chris: But at the same time, I just can't. I don't know for real. I can't answer you 100% honestly.

Dave: Yeah.

Chris: How can it not, though? My God! I had tons to do. I had a whole separate inbox, a team inbox.

Dave: Yeah.

Chris: Usually, I funnel everything pretty much to one just because that's how I roll. But in this case, it was shared.

Dave: Mm-hmm.

Chris: We'd give multiple people access and stuff. Oh, it was full of stuff. Incoming articles, they had to be read. They had to be discussed and talked about and edited and published. And I had to talk with Jeff. There was a newsletter that had to go out every week. Robin did it a lot, but sometimes he was out or sick. It just was like, how was I doing all that and this?

Dave: Mm-hmm.

Chris: Especially because I get it. I did. So, it's not like it was unfathomable. But now I'm so busy.

[Laughter]

Chris: But at the same time, don't feel like I'm twice as productive on my other things.

Dave: Yeah.

Chris: It's not like I'm like, "Oh, CSS-Tricks is gone. Dave, check out this new design I did for ShopTalk Show." I feel just as busy as I did before. Very strange.

Dave: It's kind of like the vacuum. What is it? There's a tech rule, eponymous law, or whatever. That space gets filled, right?

Chris: Right.

Dave: Like Cunningham's law where space fills.

Chris: I think it gets brought up in how fast browsers get. If browsers get faster, well, guess what's going to happen? We're just going to start shipping more JavaScript. We're going to slow that baby right down again.

They use it in football too, right? You make a helmet that's safer. Well, then football players are just going to hit harder.

Dave: Yeah. Yeah. There was an Andy and Bill's law. Andy giveth, Bill taketh. But I think it was like Andy Grove of Intel and maybe Bill Gates of Microsoft. Andy would make a better processor and Bill Gates would just eat it, basically. [Laughter]

Anyway, Cunningham's law is the best way to get the right answer on the Internet is not to ask a question but to post the wrong answer, which I 1000% do. [Laughter]

00:46:01

Chris: We have a couple of more questions it'd be interesting to get into. I have all kinds of notes. I can't wait. I can't wait for the Christopher and David Show to get all my thoughts out.

There is just an interesting technological one we could pivot to that I haven't thought of in a while.

Dave: Yeah.

Chris: Which is, think back to the days of M-DOTs.

Dave: Yep. Yep, yep, yep.

Chris: What I mean by that, listeners, is a literal different URL that you would land on kind of pre-responsive design but in that early ages of phones and stuff where websites, companies that made websites, wanted to deliver you a mobile-friendly experience. You could do that from scratch with its own codebase.

Dave: Mm-hmm.

Chris: Easier than you could do responsive design. And responsive design is what came along and said, "No, no, no. You don't need two teams, two codebases. You can do this all in one codebase." That was kind of the transformative nature of it.

But the Web is a big place, right? Sometimes. I'd imagine this is still true today to some degree. That's kind of why, for example, Wells Fargo has a mobile app and a website. Well, with their mobile app, they can design a very mobile-specific experience. It's not to say that their website could and should work on a small screen, but whatever. They picked that path. You know?

Dave: Yep.

Chris: I think, anyway. I don't even use Wells Fargo. It's just an example.

But the question coming in from Ben B. is, "Is there a best way to make a totally different layout for what happens on your desktop computer and your smartphone?"

He's like, "I work in React and, recently, Next.js, but answers for whatever are fine, obviously, of media queries. But what if you need totally different components for different screen sizes? My solution is do window.inner-width inside of a use effect and then have some logic in the case of screen resize and then pass that through React context."

I was always like [panic breathing].

Dave: Yeah. I got the sweats.

Chris: Yeah. [Laughter]

Dave: Just hearing that.

Chris: Not that I'd blame you because it's not like there's an amazing piece of technology that says, "Load this component under these circumstances in a React situation."

Dave: Yeah.

Chris: I don't know. You're already client-side by that point. That's the part that bugs me is that you have to be client-side, use JavaScript, figure out the situation, and then do more client-side work that way. That bugs me.

Dave: Yeah.

Chris: I wish we would know server-side and make all these choices server-side so that the first bytes that are coming to the client are already like, "I know what situation we're in. I'm going to deliver an experience perfect for that." What were you thinking?

00:48:55

Dave: Well, first of all, don't use window inner width because that's going to... Whenever you measure something -- get bounding client wrecked, window inner width -- you cause a style recalc. Don't do it. It's bad for your--

Chris: Just the observation of it causes re-render?

Dave: Yeah. Just even asking for it is bad news.

Chris: Okay.

Dave: But your goal is to re-render, but just know that that's... Please don't do that.

What I would recommend to do is you can do... This is tricky in stuff like Vue and maybe React where Vue really doesn't want you touching the window object from your components. Does that make sense? The component has to be mounted, first of all, before you even get the window object. I assume React has the same issue.

Chris: Where would you even write code that could access it that's not a component?

Dave: Yeah, and so I guess that's probably in use effect because it's already running on the client or it'll run - whatever - however they do that. In there, do window match media, and then your media query, min-width 30 pix - or whatever - 300 pix, max width 500 pix. Then .matches, I think is what you have to do.

Chris: There you go.

Dave: Does it have any matches? Right? That's probably the safer way to do that. I think that's totally it.

You can either do your differentiated serving from your client and just say, "If this width, do this component. If this width, do this component," and I think that's actually a pretty awesome way to do it because, to be honest, the alternatives are sort of bad.

Chris: It does. It just means that you're bundle then has both of them in it and stuff.

Dave: Your bundle has both. It's not great. I agree. I think it's not perfect. But maybe it works.

Chris: Yeah, maybe, but isn't that what client hints kind of were sort of kind of? Isn't that nice that with now the client hints exist that you know viewport width, like client or server-side?

Dave: Yeah, before you serve it. Now your template, your PHP, or your React server could maybe respond to that if it has client hints. I don't know the support of that. Are you looking that up?

Chris: It's just so old. I thought for sure it would be cool now, but maybe not.

Dave: Like a CH header. Can I use client hints?

Chris: Can I use. Yeah, there you go. What a great name.

Dave: It doesn't work in Safari and Firefox, so good luck.

Chris: Oh! What?!

Dave: You're going to have a hard time in that one. Yikeronies, bro!

Chris: Okay. Well, forget everything I said about client hints because--

Dave: [Laughter] Yikes! Okay, that's hard news to swallow, actually. Anyway, okay, cool. That doesn't work. He can't do that.

Now you have to install wurfl, which hits an API to basically sniff the user agent to figure out if it is mobile or not is mobile or is desktop.

Chris: Yeah. Talk about debt. You don't want that.

Dave: I mean that's debt. I mean you could do some middleware and then route it to two different sites, too. That's something you can do.

00:52:19

Chris: Right. I would think, if you're doing this in React of Vue - or whatever - that you'd make a really high-level component, like just the app.js or whatever. That it figures out this client stuff and is light on its own. Then figures out which kind of path to send you down.

Dave: Yeah.

Chris: But that is a choice because if all it is is the weather widget and you want a lightweight weather widget or something on mobile, then you don't need this. If it's at one single component level, load this one or load that one, do exactly what Dave is saying. Do the match media test in the use effect or something. Then get some piece of information and wait to load the component until you know that piece of information. Maybe even lazy load it if you can. That'd be cool.

Dave: Maybe lazy load. I mean that would be kind of... I was looking at this wurfl thing, W-U-R-F-L, web.wurfl.io. It's kind of like the butt of a joke from a long time ago, unfortunately, just because people are doing all these hoops, then a new device comes out, and then it doesn't match anything. You get the phone on the new - whatever - Vision Pro. [Laughter] You get the phone website on the Apple Vision Pro. That's not what you want.

That's one limitation of these things. But you could do wurfl is mobile. I think it's pretty hefty, too. It's going to blow your kilobyte budget. But you could do dynamic imports like if is mobile, import whatever tab bar instead of main navigation - or something.

Chris: Yeah.

Dave: Here's another one. Hot take. Just send both and show-hide. Use Bootstrap style is desktop. It's not the best, man, but--

Chris: If you're doing it that way, then you could use a container query, too, in CSS and just display none the other one - or whatever.

Dave: Yeah.

Chris: I was thinking, like, it's one thing to know about the window. But if you want to measure the size of the component itself, you do need to render some kind of div or something first.

Dave: Mm-hmm.

Chris: Measure that. Then load the insides of it. Which doesn't feel a particularly framework-friendly way of operating.

Dave: And there's overhead. But if they are two different things, like apples and oranges, make two websites. Then you need some middleware in the middle to figure out do you route to the www or do you route to the MDOT. That's a play you can make, too. I think you'll get burdened by maintaining two websites. But maybe your componentry is good enough that the pieces that need to map to both do. And so, maybe it's easy.

Chris: Yeah. That'd be funny to get done with it and be like, "Cool! Did it!" And then be like, "Somehow, the mobile bundle is bigger," or whatever. [Laughter]

Dave: Yeah. No, that happens. Yeah.

Chris: Hopefully, you'll have a reason why you're doing it.

Dave: Yeah. Yeah.

Chris: And one of them is size and speed.

Dave: Yeah. Yeah. No, that can totally happen. It often happens, I'd say.

Also, this is the horse-sized duck problem. Do you want to fight one horse-sized duck or do you want to fight 100 duck-sized horses?

Chris: [Laughter]

Dave: Which one do you want to fight? You choose. If you like fighting many things, then make the MDOT. If you like fighting one giant thing, make the horse, the horse-sized duck. It's that problem over and over. That's all tech is.

Chris: [Laughter] Coming soon to A Book Apart.

Dave: Horse-sized Duck: Fighting a Horse-sized Duck, A Book Apart, by Dave Rupert.

Chris: [Laughter]

Dave: What's the deal? [Laughter]

[Laughter]

Dave: God, dude. Why won't they accept my book proposals? It sucks.

[Horse neighs]

Dave: All right.

[Duck quacks]

Dave: We're at the hour. Crud. Well, we got to two questions. I feel like that's pretty good.

Chris: Almost three, really.

Dave: Almost three. Yeah, that's good. Hey. Oh, yeah. We kind of covered the P3 and then the Budweiser.

Chris: Yeah.

Dave: Yeah. Hey! Good for us. 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 X.

[Toilet flushed]

Dave: Fart noise. [Laughter] And join us in the D-d-d-d-discord. That's where things are happening: patreon.com/shoptalkshow. Chris, do you got anything else you'd like to say?

Chris: Yeah. Come for the show; stay for the Discord kind of thing. You know? Probably more happening there than here.

Dave: Yeah.

Chris: See ya later. ShopTalkShow.com? Question mark.

Dave: Bye.

Chris: Dot URL.