432: SWYX
Shawn Wang, known as Swyx, talks with Dave and Chris about his career path from finance to coding, and now in developer experience. They chat about serverless functions, React, getting a broad sense of technology, Wang's Coding Career Handbook, what's next for SSR, checking out Vite, and what exactly is DevX / developer experience?
Time Jump Links
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave, in the house with the kids doing the homeschool. Oh, gosh. We're still doing it--Rupert. With me is Chris--
Chris Coyier: [Laughter] It doesn't sound like that's going to change any time soon, Mr. Dave. Yeah. Yeah.
Dave: Well, you know, it just keeps going, doesn't it? Welcome to 2020.
Chris: Yeah. My back, I'll tell you what, though. Just an important follow-up that I'm sure everybody listens to this show cares about. My back is totally fine. It's healed. It's great.
Dave: Yeah.
Chris: My chest and legs, on the other hand, after being hit by a fricking van, are less okay. [Laughter]
Dave: Yeah, I was going to say, you solved the back problem by getting hit by a car.
Chris: Yeah. I can't recommend it enough. You know your back hurts.
Dave: Yeah. [Laughter]
Chris: Just stand in front of a van. Please don't do that.
Dave: Best chiropract-y world you could by, really, you know?
Chris: [Laughter] All right, well--
Dave: All right, man. Hopefully, you're feeling better.
Chris: No, and it could have been a lot worse. This was just me hitting the pavement. The van was barely involved other than forcing me to do it.
We have a special guest on today, which is fantastic. We probably should have had him on a long time ago because we're big fans on the show. A very interesting fellow with a very interesting career and just a big thinker, I think, about a lot of things front-end Web development. It's Shawn Wang, probably better known to the world as Swyx, though. We've mispronounced that and screwed that up about ten times on this show, I think. How ya doin', Swyx? [laughter]
Shawn Wang: Hey. Thank you so much for having me. Long time listener. First-time caller. I love saying that.
Chris: [Laughter]
Dave: [Laughter]
Chris: Sure. Well, we really appreciate you being here, taking time out of your busy Amazon-related day these days, right?
Shawn: Yes, sir.
Chris: Yeah. What part of it? I have literally no idea. Are you on Amplify or something AWS related or not even that? What's up?
Shawn: Yeah, totally. It is Amplify. Amplify is kind of like where you will see most of the front-end related stuff coming out of Amazon, but there are other, obviously, thousands of Amazon employees working in front-end not serving front-end developers.
Chris: Yeah. Well, surely, right? Amazon is awesome that way. When I said Amplify, I just threw a dart there. I can't believe I hit it. That's awesome.
It feels newish at Amazon because I think a lot of people think of Amazon as, like, they have AWS. Let's focus it on that. We know that it fricken' runs half the Web or whatever. I don't have any actual metrics, but a lot. At CodePen, we use a wide swath of AWS services all the way from just spinning up servers, databases, and stuff to stuff like serverless abilities and all that.
You don't often think of it as the most simple stuff in the world. It's the metal. It's low-level stuff that you build other stuff on and there are lots of companies and businesses in the world that exist off of the infrastructure of AWS knowing that it's this complicated infrastructural stuff and that's how it's supposed to be.
Directly from Amazon, that doesn't have to be the case. Amplify feels like a stab at, no, we can offer simple, useful stuff directly to developers, individual developers as well. That's what Amplify feels like to me. It's like, here's auth. Here's a data store. It's easy. Look. [Laughter] How did I do? Is that anywhere near--?
Shawn: I think you did a pretty good job. Yeah. Yeah. I don't know if I would ever use the word "easy" because the moment you fall into some kind of edge case or other, you get complaints about that. But I think, definitely, it could be a lot easier for front-end developers.
Amazon is a very generalized computing platform but the developer experience hasn't necessarily been optimized for front-end developers. Amplify is actually very focused on that, kind of building a layer to interface with all the other stuff that you have to use to get going with Amazon with best practices like confirmation, but you don't have to learn it. You don't have to do that to get started.
I think what sets it apart from, I guess, other cloud services is that because it's provided by the cloud itself, you can actually, I guess, eject. You're just using the raw, super-scalable services underneath.
Chris: Oh, I didn't know that.
Shawn: Yeah.
Chris: That's cool. That's cool because you might be like, I'm going to start on Amplify but at least then I'm still on AWS. If things get weird, I can jump out of whatever Amplify has given me, but I'm still in the right place. [Laughter]
Shawn: Yeah. Yeah, it's actually open-source tooling, so it's a CLI. It's JavaScript libraries that are kind of SDKs that interface with the infrastructure that you spin up. All this is open source and it spits out raw confirmation that actually spins up all that infrastructure that you might need. Yeah, you can totally eject and I think that's the thing that's underrated because it means -- I think there are two things that it means. It means that you can't take over and customize anything that you particularly want, but then, also, there's no cost. It's who you're using as open source and you're using the lowest level primitive that AWS offers. There's no sort of intermediate vendor cost in between. I think that's an interesting pitch from that angle.
I think it ends up that, actually, Amplify has two customers. Even though it's originally intended for front-end developers and mobile developers, the back-end teams who are familiar with AWS are also finding it easier to spin up services that they're comfortable with using Amplify as well.
Chris: Oh, because of the scaffolding, the CLI stuff?
Shawn: Yeah. Yeah. Yeah.
Chris: Yeah, okay.
Shawn: [Laughter]
Chris: Cool.
Shawn: It actually works out that it kind of has two masters, which is an interesting prioritization from a product perspective because the people who are very familiar with Amplify, with Amazon spend more whereas the people who are kind of just trying it out, dipping their toes in, may not spend more but they may be numerically larger. You kind of have two priorities there. Do you serve the power users or do you serve the newbies? I'm sure anyone who is working on a product has done this.
Chris: Well, certainly you get serverless functions as part of an Amplify setup. Sure. Right? Okay. I want one of those. Via CLI, it's got deployment, too. Do I type amplify-deploy or something? Is it as easy as that?
Shawn: Publish, amplify-publish.
Chris: Okay.
Shawn: Mm-hmm.
Chris: It's almost like, then, competitive against something like serverless.com, right? It's like I might use that because they helped me get stuff onto Lambda because otherwise, that's not the most ergonomic thing in the world. They've built their whole business around that, essentially. But now, all of a sudden, you've got a player directly in that I can use Amplify as my carrier to getting stuff onto a Lambda.
Shawn: Yeah.
Chris: Or on anything else, too. I didn't mean to just focus on Lambadas, but that's where my brain is at a lot because I think serverless functions are cool and the story to get them live and maintain them is often a bit weird.
Shawn: Yeah, totally. I think you have that right, I think, that perspective, because you and I are front-end. It's so weird to say you and I because I'm not anywhere as experienced as you are, but from our front-end perspective, serverless functions are only as useful as their exposure to public Internet. But we have to remember that the vast majority of service functions are internal. They are sort of glue code on top of existing staging just from databases, for example, or between different micro-services, all that kind of stuff. A serverless framework is a third-party framework but then it's also sort of generalized for just the generic use case, whereas Amplify is very focused on that front-end framework, so it'll spin up an API gateway, which you need to expose the service function to the public.
Chris: Right.
Shawn: Stuff like that, it's just kind of distracted away for you, which is pretty similar to what Netlify does as well.
Chris: Yeah. Right. Netlify tries to help with this, too, because you just have that functions folder and it just automatically becomes these public-facing URLs, which is pretty cool, honestly. I think it's proven out and we talked to Brian from Begin. There's this whole market for, like, help me with the CICD of serverless.
Shawn: Yeah. I think one of the pain points is that there are so many equivalent ways of doing these things that it's very confusing for someone new to this space to evaluate all the different options. That's why I think that sites like your power serverless site could be really helpful in giving information for people to evaluate.
I'm obviously biased by the people that I work for but this information is important and it needs to get out there. What are the tradeoffs when you pick between different providers?
Chris: Yeah, you know, and the companies aren't particularly incentivized to help you understand the landscape truly as it is. Microsoft has lots of interesting, cool things they're doing with cloud stuff. I'm speaking at one of their little conferences in a week or two. That's great. They're a part of this world too, but none of the -- Amazon isn't particularly compelled to tell you about what AWS has going on. Microsoft isn't particularly incentivized to tell you how their stuff stacks up against AWS. Maybe once in a while, you'll see a little, like, "Let me tell you how it is," but--
Dave: An unlabeled chart.
Chris: Yeah.
Shawn: [Laughter]
Dave: It's just a vast--
Shawn: Competitor A, competitor B.
Chris: Yeah.
Shawn: There are actually strict policy when you take the media training at these companies that you cannot say anything about competitors. I think that's fair. You would not want someone who doesn't know you super well to present you in a bad light. That's unfair to what it is. Yeah. I mean that's why I think having independent, third-party experts kind of survey the field, I think that's the best we can hope for, really.
Chris: You're dead right about that. Not to change gears entirely, but just a little bit, I think of you as also kind of a react person because you've written a lot of it. You write a lot about it. You're, I believe, a mod or the mod of Reddit's React - whatever you call it.
Shawn: Yeah, our…. The front page of Reddit -- front page of React is what we call it.
Chris: Yeah, well, because it's hoppin', right? Not a lot of -- there's probably an R CodePen, too, but I've probably never even looked at it. This one is actually very bustling, isn't it?
Shawn: Yeah, you know, it's a function of whether or not the core team prioritizes it. You could make CodePen, our CodePen active if you showed up on there. [Laughter] People will go wherever they get access to people who are in the know and for whatever reason, R/ReactJS has the right amount of people.
For those who don't know my story, I changed careers three-ish, four-ish years ago. I actually started -- I got my start with Vue because I found it much easier to get started.
Chris: What did you change careers from? Was it very different? Were you a firefighter or something?
Shawn: [Laughter] I wish. That would be way more interesting. No, I was in finance, you know, the other super gender-diverse industry. [Laughter] I did investment banking and hedge funds for about six years. Essentially burned out by not being that great at the finance bit, but I learned to code as part of my job.
I think that a lot of programmers, kind of card-carrying programmers, don't appreciate that a lot of people who don't carry that title of software engineer are learning to code as part of their job. Some of them get good at it, and that was me. I was learning Python. I had to learn Haskell because I had no choice. People were very impressed that I did production Haskell for two years but I had no choice [laughter] and just powered through it.
Dave: Wow.
Shawn: Yeah. See. But I didn't know.
Chris: Yeah.
Shawn: If no one tells you it's hard, then you think that's just the way it's supposed to be.
Dave: Sorry. I don't mean to interrupt, but I was watching a Microsoft Ignite thing just the other day and they were talking about AI and building no-code AI apps inside Microsoft Office or something like that. I just was like -- and they kept using this phrase. They were like, you know, you may have to bring in a developer, but we're trying to enable casual coders, I think was the term they used. A casual coder is just stitching together an AI that then, you know-- [Laughter]
I'm just like, that's casual? Or like in your situation, it's like running production Haskell. That's like intro to Web development.
Chris: Side work. Yeah.
Dave: What's going--? This is shocking my brain because it's just like the standards of what we call things are just so out there. I like this idea that it's not just developers who are coding. Lots of people are coding as a part of their job. They may not realize how serious the level of programming is.
Shawn: Yeah.
Dave: That's very interesting to me.
Shawn: I have so many responses to that, so I'll kind of take it back to, I got started -- you know in finance everyone uses Excel and Excel is famously a programming language that's reactive and very intuitive in terms of a user interface. But then you need to automate Excel, so then you get into VBA. Then you start to run into the memory limits of Excel, so you then move off of Excel to Python. Then you need to do parallel calculations, and then you go to Haskell or--what's the other--Camel, which finance people love a lot.
Chris: That was an interesting 15 seconds of audio.
[laughter]
Shawn: No. I mean, yeah, seriously. Tens of thousands of people are doing this, at least in finance, and I think people who would consider yourselves classical programmers don't really consider the amount of onramp that is coming in. Software is eating the world and this is an interesting aspect of it.
Anyway, kind of bringing it back to my story, yeah, I turned from casual to maybe thinking that maybe I should do this for a full-time job. Essentially, I did a free code camp during nights and weekends for six straight months. "No. Zero. Days," that was the article, the blog post that I write about that.
Then I finished free code camp, did not feel qualified to look for a job because it was free. What did I know? So, I went for a boot camp and the boot camp actually did help me get a job, so it was a bet that worked out.
During that, period, I actually picked Vue because Vue was the much easier framework to get started with, at least when I was looking at it. Also, I think Evan -- I was in New York. Evan was in New York. I went to a few Vue meetups and he was there. That really helps a lot in terms of your intent to adopt things.
But then I realized I wanted a job and money. [Laughter] React was much more popular, so I went into React.
Chris: Just based on its popularity? That's interesting. Why not? That's probably what most people do.
Shawn: Yeah. People make a big deal out of, like, use the best tool for the job, but sometimes you use the best tool that gets you a job. You know? [Laughter]
Dave: [Laughter]
Chris: Yeah. Sure.
Dave: Good perspective, you know.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by FaunaDB. We've talked about JAMstack a million times on this show. It's a nice stack. We've also mentioned that part of the weirdness of it is that it's not really a stack in that it doesn't prescribe the tools that you use. It's just kind of like a philosophy.
Well, what if you need a database, still? Just because you're JAMstack doesn't mean you don't need a database. You can have a JAMstack approach but still have certain pages that then hit a cloud data storage place for that data. Where is that? What are you going to use? Use FaunaDB.
FaunaDB is a fully-featured database that just has an API to that data, so it's frictionlessly fits into your JAMstack world. You talk to it with serverless functions, and it doesn't care how you do that. Put them on Netlify. Put them on Versal. Use Cloudflare Workers, AWS Lambda, Azure functions, whatever. FaunaDB doesn't care. It gives you total freedom of your database operations.
Just like that, it doesn't care about your front-end framework either. You're building a React site, Angular site, Vue, Ember, Elm, whatever, it doesn't matter. With FaunaDB, you add the global store, get it set up in a couple of minutes, and your data then is accessible via API with GraphQL support, custom business logic, the whole deal. Serverless is like the spiritual partner of JAMstack, so serverless meaning I'm going to talk to a serverless function, have that function get and manipulate data for me and build a JAMstack site. I think it's an awesome way to work.
Thanks so much for the support, FaunaDB. Go to check this out, fauna.com/JAMstack. Get you started for free.
[Banjo music stops]
Dave: This is fascinating to me because you said you've only been a Web dev professional here for like three, four years. Is that right?
Shawn: Yes, sir.
Dave: I'm not misquoting that?
Shawn: Nope.
Dave: I mean because my situation and how I am exposed to your work most often is I search for some technology on YouTube and there's a video with you and the maintainer of the software talking about it. It seems like not only have you been a Vue professional or been into Vue and then a React professional and Reddit maintainer, but you also have a broad set of technologies that you've been exposed to. Maybe that was part of your Netlify work or something. I guess, why? Why do you know so much technology, would be my question?
Shawn: I don't. That's the straight honest answer. I actually don't have that good of a YouTube presence. As well, I must have gotten lucky with your searches.
I am interested intellectually between the different frameworks. I think they're all contributing something to the discussion. I definitely spend a lot of time, more time than probably is sane, researching these things and actually comparing and making friends with the maintainers.
I definitely view that as part of my talent set because you don't have to know everything. You just have to know the maintainers of everything and that will get you pretty far. [Laughter]
Chris: That's a nice trick.
Dave: There you go.
Chris: That's a nice trick. One I've used many times.
Shawn: [Laughter]
Dave: Oh, I do. I mean some of it is the best way to get the answer is to complain on Twitter.
Shawn: Yes. [Laughter]
Chris: Yeah.
Dave: I don't know.
Chris: We've learned that lesson on this podcast a little bit because it's like, you can email anybody? Then you're like, do you want to just sit down and talk for an hour and record it? How is Thursday in the absolute middle of a workday? The chances of getting a yes are super high, even in the early days of this show, not that we're famous or anything now, but the amount of yeses you get for a, "Let's chat," is real high.
Dave: Yeah. We had Paul Irish on once and he doesn't talk to nobody.
Chris: [Laughter] Fair enough. He liked one of my Instagrams recently and I'm like, "Ooh, a rare Paul sighting from the wild."
Shawn: The rush. I just kind of wonder what he's up to because his YouTube videos on jQuery were pretty popular back in the day.
Chris: Oh, I think he's doing a lot. It's just behind the scenes these days.
But one of the reasons I brought up React is because, does Amplify care about React? It's very much a front-end thing, as you were saying. So, it's foundationally a React thing?
Shawn: Amplify is not tied into React but, obviously, it has sort of integration libraries that you can choose to use, if you wish, with Vue, React, Flutter, iOS, and Android.
Chris: Oh!
Shawn: Yeah, it's kind of framework agnostic in that sense, but it does offer integration SDKs. Obviously, because React is so popular, React developers are the biggest consumers of Amplify. Definitely, if anything gets tested in Amplify, it is the React integrations to make sure that nothing breaks because those are its users.
Chris: You get a little bit of SDK action for it, but it's framework agnostic. That's cool. What isn't agnostic about it? I assume there's a GraphQL component to it, probably.
Shawn: Yeah, but you could choose to use Rest of GraphQL.
Chris: Okay. Okay.
Shawn: I don't think there's a--
Chris: It's not even opinionated there. What is it opinionated about?
Shawn: It's opinionated on platform.
Chris: Yeah.
Shawn: You should probably deploy it on AWS if you're picking Amplify. Really, it's very pluggable in the sense that even the off solutions, the storage solutions, they're all designed to be swappable out to any sort of underlying implementation. For example, the default auth provider of Amazon is Cognito. But let's say you don't want to use Cognito. You can use Okta or Auth0. That's the vision. Amplify is three years into this.
The reality is that the third-party ecosystem for plugins hasn't been built out yet, so it kind of really relies on the continued growth of this to become a thing, and then it'll be kind of like a self-sustaining thing where people will write plugins. But the architecture is set up so that, in the future, it will be set up like that.
In the meantime, yes, it'll be opinionated on basically saying if you want all these AWS services, it will spin it up for you. If you want to plug in a third-party, you can bring your own but your kind of more on your own there.
Chris: Mm-hmm. This seems like, if you're like, I'm going to use Cognito or some third-party auth and I'm going to use a database in the sky and I'm going to use serverless functions and stuff, that's all stuff that seems spiritually connected to JAMstack. That's like the serverless architecture way.
Shawn: Yeah.
Chris: But serverless and JAMstack are like spiritual buddies. What's the pre-render story, then? Does Amplify help with kind of the final attack in JAMstack or the original thing?
Shawn: Yeah.
Chris: Or is pre-rendering kind of, you're on your own?
Shawn: No. No, basically, the same story as Netlify, mainly because--
Chris: Yeah.
Shawn: I'm most familiar with Netlify. But there is a CICD service called Amplify Console that does the same thing. It just runs your build, whatever build process you want, including pre-rendering, and then pushes it out to CDN. For AWS, that's CloudFront. Again, everything but the AWS version of it. I think that's, yeah, a fair enough proposition.
I think what's interesting now is this contention between Vercel and what prerendering means because they do kind of stale wall revalidate serverless hosting. That's something that I don't think Amplify or Netlify supports right now but it's clearly something that is a very key value proposition of NextJS, so I think all platforms are working toward supporting that.
Chris: Yeah. They're kind of playing both sides of the aisle.
Shawn: Mm-hmm.
Chris: Which we'll see if that ends up being smart or not. I even had an ancient PHP site, just super old. The only reason I did it in PHP was just to do little include statements, right? Like, oh, include my header on these eight pages. It was for some friend of my dad who had a local repair company and he wanted to show some bathroom remodeling online. Who knows. I wrote this over a decade ago, for sure, but I was closing down old servers, like, ah, I need to get rid of this ancient thing that I pay monthly for. Get rid of that.
I was like, where can I put it? Where do you put a baby PHP site these days that isn't Bluehost or something? Nothing against Bluehost, but that's what I was trying to not do. You know?
Shawn: [Laughter]
Chris: Vercel has a thing. You can deploy a little PHP site on it and it treats the PHP a little bit like a cloud function. You can write a cloud function and cloud function doesn't mean node, necessarily. On AWS, you can write a cloud function in tons of languages--Ruby, whatever--because Vercel supports that, too. What's behind the scenes at Vercel? Is it AWS? Maybe not. Maybe they … cheaper.
Shawn: Oh, yeah, I think it is.
Chris: Is it? Okay.
Shawn: Yeah.
Dave: I think Guillermo hand-evaluates every--
Shawn: [Laughter]
Chris: Well, if you're at scale, I would think that you'd write it agnostically, right? If Microsoft came knocking at your door and they offered you some crazy deal, you'd be like, "Okay, we'll run it on your crap now." [Laughter] Why not?
Dave: Yeah.
Chris: But anyway, I moved it to Vercel, which is kind of cool, but that's just one example. They're very much in the, like, "Sure. We're JAMstack. We'll serve your stuff off CDNs and static host away, but if you need a little Node server behind it, fine. We can totally do that too." They just play both sides. They're like, "We like JAMstack and we like servers."
Shawn: I think that was old ZEIT, but ZEIT v2 and now Vercel is all done on serverless. I should also probably point out that Amplify is very much the same way. It's the bet on the serverless feature of Amazon.
Chris: Hmm.
Shawn: I think the internal adoption and the -- it's kind of like -- okay. This is not officially approved messaging, so please don't quote me on this.
Chris: Sure.
Shawn: But it's kind of like the facade pattern. Amazon is built on EC2 and a bunch of serverfull technologies. But let's establish this new brand name and all the technologies in it are sort of serverless or serverless compatible. Yeah, let's just get a bunch of developers onto this thing, and then they won't even know that they're using Amazon underneath, like if they're just using Amplify.
Chris: Hmm. That's like a longer-term play? I know this is not official messaging.
Shawn: Exactly. Yeah.
Chris: Yeah.
Shawn: But I can see it. That was my pitch, so when I joined Amazon, I kind of wrote the blog post kind of detailing how I see Amazon approaching the front-end ecosystem, so that's kind of how I pitched it and I didn't get chewed out for it, so I assume it's okay. [Laughter]
Chris: Ah, nice.
Dave: [Laughter]
Chris: On your site, you should fix this because you have a little post, "First Look at AWS Amplify Flutter," and I really want to read it, but when you click it, it 500s, so you've got a little work to do.
Shawn: Yes. I am about to actually ship my -- I've been rewriting my site.
Chris: Yay! Nice. I can tell little changes because you used to have the world's coolest like candy bar scroll bar and I see now it's this little green blob, which, [groan] where's--?
Shawn: That actually depends on your screen width, so I changed that.
Chris: Oh, I have it really small. Oh, you're right. Oh, my gosh. What a rookie mistake.
Shawn: Obviously, I took that -- I took that from CSS-Tricks.
Chris: [Laughter]
Shawn: I didn't like the look of it for small windows, so I changed it to the green bar for mobile view.
Chris: Mm-hmm. I get an email once a week, maybe, that somebody is saying, "Ack, the fact that you override scrolling behavior with JavaScript leads to extreme jank as you're scrolling down the page," kind of thing. I'm like, "Guess what."
Shawn: What?
Chris: I didn't do that. It's just CSS, bro. It's all good.
Shawn: [Laughter]
Chris: You liar!
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you by Framer. That's framer.com/shoptalk. Go there. Sign up for free or get 20% off any paid plan. That's very generous. Thank you, Framer.
When you've spent hours designing something beautiful for the Web, the last thing you want to hear is, "Uh, sorry. Uh, we can't build this." You know? Ew. Ew.
What you need is a tool that bridges the gap between design and development. Framer can be that bridge. It's a browser-based prototyping tool that enables designers to use code-backed components and dynamic transitions to visually express ideas. When the time comes that you, perhaps, as the designer, are giving it to a developer, the developer can jump in and easily inspect the elements get the CSS or the JSX right from there. Custom animations custom-built with Magic Motion. It's powered by Framer Motion, which is an open-source library that's awesome, that you should check out, for React.
It all comes with a complete, clean code, which can be taken right from Framer and you can move it right into production. It's the gap. Framer is the bridge. Sign up for free or get 20% off any paid plan by visiting framer.com/shoptalk. That's framer.com/shoptalk.
[Banjo music stops]
Chris: Okay, so you were in finance. The first -- Quincy Larson spills the beans in the intro to the book that says you left a career that was pretty deep into the six figures to come do this, so I hope that was worth it. [Laughter] I mean I know it is because it involves your brain and your life, so money isn't everything, of course. But that's pretty wild. Then came over here to coding land and then were at Netlify for a while, which, wow, a lot of people's dream job there. I'm sure that was kind of a cool moment for you. Now are at Amazon, which is probably even more people's dream job. Wow! Good job.
You were in finance. Money is on the brain at least a little bit. You probably can't avoid it these days. Are a bit entrepreneurial in the things that you do. An example of that is this book, right? You talk about yourself in that transition. The book is called Coding Career. Yeah?
Shawn: Yeah. The Coding Career Handbook.
Chris: Handbook.
Shawn: It was originally called Cracking the Coding Career, to kind of draft off Cracking the Coding Interview, and then Gayle McDowell, the author, got in touch with me and mentioned the word lawyers, so then I had to change it.
Chris: [Loud gasp]
Shawn: [Laughter]
Dave: Hey--
Chris: By having a book title that's a little bit similar to something else? Hot take. What a dick move.
Shawn: No. Actually, it was reasonable, so I'll defend her.
Chris: Okay.
Shawn: You can't trademark a book title, so you could actually publish a book titled, I don't know, Great Gatsby and not be sued. You can publish the exact same title as someone else.
Chris: Okay.
Shawn: That's fine, but if an author has published a series of books with all the same patterns and a new book that comes out could be reasonably mistaken to be part of that series when it's not or affiliated with that series and it's not, then that's a trademark.
Chris: Okay. Okay, okay, okay.
Dave: Harry Potter and the Dave Rupert Code School--
Shawn: [Laughter]
Dave: --that's illegal. I understand.
Shawn: Well, you'd be fighting with J.K. Rowling, but this is--
Chris: Amplify for Dummies is probably not going to fly either? Yeah.
Shawn: I think that might work. Again, not an official statement.
Chris: Yeah.
Shawn: I didn't know any of this when I was just shipping a book. The backstory with this was, I had two months in between leaving Netlify and joining Amazon. I was like, what am I going to do with these two months? Originally, I was going to goof off on my Nintendo Switch. That got old after a week, so I was like, all right. Let's ship a side project and try to make some money.
I think my writing has been very eclectic. I do a lot of nontechnical and technical writing. For better or worse, the nontechnical stuff is the one that gets a lot more attention, and so I decided to turn that into a book.
Essentially, a quarter of the book is kind of revamped blog posts and then three quarters is new. Essentially, I kind of wrote down everything I knew about what makes sense in a career. Obviously, I haven't had that long of a development career, of a dev career, but I have had, I guess, a decent success in two careers so far. But I've also absorbed a lot of wisdom from other people, including both of you.
I think both of you are quoted in the book. Chris, you're quoted for "Build in Public," which is one of your old blog posts about building CodePen. Then, Dave, I quoted you about your surfing analogy, I think, which is very recent. It actually came in a day before I launched. I heard it on this show and I was like, oh, I need to put that in there.
Chris: Hmm.
Dave: Oh, great. Well, I should say, too, I was like, "Oh, Shawn wrote a book in his unemployment. Let me check this out." [Laughter] Low and behold, dear listener, it's like a 500-page book with like, is it, 4 well-organized sections. You don't have to read it all in one sitting, but each section is very intelligently grouped.
Chris: It really is 500 pages.
Dave: You did a smashing job. I just was like, "How far could somebody get in a book in their off time?" You knocked it out of the park, so great job.
Shawn: I appreciate that. That's huge.
Chris: How's it going? Is it working? Are you selling it? Are you making money? Come on.
Shawn: I'm selling it. I think I broke $50,000 last week.
Chris: Oh! What?!
Shawn: That's a decent side project money for two months. Yeah, it wasn't off time. I was unemployed and I wrote this every day for 12 hours a day for, I think, a total of 600 hours is what I counted.
Chris: That's….
Dave: Oh, wow.
Shawn: I think, beyond that, the thinking that went into it and the notetaking, which I stress about it a lot. You can't just sit down and write a book. You should gather some point of view or gather a lot of resource. I link to 1,400 external resources, partially to compensate for my own imposter syndrome, but also cite and attribute ideas that are not mine to the people that came up with them.
You can't just come up with that sitting down. I call this "mise en place" writing. You gather the things that you're going to refer to in a good notetaking system so that when you sit down to write, you have everything in front of you.
Chris: Mm-hmm. Mm-hmm. Well, that's great advice. I totally agree with all aspects of that. As much as it's glamorized that you may rent a hotel room in the forest or whatever or a cabin and just have a blank piece of paper and a typewriter and you just starting typewriting, it's really more like you have 55 tabs open and weird notetaking apps because you couldn't decide on just one, and your document is a big disaster. Yeah. More accurate.
Shawn: I think there's a process towards developing your thoughts as well. It's kind of like developing that startup mentality. Have a small MVP of a thought and then you flesh it out more and you flesh it out more.
I think that's where Twitter really comes in handy because you can put out something small. That's all you're allowed to do. You can get instant feedback on it. Then you can develop it further. A lot of things start out sort of being tested on Twitter.
I think that's also where -- I think one of my most popular talks is the talk on React hooks that I did at JSConf Asia. That started as a tweet. Dan Abramov helped me shape it and that became a blog post. Then the blog post became a talk. The talk was very well received, but people don't know the six months of work before that that brought that talk into being.
Chris: Sure.
Shawn: It's very much similar to achieving any sort of substantial piece of work. You start small and then you go big.
Chris: [Laughter] You still like hooks? You still in on hooks?
Shawn: I like hooks. Yeah, I think they're -- they make -- it's surprising how bad they make classes look for you.
Chris: [Laughter]
Shawn: Before hooks, you're like, oh, this is how things are done in React and I'm getting paid money to do this. I'll overcome any obstacle [laughter] to learn this stuff. Then hooks came alone and really simplified a lot of that code.
Chris: Yeah. Yeah. Now we're in a weird place with them where they've been out long enough that….
Shawn: Now it's cool to hate them. Yeah. [Laughter]
Chris: Yeah, for some ... don't even know….
Shawn: …people hate on them.
Chris: You just almost hear nothing at all about them. It's just like not a topic anymore.
Shawn: Yeah. I think they're a fact of life. They're just such a good idea that Vue 3 just came out last week and their composition API is pretty much entirely influenced by hooks. In some sense, it's actually better and Svelte also did a major rewrite also influenced by hooks. These ideas just keep coming from React and you've got to really give credit to them for always being innovators.
Chris: Yeah.
Shawn: The stuff that's coming down the pike has taken longer. The wait for React suspense has been very frustrating, but they really want to deliver a more comprehensive solution and it's very much reflective of React itself changing from a library towards more of a full-stack framework, so feature versus React will involve more intense parts of server-side rendering than they have before.
Chris: Mm-hmm. Mm-hmm. Yeah, that's interesting.
Dave: Well, and I've seen, too, just a few announcements. You know, I think React was kind of like, "We're not making any breaking changes," but then there have been a few things they kind of fudge on. As bad as that is, if you're stuck on React whatever, I think that's a sign of progress is happening. They're having to make hard decisions.
Shawn: Yep. Yep. I think something that is becoming more evident now is that React is very much built for Facebook needs. It turns out that a lot of companies are not Facebook. Yeah, I used to think that the frameworks game was over and it was all done on React. Recently, I've been diversifying more.
I think all of these -- this is a mix of technical and non-technical, but I kind of view these as the same bucket, in my mind. A full quarter of the book is about strategy, and I kind of bring my finance background into that discussion. Both of you saw my post on the Third Age of JavaScript. I definitely view where we are in this point in history as just one point in a broader story. I try to think about where that is taking us to. Yeah, so I think that there is something bigger going on and I think that we should always keep a lookout as to what we're investing in and is the investment thesis for that changing. Definitely try to by hyperaware of that.
Chris: What do you think is going to happen with SSR, long-term? Is React going to be like, "Here's our official word on it. This is how you should do it," or is it going to be like, "You should use Next because they kind of have a lock on it"? [Laughter]
Shawn: Exactly. I was actually telling Tim; I think the first time I met Tim … (indiscernible). I was like, either ZEIT should acquire React or React should acquire ZEIT and just make this thing, make this one thing, because the endorsement at this stage is very, very strong. Google Chrome is contributing equally to NextJS.
Chris: Hmm.
Shawn: To the exclusion of other React metaframeworks, which is neither here nor there, right? It's not really super fair to the other metaframeworks but then, at the same time, NextJS is the biggest one and has the biggest investment, so I can see how that plays on both sides.
Yeah, for where we are now, structurally, in the organizational spectrum, SSR seems to be separate from React because React -- well, because Facebook has a completely different architecture that's based on their own assumptions.
Chris: Yeah. That's what I mean. What about the rest of us that didn't go down the Next path a whole bunch of years ago but totally did go down the React path years ago? Have a very modern React app. We're on the latest version. We're using the latest stuff. We're using the latest Apollo. It's like a really nice React app, but now it's time to be like, "Oh, crap. You can't ignore SSR any longer." Where do you turn?
Shawn: I think it'll be NextJS. I think that's the way that we have it now is a good, happy medium. It's not fully integrated like some other frameworks might be, but you have to remember that React also supports React native. In fact, the React native team is twice as big, maybe more, the size of the React core team. Yeah, that's no point in doing SSR for a reactive, right?
Yeah. To be honest, I think if you want a good Web solution, probably the other frameworks are better to start with. Then if you need something cross-platform, you go with React. That's where I'm at now, which is kind of a hottish take.
Chris: [Laughter]
Shawn: I have a post sitting in my drafts basically laying out my reasons why I say that people should use Svelte for sites and React for apps. I think that's the division that I've kind of landed on.
Chris: Hmm. Hot take, indeed.
Shawn: [Laughter]
Chris: Tweet it. Tweet it. Okay, well, should we--? Dave, do you have any thoughts on this before I throw a gear shift?
Dave: No, I mean I guess this "Third Age of JavaScript" post you mention, it's a thinker, right? It's kind of like we're kind of haphazard a decade ago and then we've started having some kind of mature componentization. But then your third age, maybe I can describe it and you can tell me what's wrong. It's like we kind of now have modules, officially, and so that kind of opens up sort of new territory for performance and things like that.
Chris: Mm-hmm.
Dave: When do you think the third age happens or when we do enter nirvana here--
Shawn: [Laughter]
Dave: --for JavaScript--I don't know--the third age?
Shawn: [Laughter] I always feel a bit of imposter syndrome around this because I obviously wasn't around for the second age. I wasn't around for that major transition into jQuery and then out.
You have to remember, I came in and Vue was the new hotness, and so I'm reconstructing. I probably spent a lot more time diving through historical accounts than most people that I know. I kind of reconstructed a best effort, but I'm definitely interested in both of your thoughts on this.
I think it's happening right now. I think what Fred Schott is doing with Pika Package or Snowpack or whatever he calls it these days--
Chris: Yes!
Shawn: Everyone is adopting this sort of ES modules … approach.
Chris: Yes!
Shawn: ESM is unflagged in NodeJS. IE, Internet Explorer, is slowly dying. I have another post on the timeframe, but the first window for IE support to die is actually in October, next month. But it stretches out for the next seven years, so it's not as exciting. [Laughter] But, yeah, as all those old assumptions go away, and I think that that gives us a lot of basis for new approaches to come up.
You're also starting to see deprecations of second age frameworks like MomentJS, which just happened as of the time of recording. I think we start to see this.
Dave: Mm-hmm.
Shawn: We start to see deprecations of old tech or old tech in maintenance mode, not so much -- they're still predicated on previous assumptions that you can't really rewrite everything. Then you see new tech rising up without those assumptions. One of the other projects that I really, really recommend everyone listening to check out is Vite from the Vue ecosystem. Vite and Snowpack both have this idea of sort of the dev server can take advantage of the ES modules to not compile the entire app, so it has very, very fast reloading. For them, they kind of market it as constant time reloading because you don't have to recompile every file every time you change -- refile the app every time you change a single file to refresh what you're developing. That's interesting.
Dave: No, I just used Vite because I've got a little side project and it was like, okay, I have to rewrite it. I was like, I might as well just use Vue 3 and Vite just to try it out, and I was impressed.
Any time you're doing a side project, the first--whatever--few days, it's really just fighting build tools, it feels like. You know? You're like, "Okay, I wanted Sass, but now I'm stuck," or whatever.
Shawn: The tangled Web.
Dave: But Vite is very, like--
Chris: How do you Google it?
Dave: Yes, it's a tangled Web.
Chris: What is it? Is it V-E-E-T or what?
Shawn: V-I-T-E.
Dave: V-I-T-E.
Shawn: Yeah.
Dave: I think it's just Evan's Vue, whatever.
Chris: Here it is.
Dave: Whatever his--
Chris: I got it. I got it.
Dave: But yeah, I didn't think I needed it or wanted it or anything, but it just sort of took the pain out of using a command-line JavaScript server that would do modules. I guess the browser is doing the modules, but it sort of does the hot reloading and things like that. I didn't realize -- and it's very fast, but it just took out some of the pain. I don't think I had identified it as pain, but it was just like, "Oh, this is just working and very low effort to get it working." I was impressed. That's all. I have very limited exposure, but I just was impressed based on whatever big Webpack configs or even setting up Parcel by yourself. It was a lot easier than I had kind of maybe expected.
Chris: I'm really hoping that the longer we wait, the more cool it is that we didn't ever get around to shipping an NPM feature at CodePen yet, despite really trying to get that out the door.
Shawn: [Laughter]
Chris: Because eventually, you'll just be able to hit some cool CDN directly and import the module directly and it will just be fine.
Dave: Well, and browsers--
Shawn: That's the Dano dream, for sure.
Chris: Yeah.
Dave: Yeah, that's what's Dano is doing, but then even browsers. I've heard conversations where they're kicking up the, like, "What if Node modules were in the browser?" sort of thing. [Laughter] You know?
Chris: Mm-hmm.
Dave: I'm like, boy, if we're doing that again, let's see, but I'd be curious what happens there.
Shawn: Yeah.
Chris: I would think the third age of JavaScript has some cloud stuff in it too, or has some Edge stuff in it, like the idea that all these servers that there's infrastructure all over the world of them can also run JavaScript. It's going to start being taken advantage of more and more. Pretty bullish on that.
Shawn: I would caution. I would caution. [Laughter] I'm about to contradict you. I'd caution people against getting too excited about Edge servers, Edge functions.
Chris: Yeah? Okay.
Shawn: Whatever you call it. Mainly because if you use them as real servers, then you really have a pretty complicated distributed system problem, whereas they're actually more designed for redirects and small rewrites like based on your language or your location will shift you to the right language version for you or whatever or inject some JavaScript at the Edge. That kind of stuff, much smaller than I think people are imagining things for, and you're still going to have to need to have some sort of "origin" to serve from your primary logic.
Chris: Well, that seems fair.
Shawn: It's exciting but, I think, try not to do too much with it because it's not designed for that. [Laughter]
Chris: Yeah. Yeah, it doesn't replace your origin. Okay. Okay, so let's do the DevEx thing because that's been a part of this world too and we haven't even said it yet. Developer experience, I mean, shortened to DevEx sometimes. Is it a job? Is it a thing? Is it a thing that companies think about? What the hell is it?
Shawn: Yeah. It's basically customer experience when your customer is a developer, right? I think that's my framing of these things and why it's more of a trending term. My last title at Netlify was Developer Experience Engineer. Nobody knows what that means. [Laughter]
I think I was very inspired by your post on CSS-Tricks marking out, like, what do people think when they think about the world of experience? I think there are a lot of valid viewpoints there. It's exactly as well defined as what customer experience is. It's everything.
It's a very difficult and vague job to pin down, but I think perhaps what you're going to talk about is, is this becoming an industry? I think it is, basically, because developer tooling companies and developer platforms are just growing and growing. It shows. It's basically been shown that the best way to get developers is to get their attention, write demos, and then make sure they're happy once they join and successful.
I definitely see this growing. I definitely see conferences and thought leaders and gatekeepers and stuff like that. I think my most recent sort of obsession has been a lot of developer applicants -- so there used to be an era of Google having developer evangelists kind of go and yell at you from the rooftops. Then the vibe changed about five years ago to where it's more developer advocates where it's kind of like a two-way street. Then developer experience engineering has been much more sort of being more on the product team of a sort of shadow marketing team and contributing towards the design and shipping of actual products.
But all these sort of activities have been very much focused on the happy path, like, look how easy it is to get started. Look at our great docs. Look at all these IDE integrations. These are all great things, but I think that we often leave developers alone with the unhappy path.
The way I phrase this is that, with developer advocates, there is a lot of try but maybe we should focus more on catch. We should catch people where we have errors, where we have deprecations, where we have missing features, stuff like that, stuff that's not so nice to talk about but people actually lose a lot of hair on when they encounter any developer tooling.
Chris: Is there--I don't know--a rollercoaster of that? You wouldn't sit down and be like, to build a new company or a new product and think about the problems first, right? You have to build a thing. Then you have people use the thing. Then you can--I don't know--start thinking about what it's like to fail at using it.
Shawn: Yeah. Yeah, you're a builder. You know how these things go. I think a lot of people are not comfortable with -- a lot of people who work in Devrow, don't really talk about that, right? I guess it's not polite conversation. But I think that developers are at a point where it's more authentic and people trust you more if you're also upfront with your flaws and what you're missing on.
I'm hoping to move the industry. Whatever minor clout I have. I only move the industry in that direction because I see a lot of people, you know, only doing happy stuff.
Chris: Yeah.
Shawn: Sometimes, you've got to do a real talk. You know?
Chris: I wonder what you'll uncover there as your journey is going on. I like that you're already thinking about politeness and that maybe if we're just avoiding it because of politeness, that's certainly a fail. That's not a good reason to leave a developer screwed because your company is too afraid to talk about what it's like to fail using your product, kind of thing.
But it's tricky because it's tied into marketing and stuff. If your product has a big, public-facing page about what it can't do, what does that do to the business of your company? Maybe there's some evidence that that's bad for business.
Shawn: I think it means that it forces you to be secure about the value proposition that you do bring and being confident enough that, "Yeah, that's actually -- we are the best in the world at this thing. Yes, we have a lot of other flaws, but when you come join us or when you use us, we are the best in the world at this one thing."
Chris: That's great.
Shawn: "We're working on everything else and we know them, we publicly acknowledge them. Hold us accountable." I think that's much better than--I don't know--sending a support ticket and maybe someone will get back to you some time never.
Chris: [Laughter]
Shawn: And so, you know, obviously, I feel strongly about this. I think the problem is not marketing. I think the problem is product because it really, really -- I think this is -- I kind of phrase this in my blog post as Conway's law. Conway's law is where the product that you ship is a reflection of your organizational structure. The people that own the products--and there's a title for these as product managers, product engineers--they have a strong say in this too. Who owns this, the experience of developers, and how do you interface with the roadmaps of different competing priorities? Right?
I think that's where the real conflict lies because there's no clear ownership and what I got from recently Andreessen Horowitz put out a blog post that kind of -- put out a podcast that talks about this. Amir Shevat, I think he used to run developer relations at Twitch and then Microsoft, then Google. He says that we basically have to organize weekly … between product and developer experience. I think that's the right way to go because, yeah, developer experience, you're kind of like the representative voice of developers but you also don't have the resources to do everything yourself.
Dave: No, that's a great way to put it. Recently, in the last couple of weeks or months, I've been evaluating a lot of different GraphQL kind of--whatever--Sass things. You know, just like, I want a server but I also want a way to configure it. I want the database and then I want the GraphQL endpoint.
I didn't realize it until I had done three or four. I was like, oh, these kind of all solve different ends of the problem. One, I think, does the -- it's almost like configuring a database or like PHP admin and it's kind of like, "Okay, bring your own authentication. I don't know. We don't care."
Then every tool does it sort of differently. I try to evaluate all these things and then even I complained on Twitter. One of their developer advocates reached out to me. They're like, "What didn't you like about our thing?"
I told them very straight, like, "Here is what I expected and I got this," or I expected a GraphQL schema and it didn't have it. It was like, "Build your own. Good luck."
They were like, "Oh, yeah. We've heard that feedback before." It was cool that they were very honest that they had heard that feedback before, but it also didn't help me, so.
Shawn: Yeah.
Chris: Okay. How would you improve that, Shawn? What would you do if you were in charge of that situation?
Shawn: Look. I don't want to make it about any particular company, so Dave should not have had to tweet to find that out. It should be documented clearly that this is a common thing that people want, people need, and we don't provide. Here are a few different options.
Just provide a nice offramp onto other services for things that are very commonly held feedback. That developer advocate, I don't know who it was, but when they hear that, "Yeah, we get that feedback a lot," and then they did nothing because it was an uncomfortable conversation, I think that's one the kind of attitude that I'm hoping to change. Let's actually help people. Even though it's sort of telling people, like, here's a hole in our product and the overall experience, everyone using us runs into this. Let's document it.
Chris: Hmm.
Shawn: Yeah. I recently had a win on this because I think I shipped, to the Amazon docs for the first time, a list of things we don't -- a list of features we don't have, and the open GitHub issues where people are actively discussing all of these.
Chris: Nice.
Shawn: It's right there in the docs so that you don't have to dig around or actually play with the tool before you run into these things, because it's expensive to evaluate tools. You have to go play with these things, run into the holes, then you go on Google and dig up GitHub issues. What if they just all were in the docs because we're honest about what all the developers who actually use us face? I think that's how you sort of treat your developers seriously like that.
Chris: Well, it sounds like you made one doc for this. I'm curious about that, too. It could be kind of a cool phenomenon for companies to do, like, maybe every company should have a "What we don't do yet" page.
Shawn: Yep.
Chris: That just is a big list or something of the things that is an admission that you don't do. The alternative being sprinkling that information onto the docs pages that are relevant to that feature or whatever which, either way, probably is better than nothing. But I kind of like the idea of a single page that has all these admissions on it.
Shawn: Yeah, well, it depends on the size of your platform. The Amplify page would be very, very long, so I think sprinkling would make more sense. But yeah, you could also stick this in the UI. You know it's one of those. It's uncomfortable but it actually saves a lot of developer energy, but it also, I guess, builds trust because when people use you, they know exactly what you do and don't do and they've picked you for that tool instead of assuming things that you have that you end up not having when people actually try you out.
I almost put it as a responsibility of the platform provider because you know a lot more about this problem with the domain from having dealt with so many developers that you should educate the people on these are the things that people need. Here are the mitigation factors or here are just things that we plain don't have. If you don't have this, please use other things.
I think that's something that open-source libraries are also pretty keen on as well. Redux has a thing on why you should not use Redux. I think that reflects a certain level of maturity.
I have another blog post on documentation levels. Your documentation should kind of match the level of maturity of your project. Certainly, for any developer tooling platform that hopes to be used in production by other companies, you should be at a level of maturity that you can admit when you should not be used and also document your holes.
Dave: Yeah, because if you let your problems be self-discovered, I mean you're, I guess, delaying--
Shawn: The inevitable.
Dave: Delaying bad blood, right?
Shawn: They're going to find out. They're going to find out.
Dave: Yeah.
Shawn: And they're going to find out from the worst representatives, like people who are already disgruntled. Yeah, I don't know. I don't like it when people kick me to the community forum and then I find out this super important thing that's hidden like five comments down. Just tell me. I'll deal with it.
Chris: Yeah. Yeah. Yeah.
Shawn: I know nobody is perfect. I get it. It's fine. Just admit it. [Laughter]
Chris: I'd put stuff in the CodePen one that would say, like, "We support post CSS but we don't support every single plugin in the entire world for post CSS. We support this limited subset of them and this is how you use them and this is how you request another one if you really need to use another one. And here's a weird hack that does allow you to use them." Little stuff like that, right? Which I don't think is in our documentation now. I think you'd have to kind of discover that on your own, just as an example.
Shawn: I don't want to give the impression that documentation is where you dump everything. Certainly, the best documentation is the documentation that you don't have to read, and that involves careful product design and either in the CLI or the UI where you pop off information or just add in prompts and logs and warnings where appropriate.
Chris: Mm-hmm.
Shawn: I think that's better than having one place that, "Oh, you didn't read the docs? Too bad." I think that's also a pretty poor attitude to take to developers because there are too many docs to read. Nobody has got time for that. [Laughter]
Chris: All right. I think we've kind of rounded out the hour here.
Dave: Yeah, we're borrowing money from Bezos here. [Laughter] Shawn, thank you so much for coming on the show. For people who aren't following you and giving you money, how can they do that?
Shawn: You can find me on swyx.io. That's my site, which I will be shipping a new version of. You can also find the book that I wrote at learninpublic.org. Yes, .org. I hope to make that into a nonprofit soon. I'm going to give a discount to listeners. I put a coupon, SHOPTALK30, so I'll just paste that link in our Zoom chat.
Dave: Hey! There you go. Free money. Thank you very much. Thanks for all you do. You really contribute a lot to community and just developer experience as a whole, so thanks for sharing your thoughts.
Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.
And if you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you.
Chris, do you have anything else you'd like to say?
Chris: ShopTalkShow.com.