Parenting life update, redundancy for leaves, using a chaos monkey, images not showing up based on ISP, modern image handling workflow options, and discussing The Manager's Path.
Time Jump Links
Episode Sponsors 🧡
Hashnode is a free blogging platform for developers who want to plug into the global dev community while retaining ownership of their content and domain.
Hashnode makes it easy to map a custom domain to your blog, which means that the domain authority you build over time belongs to you—not the platform.
Hashnode also has you covered with a massive audience for your content on day one.
It's the best of both worlds: you own what you create without the hassle of building it all from scratch, and Hashnode connects you with your future biggest fans.
Notion is an all-in-one team collaboration tool that combines note-taking, document sharing, wikis, project management and much more into one space that’s simple, powerful, and beautifully-designed. more.
With powerful integrations and seamless navigation, you’ll have everything you need in one spot so you can make speed your advantage — without the silos and context switching that slow companies down.
Plus - Notion has a worldwide network of millions of users creating templates, tutorials, and new inspiration. The product is getting better all the time, and you’ll always have the support you need.
Find out how Notion may be the missing piece your startup needs to grow, get more done, and delight your team in the process.
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier.
Chris Coyier: Yeah, man.
Dave: Hey, Chris. How are you?
Chris: Good. I think this one comes out -- checks notes -- November 1st, which is my daughter's 4th birthday. How about that?
Dave: Aw! Four years already. That's amazing!
Chris: Four years old.
Dave: Four is exciting. But also, a little terrifying because they're right at the height where their head hits the counter. [Laughter]
Dave: A lot!
Chris: Yeah. She's very tall.
Dave: Oh, really? Okay. Okay.
Chris: She's always been very tall, so I think she's already at that level (to some degree). It's been interesting to see her. She's just getting smart. I enjoy that more and more where their brain is turned on, so they can--
Chris: They can understand things and call you out on stuff. I enjoy it.
Dave: Oh, bust you on logic? Yeah. Yeah.
Chris: Yeah. And we're at the total honesty level, too. So, I can't cruise through McDonald's with her, or something, and be like, "Shh. Don't tell mom we did that."
Chris: That's not happening. I'll even say that, and she'll be like, "Okay, daddy. I won't." And then we'll open the door and be like, "Daddy took me to McDonald's." I'll be like, "Goddamit!"
Dave: [Laughter] Why?! We had an understanding!
Dave: The other day, I was solo parenting.
Dave: My wife was at a tennis weekend thing. I was just like, "Oh, I'm solo parenting. Okay. I can do this. I know how."
I'm like, but we're down to one car. Oops, I forgot. [Laughter] She ran off with the car seats, and I just was like, "Okay, kids. Just hop in the car. We'll go to the Wally Burger right by our house. It's less than a mile."
My daughter was like, "No!"
Chris: "I do not have a car seat, and that is not okay." Yeah.
Dave: I do not, and she's like six.
Dave: She can, in theory, survive a trip a quarter-mile.
Dave: But she just was like, "No!"
Chris: Are they just in boosters?
Dave: Just boosters, yeah.
Chris: She doesn't have a five-point, right?
Dave: They're just in boosters. Yeah, so it's like a booster in like a giant F150.
Chris: Here's an encyclopedia. Gees!
Dave: Yeah. [Laughter] But she was not having it. She made the right call. It's fine. We figured it out. Dad made what we call "Panda at home," which is like the Trader Joe's spicy chicken or whatever, General Tsao's chicken.
Chris: Well done.
Dave: We had "Panda at home." We salvaged the meal. But man, she was not having it.
Chris: Mm-hmm. Yeah. I had to pick her up from school the other day and we both just was like, "Why--?" The seat wasn't in my car and I just had no choice. Sorry. Breaking the law there. Don't arrest me.
She wasn't cool about it, but I said, "This is like a--" I don't know. I lied. Double lied in some way.
"Oh, we talked about this. This is a special thing. Remember?"
Dave: Yeah. Yeah. Yeah.
Dave: You're not putting the kid in the front seat. It's not safe. Don't do this, new parent.
Chris: Yeah. We didn't go on the highway. We drove real slow. It's a small town and it was fine.
Dave: Yeah. Yeah. Yeah. But there's just this -- you know, and it's like, "Either we just are stranded here, or we get home safely."
Chris: [Laughter] Yeah. Yeah.
Dave: Kids, man. Kids are wonderful. They bring a lot out of you.
Dave: I taught my kids how to chant, "Dad is the best!"
Dave: And it's great.
Chris: Dad is the best! [Laughter]
Dave: Dad is the best! [Laughter] I'm just like--
Chris: It hits your ego somewhere.
Dave: Well, I'm just like, "If you want more video games on, you better start showing 'Dad is the best!'" [Laughter]
Chris: [Laughter] Yeah, buys you stuff. That's great.
Dave: You want desserts? Yeah.
Chris: That's crazy.
Dave: Here's how you do it.
Dave: Here's the trick, so you know.
Chris: Well, we were thinking about this a little bit because my partner in crime at CodePen, Alex, my literal co-founder, and his wife, Dee, who works on CodePen and has been on this show (probably more than once), they just had kids.
Dave: I think Dee has been on more than Alex. [Laughter]
Chris: Yeah. I don't even know if Alex ever has.
Dave: Yeah, there you go.
Chris: He's been on CodePen Radio, clearly, because that's a thing, too.
Dave: Yeah. Well, congratulations, Dee and Alex.
Dave: That's kind of big. It's twins, nonetheless.
Chris: They're both out, and they're both back-end at CodePen, so it's been on -- not been on, like this is day two as we record. I'm like, [breathing heavily in a panic] "Nobody push anything! Let's just stop!"
Dave: Yeah. Yeah.
Chris: [Laughter] Like, not quite, but--
Dave: One-year moratorium on any kind of development.
Chris: Yeah. [Laughter]
Dave: Yeah. [Laughter]
Chris: No, not at all. In fact, it's the opposite. It's like we need to maintain momentum. There's no reason that because somebody has gone from this company that anybody needs to stop. We've done the work. We have protective measures in place.
But I'm just feeling very, like, while they're off feeling motherly and fatherly over their children, I'm feeling motherly and fatherly over CodePen. You know?
Dave: Yeah. Yeah.
Chris: I'm like, everybody needs to talk to me all the time about everything. I'm your manager now. I know I was before, too, but now I really am.
Dave: Now I'm your double manager. Yeah.
Chris: Yeah. [Laughter]
Dave: I'm filling in here for your manager you actually talk to.
Dave: And-- Yeah, yeah.
Chris: Right. Like writing things down and having little extra meetings and all this stuff.
Chris: It was interesting that they're taking leave because they're taking leave, right?
Chris: But also because they long talked about it from day one, like, "We are going to be out. Let's plan accordingly."
Chris: And we did.
Chris: So, there's that.
Dave: The plan that was executed.
Chris: Yeah, and you were mentioning that it's a common thing maybe in Europe or just generally that--
Chris: --that it's good to have people out, especially if it's planned for, because it highlights stuff in your company, right? Potential problems.
Dave: Yeah. I always admire Europeans in that regard. Americans are like, "Hey, you get four days of vacation a year, but only at Christmas." [Laughter]
But I admire -- I've heard in some European circles where it's like you get three months of vacation or whatever. Two months, let's say.
Dave: It's like you're encouraged to take it because when you're gone not only is your brain getting better and resting. That's actually the key to actually performing at work.
Dave: But your organization learns -- becomes kind of self-healing. They learn to exist without you, which may sound like a threat, like, "Oh, they can live without me?" But you're not integral. You're not a bottleneck on anything. You're not an unreplaceable machine. If you leave, they're not S.O.L. - and stuff like that.
I admire that because I think we should all be somewhat redundant. We should have overlapping skills with people who can then operate in those skills if they need to for whatever reason.
Y'all probably have quite a bit of overlap back-end. I guess Dee and Alex specifically did back-end, right?
Chris: Right, and that's the biggest gap anyway. That's what we're short on anyway. It's a little tricky.
Dave: Yeah, but you have some overlap, I'm sure.
Chris: Oh, yeah. It'll be fine. Plus, you can always turn it off and turn it back on again, you know.
Dave: Beep-beep. Hit the power switch.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Hashnode. Hashnode is a free developer blogging platform. Go over there. Sign up. It's free. It's easy. Boom! Now you've got a blog.
It's filled with features that are good for developer blogs. It's a community of developer blogs, so syntax highlighting and all those features you need for a developer blog, they have.
It's running on Next.js and Vercel, near-perfect Lighthouse score, so nobody is going to accuse your blog of not being super-fast and performant. That's great.
But then publishing on Hashnode ensures that your content can be discovered by millions of users, meaning that you have the blog. It's your blog. In fact, you can map it to your own domain name, so it's totally yours. But it's plugged into the full community there, so it's a fun place to just have an account and go explore anyway because there are loads of developer blogs there, so it's this hive of developer writing, so that's fun.
Best of both worlds. You own what you create there without the hassle of having to build everything from scratch. It plugs into your content into the massive global dev community. Markdown support, code syntax highlighting support, GitHub backups, no ads, no paywalls ever.
Thanks for the support, Hashnode.
[Banjo music stops]
Chris: It reminds me of that dev-ops kind of concept of Chaos Monkey. I'm sure you've seen that too.
Dave: Uh-huh. Yeah, yeah. I think Netflix famously had this Chaos Monkey in their machine that would just throw errors occasionally. Yeah.
Chris: Yeah, certain servers would just turn off and stuff. Then they moved it I think maybe all the way to production, right?
Dave: Yeah! They might.
Chris: They were real super serious about anything can go wrong. In fact, we designed a system to force things to go wrong so that your code and your dev-ops work just--
Dave: You did!
Chris: It's like nothing ever happened. It's so redundant and all that because it's obviously important for a tool like Netflix. Everybody is going to cancel their subscription if every other time you try to watch Squid Game it's offline. You know?
Dave: Yeah. Yeah, yeah.
Chris: Then I somehow remember when Obama was elected and the tech team for Obama wasn't working so hard anymore and got to go take their victory lap of speaking at conferences that they kind of subscribed to the same stuff.
Chris: It's so time-sensitive (an election) that it's not acceptable for a donation form to be offline and stuff.
Dave: Yeah. You need massive tolerance.
Chris: Yeah. Maybe that works with people, too. You learn to be tolerant of missing people.
Dave: Yeah! I think you need it. Otherwise, people just have to carry stuff, shoulder stuff.
Dave: Way too much.
Chris: Part of this was getting more monitoring in place for everything. It's not just like, "Check the homepage and tell you if it's up or not." It's all these different services and all kinds of crap that's monitored.
We kind of were doing that anyway, but now my name is on the list where it kind of wasn't before.
Dave: Oh, you get the emails.
Chris: I'm really, actually not that useful. Like if I get a text at 2:00 in the morning that our server is down, my job then is to look at it. [Laughter]
Chris: I don't know what to do. It's not my skill set.
Dave: Are you tapping the box? You just hit the box?
Chris: Yeah because we really can, these days. There are actual tools, things that I can do now, but it took time to get those into place. Now I am on all these uptime alerts. We literally are using uptime.com, and I don't even know why. There are other ones. Whatever.
Dave: Yeah. Pingdom or something.
Chris: Definitely. Yeah, Pingdom. Definitely not a sponsor at the moment, although we're always for sale. Feel free to hit us up.
Dave: Hey, we also do videos.
Chris: This morning, I was looking through all my stuff to make sure that, no matter what, it screams at me. Like, can I pick a different ringtone, like when I get a text for that one?
Dave: Yeah, yeah, yeah.
Chris: Then I found the place. There's a place where you can designate which contacts break through the focus.
Dave: The do not disturb.
Chris: The do not disturb firewall.
Dave: Yeah. Yeah, yeah. Okay.
Chris: Just doing all that stuff. It felt like the right thing to do.
Dave: Oh, wow. You're advanced here.
Dave: This is good.
Dave: Yeah, I was having some breakages and I recently set up -- I have a server that runs on a cron, and then it falls over every cron job. [Laughter] But it only runs once a month or twice a month. It's just like, "Oh, buddy," so I set up alerting for that.
Some views were just exploding, so I started writing tests. I think I talked about it a few episodes ago. I just went down a big bender on writing tests. I still need to do more for that.
Yeah, I don't know. I might set up Century just because we're having other weird issues where it's just on Firefox. Trent and Reagan were having this issue today.
Dave: They're not getting images. Images in our S3 bucket are not showing up on the app.
Dave: It's weird, but it works for me in every browser.
Chris: Yeah. Does the console chuck anything?
Dave: But they're like two browsers, it works. The console says nothing. We did find a thing where it was sending the wrong MIME type. It was a PNG but it had .jpg and a jpeg.
Dave: But my browsers were all like, "Yeah, that's fine. I know what to do with that," on my machine. Okay? Weird.
Chris: Even in Firefox.
Dave: Even in Firefox, which would be the most--
Chris: Okay, now that's real weird. Yeah.
Dave: Now it's double weird, right? I fixed the MIME type thing, or I just said, "Make sure this is a jpeg, right?" Everyone knows it.
Dave: Now it's sending back MIME--
Chris: Was it a bucket policy thing or something?
Dave: I don't know what's going on.
Chris: No? Okay.
Dave: But Trent has now isolated it. If he is on his cable Internet, Spectrum, which is the old Time Warner or whatever, it does not work. Reagan, on Spectrum, does not work.
Chris: Oh! Some man in the middle action.
Dave: When Trent switches over to -- womp-womp-womp -- AT&T, it works. Like tethers to his phone, it all works.
Dave: I'm on AT&T.
Chris: Can you inspect the packets or some crap or look at the request-response? Compare it, diff it to yours.
Dave: Diff it. I don't know. Yeah, they're getting zero response. Basically, it's almost like a rejected response.
Chris: Oh, there's nothing to diff. They get no data. Wow!
Dave: Nothing back. We're just like--
Chris: Even if they open the URL directly in the browser?
Dave: Even if they open the URL.
Dave: Then it's kind of intermittent, too. It's starting to kick on, so it might be a weird DNS thing or we got flagged or something. I don't know, but we're like, "How do you--?"
The only clue we have is it works on one ISP and not on another. I've never heard of that.
Chris: I don't know if this is going to solve it for you, but I almost never trust bucket URLs anyway.
Dave: Yeah. Yeah.
Chris: I always run it through something else and that other thing pulls it from the bucket. Like even CloudFront can do that.
Dave: Okay. Yeah. Okay.
Chris: Or Cloudflare or something. Then you have an abstraction, too, anyway. So, if you start using those on your website, and you need to move where you host the images, which you should probably move them to R2 on Cloudflare anyway because then the bandwidth is free--
Chris: Yeah. [Laughter] Yeah.
Dave: [Laughter] Okay. Today. Yesterday. Yeah, yeah.
Chris: Then the URLs won't change. The URLs are just the same forever, which is kind of useful.
Dave: I've heard cool URLs don't change.
Chris: Yeah. Although, didn't Jim Nielsen have a good post about that recently? I love old Jim.
Dave: Jim is a good blogger.
Chris: He really is. He had one about cool URLs don't change, like for your blog posts.
Chris: But who cares if your CSS URL changes? That's not subject to the same rules. You know?
Chris: It's like content URLs. User-facing stuff matters. All those other URLs, who cares? The images thing doesn't quite add up to me, but it's more like for developer convenience that you can code it and know that it won't change.
Dave: Yeah. Yeah, that's a good point.
Chris: We screwed up. There's a small area at CodePen where we uploaded to S3 and we gave you S3 URLs to use for your assets.
Chris: Whoops! Now we have to support that weird URL forever even though, for everybody else, we moved away from it. Never give a user an S3 bucket URL because it just locks you into that bucket forever. That sucks.
Dave: Yeah, you're stuck on the bucket. No, that's a really good--
Chris: If you're giving out a URL, you've got to abstract it somehow.
Dave: Man. See! This gets me into things. This gets me onto a discussion.
Dave: Well, there are so many little best practices like that, like never give a user the actual S3 bucket. Always proxy that, right?
Chris: Yep. Always.
Dave: But what tools are there? Now you have to -- there's a dozen ways you could do that.
Chris: Plus, S3 is not -- they don't even want you to do that, necessarily, because it's not really a CDN anyway.
Chris: If you throw it through something else, it could be CDN-ized anyway. That's why I think Cloudflare is kind of a good answer for it. Although, of course, with AWS, it's probably -- they want you to cloud-front it.
Dave: Right. Right.
Chris: But then you get the caching, too, which you don't -- like S3 is not a CDN. It seems like it should be, but it isn't. It has an origin.
Dave: This stuff, yeah, there's probably a really good best practice or something. But then it might not -- but no one is going to help you do it. You have to just read on a blog post it's a good idea or hear in a podcast it's a good idea.
Chris: Yeah or discover. We didn't read a blog post. We were just like, "Oh, yeah. That was stupid."
Chris: And we did it in production on a paid product that still exists today. [Laughter]
Dave: Yeah, and the tradeoff or the consequence is you are now stuck with supporting the S3 URL for some time.
Dave: Or that bucket.
Chris: But maybe the tradeoff originally was, like, but this is easier. [Laughter] There's less technical debt to just give the raw URL.
Dave: No, that's -- yeah, because you could even do some DNS mask or something.
Chris: I think that why I said it was a small period is I think, originally, we didn't. We had an abstracted URL but guess what the abstracted URL was powered by. Our Rails app. We had a Rails route for the image. That's stupid. That's dumb. You do not want your Ruby on Rails app serving an asset. That's a super bad waste of cycles.
Dave: Because now that -- yeah, it's blocked on the thread, right?
Chris: Yeah. It's terrible.
Dave: Every asset request goes through the app.
Dave: Like the CPU.
Chris: No. Bad. Full of cookies and JWTs. Blah. Do not do that.
Dave: See. That's stuff.
Dave: How do you get these answers, man?
Chris: I don't know.
Dave: I also just rolled out a user system or made a user system. Invites, password resets, all the stuff that comes in. You've got login, log out, all users, edit users, edit one user.
Dave: View one user. All these screens, right? It's half a dozen screens, half a dozen actions or whatever. You have to just code them all by hand and then go, "Oh, wait. I have to do that. Oh, yeah, we need that."
Then the minute you're done with it, guess what. You need to support single sign-on. Arg!
Dave: And so, that changes the whole flow. I wish there was just some - whatever - Lord of the Internet, some master, Web Master out there who is just like, "Start with single sign-on and then, if you need the local authentication strategy, that's what you should do."
Chris: Oh, right. Like, this is the best practice. Enjoy.
Dave: These are the views you need. Here is actually a sample HTML for all those views.
Chris: Right. Here are your components. Here are all the states for all those.
Dave: Oh, you're going to set up an email invite system? Bless your heart. Awesome. Let's do it, but here's the token.
I felt like--
Dave: Here's the whole token redeem, token expire system. Here's the system, like, "Oh, click this checkbox and get some - whatever - text to login thing." I like Notion's, "Hey, we emailed you a password." I love that. I just think that's--
Chris: That's Magic, magic.link. Not a sponsor, but they're actually really cool, and that's probably the right answer for a lot of apps.
Dave: I feel like it's probably the right answer, and so I don't know. I just have--
Chris: But you know what makes me think about with you, Dave, is that you've been so focused on prototyping for so long that this is an extension of that. You're like, "What is the easiest thing I can do (in the spirit of prototyping) that gets the job done but does it in an acceptable way?" You know?
Dave: Yeah. What gets me there? What gets me up and going?
Chris: I was at a local meetup the other night. He said, "I made a little app. You can buy tickets for concerts on it. You can pay, too."
Chris: Then there are a couple of little bonus features, which made it a unique startup. It had something where it texted you after the concert and you could give the band more money if you really enjoyed yourself, or something really weird like that.
Cool. Now it's a startup. Sell it. Go on Shark Tank. I don't know.
But the point of their whole talk was, "I built this thing super-fast. It only takes Stripe. I didn't build any payment UI." It just uses all Stripe prebuilt - here's your signup form, anything - so payment took one minute to install.
Chris: The longest thing was probably waiting for approval for your fricken' Stripe account. But then he made this bold assertation. I think he was a little old-school. Although, maybe that's not fair.
Chris: [Laughter] It was so interesting. I'm like, "Is that still the right answer, though? I kind of agree with the Stripe thing because that's like, "Yes, please. Let them do all payment everything." Sure, use Twilio.
Dave: I don't disagree, to be honest. I think if I was doing Rails, I'd be done by now - or whatever. [Laughter]
Chris: Oh, really?!
Dave: Rails have devise. I don't know. All that authentication stuff, you just gem install devise and you get all that stuff for free.
Chris: Yeah. We still use auth gem. You know?
Dave: Yeah. I mean why not. Why reinvent the wheel there?
Chris: We have a little bit of extra fanciness on it, but very little.
Dave: Yeah, and so it's like gem install devise and then you can devise eject from devise, basically. You say, "Generate all my templates," and then you get all the templates for all that I described, like login, reset, blah-blah-blah. All that stuff is already there.
I don't feel like the Node world caught up on that - or something - because I guess we all OAuth only. [Laughter] I don't know.
Chris: Yeah. I don't know if that's a super great idea, generally. I like offering it, but I think you should have a database of users that has a way to--
Dave: A local authentication strategy.
Chris: Yeah, because then you're just less reliant on what if the one goes down or whatever. I don't have fully fleshed-out thoughts on that, so I might punt. But I do think it's a good point that there's maybe not a Node thing that wins yet because I'm tempted to say it's kind of like Next.
Chris: Next feels like the Rails-ish of it.
Dave: Yeah. Yeah.
Chris: Although, it offers much less. But it feels like, UI-wise, that's a maybe better choice than Rails is. You can build out your front-end better because then you can also pick a component library, too. Like the bootstraps of React are better, actually, than Bootstrap because they're not just visual. They'll handle fancy crap too like sorting your tables.
Chris: They help you with running your functions and stuff, but who is the Next of data? I'm sure FANA would say they are, or Prisma, and that type of stuff. But they're definitely not as integrated and built-in as Rails is.
Dave: There's not one. I've been looking at Supabase, which is cool.
Chris: No AWS thing. There's stuff, but it's not Rails level.
Dave: Well, Supabase has an authentication product. It has a login with Google, a single sign-on social provider or whatever.
Chris: Okay. Okay.
Dave: But it's so weird to me. It's like, "Why is my database--?" [Laughter] "Why does my database have a cloud login - or whatever?" But it's just like the product lines are confusing.
Chris: Because Firebase did.
Dave: Because Firebase did. You know what I mean? But it seems cool, and that's my thing, too. And they have these neat little rules where, if you use their thing, you can just click a button and be like, "This is a protected route," and they do manage Magic links and stuff.
Chris: Yeah. You need permissions and roles. If they do your auth, then they can help you with roles, too.
Dave: And so I'm just like, "Oh, maybe I should have built this all in--
Dave: I should have built this all in Supabase. I think we're actually using the Supabase Postgres image. Maybe I should do this.
Chris: Yeah or Firebase.
Dave: Or Firebase. Uh, yeah. I have Firebase. I don't know. Over time, I've logged in and I felt more and more lost, but that's just me.
Dave: I've used it on a couple of little toy projects, but I just never felt like--
Chris: What worries me is that the database of it is totally unique to itself. It's like your knowledge of how that all works is not GraphQL. It's not really Rest. It's a special API just for it and your knowledge of it lives and dies with Firebase or Firestore is what they want you to use.
Dave: Yeah. Firestore. Yeah. Yeah and I've been bit, too. It's like it only lets you store objects and never let you store arrays of things.
Chris: Yeah, little quirks.
Dave: I think that's what it was, the limitation. It was just like, "Ah, man!" I don't know. I know how an array works. I just want to send you an array. It's like, "No! Object."
Chris: [Laughter] Yeah because you have to reference it again in a special way or whatever. All right, well, that's that. Okay. Rant over. Two old men shake fist at new Internet.
But I want to like the new thing because, honestly, I wouldn't do it. If I was alone and was going to spin up a thing, I wouldn't fricken' pick Rails. I don't have the depth of experience you do. I would pick something else and just struggle through it, probably.
Dave: Well, and that would be my thing, too. Rails is cool. I think you sort of limit who can work on it or you inherit quite a few environment problems, I would say, historically. As cool as Rails is, you sort of end up with a lot of, like, "Uh-oh." [Laughter] "This is now -- how do we do this?" You know?
Chris: Back to Docker town.
Dave: Yeah. Now you're in Docker town and it's 700 gigs on your machine, but it spins up one Ruby server in one database.
Chris: Yeah, and it isn't even that satisfying whereas Next, you're like, NPX new Next project. Instantly ready to rock. Hot modular reloading. Super, super, super fast.
Chris: Hmm. Compare those DXs.
Dave: Nope, there's a difference.
Chris: You're like, "Suck it!" Yeah.
Dave: Yeah, but to Rails' credit, they were like, "We are solving problems you have with an application, like running applications."
Dave: Authentication, active record, how you store memory and stuff in a database, how you set up models, views, and controllers. It was very strict, but even the testing database, you could be like, "Okay. I'm going into test mode. Use my testing database."
Chris: This fight will go on forever. We can do this podcast. Let's meet again here in 2032 and talk about the same crap.
Dave: 2032, and we'll still talk about "Is Rails good?"
Dave: Maybe Rails is good.
Chris: It'll be some VR chat app or whatever. That's not even thinking big enough. Ten years is a long time in tech, man. Hard to predict how weird that's going to get.
Dave: O, yeah.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Notion. It's just my great pleasure to have Notion as a sponsor because I'm just such a big fan as a user and use it on literally every business I run, as well as just personally.
Notion, of course, being that app that's like a document kind of based app. You can use it for notetaking, but it's much more powerful as like calendaring, kanbans, databases, knowledge bases, and just all kinds of stuff. It's unbelievable what we can do. For startups, Notion can provide really a full-on operating system for running every aspect of your company, keeping everyone aligned as you grow fast and take on more.
At CodePen, we use it for project management. We use it for our weekly check-ins where we're writing down what we're doing and talking with each other about it. We use it for planning the podcast and scheduling things and dealing with advertisers. We have public documents. We use it to make a document for a job, make it public, and use that URL for hiring reasons.
There are just so many things that Notion can do (it's so great) particularly for startups. I've seen so many startups be successful with it.
Interested? Want to find out more? Notion is running a special offer just for startups. Get up to $1,000 off Notion's team plan by going to notion.com/startups.
To give you a sense, that's about a year of Notion for a team of ten, so a pretty good deal. Again, that's notion.com/startups to receive $1,000 in free credit to use Notion with your team. That's a $1,000 value when you go to notion.com/startups.
[Banjo music stops]
Chris: Yeah. I'm going to hit you with one.
Dave: Hit me.
Chris: We can attempt to do this, and then I'll turn it into a blog post, maybe, if it's satisfactory.
We've talked about modern image formats enough. I just saw another Addy post on Smashing Magazine about using WebP and using AVIF, stuff he surely covers in that book. Remember, we joked about it on a video. You had it on your shelf. It's this bookshelf that's eight inches thick, essentially, about how image formats work.
Dave: Yeah. Yeah.
Chris: But let's say we focus that just to AVIF because it's an interesting format, right?
Chris: It's almost always the winner.
Chris: When you move stuff to it. Very pretty impressive. Notably slow. Although, Addy pointed out in the post that the trajectory of improvement on that is looking good.
Chris: If you look over the couple of years it's been around already, it's going to get fast - eventually.
Chris: But it is just notably way, way slower than any other conversion. But let's talk about the different ways in which you could use it. Let's say you wanted to make sure a blog post of yours, Dave, had an AVIF image in it. Would you just handcraft it? What would you even reach for at all to make sure you had an AVIF copy of just a screenshot or some crap in a blog post?
Dave: This kind of came up because I put a 300-kilobyte jpeg on my site. I was like, "Oof, man! Could that be better?"
Chris: Like your cool warrior dude is 300k?
Dave: No, it was just in a blog post.
Dave: It was like a screenshot of my site or something like that.
Dave: I just was like -- and I crunched it. I squooshed it. I resized it. I did everything. It was still pretty big. I just was like, "Ah, man. That would be cooler if it could be smaller," but I think the transparent rounded corners on the thing were killing it.
Chris: Oh, sure.
Dave: On the UI there. So, I did kind of go down this mentally, like, how would I do a WebP or an AVIF if I wanted? But then I just was like, as a static site, I don't really have a differential serving machine. You know? I can't serve different formats, really.
Chris: Yeah. Netlify doesn't. They have an images thing, but it's pretty complicated, isn't it?
Dave: Netlify has a very cool images thing. However, you have to use get LFS.
Chris: Yeah, man. I set it up once and I was like, "No, I'm not going to do that."
Chris: Yeah. Get LFS is a little bit problematic. I don't even know what was the issue. I started going down that route and then I just was like, "Yeah. No thank you."
Chris: It's just use, maybe. What killed me is that if you collaborate with anybody, they need to go through the dance, too, with get LFS.
Dave: Yeah. Yeah. Yeah. Yeah. Yeah, it's not. Yeah, and if they are not get LFS, the whole thing is like, "Yeah, you don't get it." [Laughter]
Chris: Fail states come back.
Dave: You can't commit to it. Yeah, I think so.
Chris: Anyway, it's not that it's a terrible feature or anything. There's got to be something else to do, or something.
Dave: I should probably do that, but I think what I ultimately need is media.daverupert.com.
Chris: Oh, your own little media server. That's a clever idea.
Dave: I need a bucket that is fronted by something: CloudFront or something or Cloudinary.
Chris: Maybe. Yeah.
Dave: That's where my images go, and then they serve the correct image format.
Chris: But then you start thinking about workflow. Do you visit some UI for that thing and upload stuff with the little cool UI and then browse and then get the Markup for it and copy and paste it over, or is it more transparent? You just put a .jpeg image and the build process sees it and does magic on it?
Dave: See. Yeah, I don't know. I think it would just be like I put it in the bucket and then my local URL is the media URL.
Chris: Maybe this should be part of your 11ty conversion, though, because I know very applauded is 11ty image, which I think you just link up one image and, during the 11ty build process, it makes the different versions and changes up the HTML for you to have picture and all the sources.
Dave: Yeah, maybe. Maybe I could totally do it in 11ty image.
Dave: That's at build time, right?
Dave: All the zapping images, yeah?
Dave: I'd want to see how many images I have. I kind of like the--
Chris: Does it put it on a CDN for you, though?
Dave: That's true. Yeah, right. It does. Wouldn't Netlify spawn it out to a CDN?
Chris: Yeah, I guess if it's on Netlify, it's just naturally on a CDN. Yeah.
Chris: Yeah. Fair enough.
Dave: It's probably smart enough to incrementally build or something like that.
Chris: Probably. Yeah, that sounds like it. I think you checked all the boxes. We did a video about this not long ago, the checklist of stuff that images have. It's not just formats. It's optimization, too.
Then it's also put it on a CDN. The list goes on and on of things you need to do. Resizing all the versions and all that stuff. There's a lot.
That's why I mean workflow. It's like what do you want the workflow to be? How much work do you want to do every time you do this?
Of course, the answer is, very little. But then the setup time is a lot. Then you're investing a week in your dumb little media workflow. It's just a blog. My god. Get over it.
Dave: Yeah or it's like, "Am I really going to--? My blog is a stat server, a media server."
Dave: A www server. You know? All my subdomains from my little apps. Each one of those has subdomains. Where it is overkill? It's hard to say. Something automatic would be kind of nice, but I do like my sub-one-minute deploys on Netlify.
Dave: If I do image stuff, that probably takes that out of there.
Dave: Maybe. I don't know. Tough to say.
Chris: I'm not experienced with it but, yeah, that would be a bummer if that one thing is what blew out your build time.
Dave: Mm-hmm. Yeah. I need to investigate. But I'd like to get it solved. I mean next-gen image formats are a very important thing.
Chris: Think of all that complication. Then that's just one type of usage of it. There's another type of, like, let's say you have an app where users upload images. Well, that's a whole different can of worms of handling it.
Dave: Yeah. Mm-hmm.
Chris: It's more of a one-off, but it's a mass conversion. Let's say you need to make 2,000 images AVIF.
Chris: Then what's the tooling like? I just think all this stuff is fascinating. You know how we had broken up the industry. Now there's dev-ops people, and now there's back of the front-end people.
Chris: There are all these different specialties: performance people, accessibility focused people. It's almost at the level of media people.
Dave: Nah. Yeah, how do you handle assets? Yeah because it's hard stuff. Then you think, "Oh, we'll save bandwidth."
We had this problem at a major pizza company. [Laughter] You're like, "We'll save bandwidth and just compress the crud out of these images." I think they were getting very large images from marketing, and so they had to set limits, like, "Okay, we'll do it, but it has to be X hundred KB, or something."
Chris: Yet another weird kind of workflow.
Dave: There are humans involved, right? There are humans. It's not just put images on webpage. There are also humans involved.
And so, there was all this, and then it would smash the image down, like use some really aggressive Lossy compression. It was turning out really bad because of the brand color was red or pizzas are generally kind of red and beige.
Dave: Guess what colors each shit the most.
Dave: Red. You know?
Chris: Oh, really?
Dave: In compression-town, you know.
Chris: Yeah. That's too bad. I didn't even really think of that, that much, that colors lose something, vibrancy or whatever. I'm sure it depends on the color space.
Dave: Yeah. It's like it sees red, and it's just like, "I can do stuff with that."
Chris: Wow! What an interesting problem.
Dave: Quantizes, I think is the right term. Anyway, yeah, it was a unique problem. And if they weren't using red, they probably would never hit it or it would have probably skated through a bit longer.
Chris: Yeah. Yeah.
Chris: We had to punt on AVIF usage. We were just rewriting almost like an onboarding project for an employee. Let's rewrite and modernize our screenshot process on CodePen and do some different things. Maybe we'll make our own sizing and stuff, so we're using Sharp, this classic Node-based library for image resizing stuff.
There was an interesting one (I thought) that came up. Let's say you need seven sizes of an image. It's tempting to write something like, "Here's the base image. Now make one that's 800 pixels wide. Now make one that's 600 pixels wide," or whatever, that you can somewhat trivially rewrite that code to make the 800 pixel wide one and then make the 600 pixel one from the 800 pixel one and make the 400 one from the 600 one.
Chris: It feels like maybe that'd be slow. What does it got to write one to disk or something before it does it? But it turns out it's like 40% faster.
Dave: Oh, really?
Chris: Yeah, it's very significant savings. It's that kind of thing. Where does that knowledge come from? I don't know. I think that's how computer science people think. Despite all our years in computers, it's been more of, like, "Just make it work and move on," rather than apply science.
Dave: Yeah, that's true. There's probably actual academic research that fixes the problem. Then there's just, "Oh, it worked. I got it to work." [Laughter] That's a whole other class of whatever - science.
Chris: Yeah. I kind of like that aspect to it, but I get how we've just had that desire many times over the years at CodePen. We got it going. We're somewhat happy, but could a computer science person come in here, please, and have a look?
Dave: Yeah. Yeah.
Chris: Is there computer science people for rent? [Laughter]
Dave: Yeah. "Oh, you want the double binary sort."
Dave: You want the double switch flip sort.
Chris: Right. It's like I could probably install a new light switch in the bathroom but, ultimately, I want an electrician to do it.
Dave: Right. Right. There's somebody who knows how to do it. Setting up a stereo or whatever, yeah, it's just like you know how to do it. [Laughter] Yeah. No, there are experts for everything, man. Every problem, usually, you can get to the step one.
Take a screenshot. You know how to do that. Did it. Fired it up. Puppeteer. Did it.
Step two, there's a giant cookie consent on the page. [Laughter] How do you dismiss that before you take the screenshot?
Chris: Oh! We had that exact thing. We're using a URL that we have to be really protective about because, on CodePen, if we have routes that render crap, they can be abused because you can make an HBC login for them and send it to your email list or some crap.
In this case, it was a route that's pretty protected but has an extra, another bonus protection that's almost like a watermark. We put a big banner across the top that's like, "If you've arrived at this page and don't have the exact perfect set of credentials but somehow you're seeing it anyway," there's a big black things that's like, "Warning!"
Dave: Warning. You're probably going to--
Chris: "Do not enter your credentials onto this page," kind of crap. [Laughter] Somehow, our screenshot service was able to screenshot it, and they all had the fricken' black bar on the top. [Laughter]
Dave: Oh, brutal. Yeah.
Chris: Whoops. But we caught that long before production, but a funny little moment.
Dave: Well, and that's just it - every problem. Then you're like, "Okay, cool. Now let's run Puppeteer on Windows." Oh! Failure!
Dave: There are always two steps after that first step that get brutal.
Chris: Yeah. Yeah. That's cool. You know it turns out it's kind of survey season around here, isn't it, recently? I saw the CSS survey thing is going around. I saw Gina tweeting about the design system survey thing going around. There was a--
Dave: Jamstack survey.
Dave: You know [laughter] it's interesting. I think people like to say immediately, "Oh, this is very self-selecting and biased and bad." I agree. "Hey, people in my sphere of influence who also like my type of development. Please go vote up my favorite framework and your favorite framework over on the newest survey machine." You know?
Dave: I think you expose a lot of bias and stuff like that. Self-reporting, in general, is actually pretty prone to nonempirical data.
Chris: Yeah. Like if you're going to tell me what you use, maybe looking at my GitHub is a better indication of it than asking me to select the correct radio button.
Dave: Yeah. There's optimism bias sort of stuff, too. I use this because it's good. You aren't able to think critically about maybe some of its problems. Actually, I'm actually not happy with whatever: Svelte, 11ty, or something like that. You're just like, "I chose it. It's fine. It's good."
I don't know. I think there are some biases that could show up in a self-reported test like that. But I will also say I don't know that we don't have anything better. Nielsen ratings, or whatever -- Is that who does it? -- they're not calling a robo-dial of developers to ask them their opinions on stuff. There's no TV rating system for frameworks and stuff like that. We kind of just do the best job we can, and so maybe we should--
Chris: But do you have a good sense of what the final value of it is? Once it's done, let's say it was done as it could possibly be done with the lowest bias could possibly be done and the visualizations at the end are perfectly fair and done by a data scientist. Why?
Dave: Yeah. I think people like to know trends.
Chris: Fun, almost. They just like it.
Dave: I think people like it. I think when you get into gender and geography and pay, those eliminate some pretty interesting discrepancies, like pay gap sort of things and stuff like that. I found it interesting, the state of CSS. There seem to a female bias toward saying, "I do CSS," and stuff like that, so just kind of interesting. Then there's a pay discrepancy.
Chris: So, if you know that, you can point to the data and be like, "Look. There's a pay gap, and I'm not making it up."
Dave: Right. Right.
Chris: It's right here.
Dave: Yeah. You don't feel as gaslit because now you have a little bit of data to sort of--
Chris: Yeah, that's a good reason.
Dave: --match your real-world experience. Maybe you can use that to leverage a pay increase, like, "Hey. I do the same work, but I'm getting paid less."
It's hard for me. I was telling my wife this. As cool as this macro study of the macroeconomics of Web development is, I can come up with maybe there are other reasons or something like that. Maybe CSS people skew older and that's why we get paid less because we just literally got a job (thank God) in the crash of 2001 and the crash of 2008. We're like, "You know what. I'm just happy making money, so I'm going to stay here."
I'm not going to be like, "You need to pay me more." We came in kind of on the softer side or something. I don't know.
Chris: Wow! I haven't heard that theory before, but I like it.
Dave: There's some data to suggest if you graduated college in a recession--
Chris: Certain years.
Dave: --you're paid less over time. Something to the tune of like $500,000 over your....
Chris: Because psychologically you're like, "Welp, I've still got a job, so that's good."
Dave: Yeah. Yeah and so you're not angling for the $80,000 job. There's geography, too. You could say U.S., but different parts of the U.S. pay way differently - even though I think that's really stupid. I don't know. I don't get that. If you're paying for work, it should be the cost of work, but I'm sure people in San Francisco are like, "I need to get paid more because houses here are like $200 million," and I understand that. But I don't know. Yeah, it's different worlds, so I don't know. There's so much relativity. I guess it's hard for me to see the absolutism.
Chris: Yeah. I'm not necessarily. I was really just genuinely curious.
I heard some pushback, like, okay, there is going to be bias in this thing. Then even though it's pointed at or acknowledged, the data then still exists.
Then let's say it has a bunch of information about what technology people are using and what they care about. Then a company like Google or even the W3C or people that influence and make the Web use the data in there (biased anyway) to make choices about what they work on and what they're going to do and stuff. That's weird, right? It's almost like a weird net negative. Rather than this being this thing that's supposed to help, can hurt.
I mostly look at it and be like, "Oh, cool. React is popular." I didn't need a survey to know that.
Dave: [Laughter] Yeah, I get value out of it, but yeah. I understand the same points. For me, I actually have a hard time answering the quizzes because they're like, "What do you use, man?" It's like, "On which project, because I've got 16 projects. They all use different stuff. Which one are you talking about?"
"Yeah! What do you use? Do you like it?" I hate those people. No. [Laughter]
Dave: I might like it if it was well set up, if it was working for me. But right now, it just feels rough because it got dumped on me - or whatever. There are different levels of enjoyment, and stuff like that.
It's hard for me to answer some of these questionnaires because they're very much designed for one person in one desk working one job on one project. It's not for people who have a blog and a podcast and ten different jobs or ten different clients and stuff like that. It's not really designed for people like that.
Dave: People touching their toe into management or senior leadership or something like that.
Dave: There's that too.
You know what book I read recently and I really liked was The Manager's Path by Camille Fournier.
Chris: Oh, you said you just finished it recently, right? Yeah?
Dave: I like this, and I'm looking forward to Sarah Drasner's book, too. But it does a really good job of being senior tech leadership and management. It gives you a role: tech lead. Here's what the tech lead must do.
Senior or team leader or, I guess, that would be a tech lead, but senior engineer: this is what they must do. This is what they're responsible for. This is what they expect. This is what's expected of them. A manager: here's what they must do. A manager's job is to get people promoted.
Dave: I just was like--
Dave: I just was like, I love when people draw lines in the sand and are just like, "Here it is." I like that, but I think, too, could these surveys produce something like that? Here's a senior manager. Here's how much they should expect to make in whatever geographies. Here's what they should know how to do or their task list.
I would love stuff like that. I just really appreciated that it was just very, "Here's what it's about. Here's the role. Here's what it needs to do."
Chris: I like that. I wonder, how do you--? Do you find yourself--? You always worked at small places and you work with clients, so it's almost like the clients are your managers.
Chris: It's interesting why you're so into management stuff.
Dave: Well, there is one. Well, it came back as working somewhere (not to be disclosed). I had a very bad manager. I had a very bad manager. I had a very bad scrum master. I had a very bad couple levels of management, but I was split on six different projects or something like that because I was asked to work on them.
I looked at my org chart, and it's like I have six or eight different managers telling me what to do and my own company. I'm kind of my own manager. It was really hard to balance inquiries and requests because I don't think they had any visibility into the other stuff I did. Each manager didn't know what else I did. You know what I mean?
Dave: They're used to managing one person who sits in one desk and does one job.
Dave: So, that was really hard, and it launched me on a path where I just was like, "What is good management? Because this is terrible. What is even good agile because the agile I'm experiencing is terrible. I can't imagine anything -- I don't see what's redeemable about it." [Laughter]
Dave: I've softened my opinion there.
Chris: Anything else you liked about that book?
Dave: You know I think it's really good. I love how it just puts the onus on managers, like, "It's your job to do a good job and help your employees." [Laughter]
Dave: I thought that was good. One other thing it said is there's a dichotomy between CTO and VP of engineering, which you'd think, "Oh, they're just engineering nerds."
Chris: Yeah. I've never thought about that.
Dave: Yeah, but the distinction she made was like a CTO cares about the technology stack, like are we technology leaders using these services, this blah-blah-blah, this structure, blah-blah-blah. The VP of engineering cares more about the people in engineering.
Chris: Oh, my god. I would have thought it was the exact opposite, if I had to guess.
Dave: Kind of. Yeah, right? But that person is in charge of making sure everyone has what they need. Then there's even probably a senior engineer or a team manager or principal engineer or something like that. I forget the actual title. Sorry. I wish I knew. You'll have to read the book. It was just kind of like your job is to help people, like developers be successful, almost like a DX role inside your company.
Dave: If people are struggling to get up environments, it's your job to do that. If people are struggling or they're always fighting fires and they're always running around with their heads cut off, that's your job to fix that, to lower that temperature.
You need to provide tooling. You need to figure out what tooling people don't have, need, or whatever. Your job is to produce, ease the burden of the organization. I thought that was cool, too, because so often it's not that. It's the new kid who's just like, "Whatever. I just made a docker file, so good luck." You know? [Laughter]
The ownership gets messy, and so I thought this put pretty clear lines on who owns these jobs.
Chris: Yeah. That's an interesting way to think about it because you have certain things that you can watch for and outcomes that are on you, so you need to get productivity out of people. If that's removing a barrier here, then that's on you to do it. Lower the temperature, as you put it, or just solve whatever problems need to be solved.
I'm curious if it gets into that. Very fascinated by the, like, people are super different from one another and they need to be managed in different ways.
Chris: I don't know if "managed" is the right word, but everything in different ways, like how much you talk to them, how you talk to them, how much feedback they need, how much direction they need. Are they more written or are they more visual or are they more audio? Having a profile of each person, should you be doing that or should you be trying to morph them into how your organization operates?
Dave: Right. Yeah. I think it sort of addresses that. I think, to some degree, it does. Probably not to the degree that somebody like Lara Hogan's book for her A Book Apart book, which is really good. She gets kind of more into the tactical assess the person, like, "Hey. This person has response to this positively."
She was on the show, and she says, "What makes you grumpy?"
Dave: If you know that about a person, you can actually make decisions or tailor messaging or something like that. There was a good section of Camille's book that was how you relay news. If you have some people who, if you have bad news -- we're cutting a project, a department, or something like that -- you may want to strategically figure out how to roll news down. Some people are just like, "Just tell the whole group," but some people are like, "Let's tell this group first," or something. There's maybe some strategic moves you can make in how you relay news or whatever.
Yeah. I think I would probably do -- I would probably look at Lara's book for that question specifically. Meeting people's needs or meeting them where they are.
Chris: Yeah. I wonder if she's found that that's been highly effective for her or if it works in reverse, too. Did it work for you because that's how you operate as a manager and not all managers it will work for?
Dave: Yeah. Yeah. Do these books sort of self-select? Yeah.
Chris: I don't know. [Laughter]
Dave: Yeah. I don't know. Yeah. [Laughter] It's maybe management itself self-selects, but you have a high tolerance for dealing with people.
Chris: Yeah, it might. It's funny how much talk about this is. We don't set out to talk about this. It just comes up a lot.
Dave: Every person is either managing or being managed, unless you exist on some island.
Chris: Wow. Maybe that's why. Yeah.
Dave: You know what I mean?
Dave: I was in a chat the other day. We've got to wrap this up, but I was in a chat the other day. Some people are at management level or they have people under them or whatever.
I just was like, "Do you get feedback, like reviews, or is it only your senior management that reviews you?" In the 360 feedback cycle. They were like, "Oh, we get reviews." But I'm like, "How does that impact you?" because I've only [laughter]--
In a lot of organizations I've been with, the cool managers peace out, and you're left with the dumpy managers, right? Then you're like, "Wait a minute. What happens? Why don't the dumpy managers get fired and why do the cool managers leave and the dumpy ones stay?"
I'm saying this as an outside consultant. I should not care, but it does impact my life.
Dave: When the person you liked in the group is just like, "I've got to go," you're like, "Wait a minute. Who is my boss now? No!"
Yeah, so it impacts people. I think it 100% relates to turnover. It's massive. You've really got to -- it's really important. I think management doing it is really important. I think it's weird that people can become managers without taking a course or a certification or something [laughter] because you impact people's lives very immediately.
Chris: I agree, sir. Let's wrap it up, I guess.
Dave: You know the drill. Like it! Do the Twitter.
Dave: Tweets, 16. Patreon.com/shoptalkshow. YouTube, we do videos now. Like and subscribe. Chris.
Chris: That was good. That was the most unique one in a while.