409: Stripe & Streaming with Suz Hinton
Suz Hinton stops by to talk about what it's like to work at Stripe, how businesses should consider storing billing data, her live stream coding journey, and building and coding digital devices like the Arduino.
Guests
Time Jump Links
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another Corona episode of the ShopTalk Show. I'm Dave--still in my house with still the same kids--Rupert and with me is Chris--comfortable in that solitary booth--Coyier.
[Laughter]
Chris Coyier: Yeah.
Dave: How are you?
Chris: Yeah, same old another week in our places. Yeah, I'm doing okay. We've got a special guest this week, another kind of crossover show because it's one of my favorite podcasts. I know you listen to it too, Dave, JS Party. We have Suz Hinton on. Hey, Suz.
Suz Hinton: Hey. Thank you so much for having me. I'm actually like, again, a fellow podcast host/panelist. I've been a fan of ShopTalk for a really long time, so this is actually really fun to actually kind of collide like this.
Dave: Yeah.
Suz: Yeah. It's funny because I'm actually recording JS Party immediately after this, so it's a double podcast.
Chris: Are you really?
Suz: Yeah.
Chris: That's awesome. A true crossover episode. Yeah, it's a great show. Everybody should listen to that too. It's actually literally my favorite tech podcast obviously that's not our own because that's disqualified immediately. I like the different formats and all that stuff. Really good. Suz, you're at Stripe right now, right? It's not super new but a little new.
Suz: Yeah, I've been there just over six months now, so that kind of awkward phase where you go from not understanding what the heck is going on at the company to, oh, I think I understand the company now. It's that nice sweet spot that I've hit finally.
Chris: Nice.
Dave: Nice.
Chris: it seems, from the outside -- I mean we know a couple of people at Stripe, but I largely don't know anything about the internals of Stripe. It feels very admirable company like beautiful design, APIs the developers just love. I don't know. I don't know anybody that is like, "Stripe, gross."
Suz: [Laughter]
Chris: [Laughter] Is that what inspired you to go there? Does it feel like that on the inside too?
Suz: Yeah, absolutely. I was working as a developer at Kickstarter years ago and I was kind of responsible for that sort of weird bit where you click on a reward if you want to back a project and you want a reward to go along with it. You're sort of picking things. Then that obviously turns into--
Chris: Oh, so kind of a big deal.
[Laughter]
Suz: What I meant was that, eventually, you get to checkout. I did some work to do with that too, right. It's sort of like the glue in between.
Chris: Okay.
Suz: That campaign page and the actual checkout. If I went on a run or went on a call, sometimes we just had weird payment things that literally nothing to do with Stripe. It was the way that we were coding our checkout. And so, I had to go and read the docs and familiarize myself with the API.
I was reading the docs and I was like, "What is this lovely place that I'm in right now?" I think that the biggest thing that just blew my mind was that when I was reading the documentation, they put your test API key embedded in the code samples.
Dave: Oh, wow.
Suz: You can literally just copy/paste.
Chris: Oh, my gosh. Yeah.
Suz: The stuff that you're trying out works. That, to me, was the single moment where I was like, "I will never be good enough to work at a place like Stripe but it would be so good to work at a place where they think about the little details like this." That was sort of my moment and I think that was 2015, 2016. Then I started the job six months ago, so you really never know what the future holds. I feel very fortunate.
Chris: Isn't that incredible when something happens in your life and you think back. It was like, "Gosh, it wasn't so long ago where that felt so insanely out of reach." [Laughter]
Suz: It's so true. That's exactly how it felt.
Chris: Mm-hmm. Yeah, I love that little touch, though. Looking at docs and seeing API code that is ready to go for you, not just for generic, replace your API key, replace things that are relevant to your account. That's a real cool dogfooding stuff. I think, like, what if it executed it too and you could see the results? Maybe it does that too. I don't know.
Incredible. Very cool. Sounds like you're liking the job at Stripe. The job is DX, they call it or you call it. Who calls it that? Is that a thing?
Suz: It's a little complicated internally, actually, because we have this organization called Developers, which means developer audience. Does that make sense?
Chris: Yeah.
Suz: Stripe has a bunch of products. They also have the dashboard. You can actually administer a lot of stuff without being a coder these days, whereas Stripe originally started just for developers and coding. There's an organization called Developers.
There's a different set of smaller umbrellas in there. I'm in the developer advocacy section and that has crossover with everything from developer experience products, which is specific tools that are adjacent to our Stripe APIs. There's a team that works on those, so that's the SDKs, the documentation, and we have tech writers and all sorts of other people underneath the Developers' umbrella too.
I'm in developer advocacy but that boundary is quite fluffy. We sort of have a lot of overlapping teamwork with these other teams outside of it under the same big organization.
Chris: Right. Right. What would be a key win for you in this role? Do you know what I mean? Should we take this opportunity here on this podcast to tell somebody about something cool that Stripe does that they should know about?
Suz: My job has me writing almost a different programming language every week.
Chris: Wow.
Suz: I think that that's a really good description of how varied the work is. I spent all of January writing Go and then, just recently, I've gone back to writing JavaScript and TypeScript again. Some of the things that developer advocacy does specifically at Stripe is, we work on our engineering blog as well as just writing other blog posts out in other ecosystems such as dev.to and other places. We help run our conference every single year, so we're providing a lot of the really cool demos that showcase new products for Stripe.
We also just do API reviews. I actually prefer most of the internal facing work rather than the external-facing work of advocacy at Stripe. One of my favorite things to do is attend API reviews where they're basically Al-Anon meetings where somebody is introducing a new feature of an API or a big breaking change or something like that. We all have our input and talk about some scenarios that people might not have thought of that we'll have to solve before releasing it and things like that.
An example of that is, there was a specific thing around type support in an SDK. I very strongly disagreed with them shipping a certain thing. I just felt it wasn't ergonomic, and so I was able to negotiate and then we actually unshipped that small portion of it.
Again, it's not supposed to be sparring or defensive or anything like that. It's just out first principles thinking of how does this feel for the user and is it important to us more than the user's experience to have this specific thing. That was a negotiation that happened and I felt like that was a really big win.
Chris: Hmm.
Suz: One of my favorite things is just building those relationships internally in order for us to advocate for developers because we tend to talk to them on a regular basis a lot more than product teams get an opportunity to. It helps us work with user research to sort of like carry, I guess, the message back to the product teams, you know.
Chris: Mm-hmm. Mm-hmm. Does it help? Does it help when you're new sometimes where you haven't been looking at the same code for so long that you could see APIs that are like, "Whoa! What is that weirdness?"
Suz: [Laughter] This actually was one of my favorite sort of months that I worked at Stripe, which was my first month, because especially if you're starting in the Developers org, they encourage you to do a bunch of what we call friction logs where you go through and you try to implement a bunch of products. Then you just write detailed notes. It's literally a play-by-play.
It's just kind of word vomit and then you clean it up. But you just write, "Oh, I wanted to do this, so I Googled this. Then I ended up with this link. Then I copy/pasted this code and then I ran into this error. Then here is how I thought about how to solve the error." You just keep going through and then you end up calling out specific things that you think should be fixed. Sometimes you can just go through and pull request yourself if you want. I really enjoyed that experience.
A few things that I did when I went through friction logs was, I ended up shipping an example up in a docker container because it took me far too long to set up a custom Ruby environment just to run the sample app, for example, as well as just making some changes to other sample apps, as well as some documentation changes too. When you're new and you feel that you're actually having an impact on the development experience immediately, that is such a nice feeling. Stripe gets so excited when new developers start who haven't had a ton of experience with Stripe, like I hadn't touched it since 2015, 2016, so it was very, very cool for me to kind of see how the APIs had changed, for example.
Chris: Wow. Friction log is my favorite new thing I'd ever heard in my life.
Suz: [Laughter]
Dave: Yeah. I'm going to be a friction log consultant.
Suz: [Laughter]
Chris: You could be!
Dave: That's what I want to do.
Suz: It's really fun. It's kind of like penetration testing but it's for like the developer experience, right?
Dave: For docs. Yeah!
Suz: You get to write up a report. Yeah, it's super fun.
Chris: It's about what's happening in your mind, you know. Like, "Eh!"
Dave: Yeah.
Chris: Logging those little moments of frustration are literally friction, I suppose.
Suz: Mm-hmm.
Dave: I sent out a dumb tweet the other day. I was like, "Pay me $10,000 and I will use your docs on Zoom with you."
[Laughter]
Dave: I don't know if that's an hour or what, but let's just pretend it's $10,000 an hour just because. But, like, I think that's a really valuable service because if you're--whatever--a big developer service. I'm thinking like hosting company, Netlify, Azure, or whoever. Your developers are getting frustrated. They will be frustrated with your product eternally. Now you're building bad blood and community disrespect and all this stuff. Make it, break it based on the goodwill of your API almost, right? I'll charge -- yeah. Let me charge. I'll charge you money just to use your docs for you and I'm a pretty good developer but, man, there are times where you just run into things. You're like, "I don't get it. I have to install a Hugo app?"
[Laughter]
Dave: "Or a Go app to get this running? I don't understand." Yeah. Or my favorite new one is where it's like, "Yadda-yadda-yadda. Watch this four-hour live stream." You're like, "Ew!"
Chris: Ew. Yeah.
Dave: I just don't have the time, buddy.
Chris: Check out our webinars.
Dave: Yeah.
Chris: It's like, if you tell me that, they better be good.
Suz: [Laughter]
Dave: Well, it's Tuesday at 7:00 p.m. your time, you know. Oh, great, great, great.
Suz: It's funny you mention that because I will admit that I get a little bit of free user research out of, like, sometimes I'll be going through my Twitter feed in the morning and someone announces they're going to do a Twitch stream and they're going to integrate Stripe into their website. I'm like [loud gasp], "Yes!"
Chris: Nice.
Suz: I get really excited and I tell everyone at work. If you do that on Twitter in the morning, I'm going to put it in the dev advocacy channel at work because we're all going to watch. We will just completely like ghost and look in the background and not help them because we'll just be making furious notes about, like, what did they get stuck on and did they make any mistakes?
Dave: Man.
Suz: Are they aware that they made mistakes? Do they have confidence in the integration at the end? Things like that.
Chris: Hmm.
Suz: That is a little bit of free research that I get sometimes, which is very helpful.
Chris: Incredible. Yeah.
Dave: That's like gorilla research. Usually, you have to pay for that. You have to give somebody a Starbucks card or something.
Chris: Yeah. Yeah.
Suz: Well, we give people shoutouts in our newsletter, so we'll say, "Hey, you know, blah-blah, you know, Mr. Jones implemented Stripe and showed subscriptions and they did a really great job, so we would recommend their approach." Then we will call them out in the newsletter and thank them.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Jetpack. Jetpack is a plugin for your self-hosted WordPress site. I have a bunch of self-hosted WordPress sites, sites like CSS-Tricks. I think it's probably the most important plugin that I run.
It's not a plugin that just does one little thing. Jetpack is like this huge feature set and each one of those features is super useful. Huge things like it backs up the site. You can back it up in real-time - incredible.
It'll warn you when your site goes down. It'll block spam from your comments, which is incredible. CSS-Tricks probably gets ten times more spam comments than regular comments and, largely, I don't see it at all.
It'll update your plugins. It'll add security features like people trying to brute force log into your website.
It'll allow you to log in easier because it allows you some single sign-on stuff from WordPress.com. That's the first tab of features from Jetpack, which is amazing.
I think image performance is a super big deal on websites. I just use Jetpack raw for images on CSS-Tricks even though I'm an image nerd and want to do the best that I possibly can. WordPress does such a good job anyway. It does responsive images naturally.
You flip on the site accelerator feature and then they're CDN hosted too. Then you flip on lazy loading and you get that too, even in browsers that don't support native lazy loading. Incredible image handling just by toggling on a few tabs, which is amazing.
Their instant search feature, which is just launching, they already have a really good thing that you just flip it on and your search gets way better, which I use on CSS-Tricks, and I'll be using this instant search feature, which just takes that feature set and makes it even awesomer, the full-page search experience with all kinds of filter toggles and stuff like that. it's going to be awesome.
Now I've covered the first two tabs of Jetpack and there are four tabs to go, so I'm going to stop there for now. Jetpack for WordPress is awesome.
[Banjo music stops]
Chris: This is like the most random thought because I just did this the other day on our CodePen documentation. It didn't have a left sidebar of all the docs available on it. I was just looking at the Stripe docs which, of course, has that. You know who else does? Every single other documentation thing ever.
[Laughter]
Chris: Maybe it's just a standard thing but I think it comes from the idea that we all have VS Code open all day or any other. That's the standard developer environment is file system stuff on the left and words on the right. [Laughter]
Dave: Yeah, things to click on the left. Things to read on the right.
Chris: Yeah. I just copied it because, to me, it's just a little templating, HTML, CSS change. I'm like, I'm going to do this. It's so stupid that we don't have this. Every other docs have this, so I'm going to do it.
I have a question for you, Suz, about overengineering a Stripe integration. I think this is a thing that we did historically at CodePen. I think the vibe is that we regret it a little bit.
For example, you have customers that pay for stuff. CodePen has pro plans and you upgrade to them. Then you should be able to, within CodePen, see that, see some evidence of what happened and look at an invoice and look at the last four months of invoices or whatever and see when you upgraded and when you're downgraded. You have all this information about payment history. That's kind of the point of having a payment provider is they help with that.
I don't know if it was just historical. I didn't lead up the billing projects at CodePen ever. But, you know, we look at them and we're like, "This isn't as good as it could be." We have problems with it once in a while, you know, like, "This is a pain in the butt."
I think what we did was kind of like, oh, when somebody upgrades, changes plans, or something, we're going to write it to our own data. We're going to do all the Stripe stuff that we need to do and we're going to write all that information to our own database, so we have a database that is our payment stuff that happened database.
Lately, the vibe has been like, we should just ditch all that. If you want to show somebody their billing history, just use the Stripe API, get the information from the API, and show it on the screen. That way the source of truth is Stripe, not your own database, because things just have a bad habit of getting out of sync for whatever reasons. Our database is just a record. It's not truth like Stripe it. Stripe is never wrong.
[Laughter]
Chris: You know what I mean. Maybe… Maybe there are examples.
Suz: We try not to be.
Chris: Yeah.
Suz: We try to … [Laughter]
Chris: But would you recommend that? I know that's a pretty high level, weird question. I don't know if it's appropriate or not. When people build billing integrations, would you suggest not building your own database to track billing historical stuff and just use the APIs directly all the time?
Suz: Chris, it's almost like I paid you to say that because that's an internal conversion that we're having right now, like exactly that and around billing as well. We realize that, in our documentation right now, we don't have the best -- we really hate being super-prescriptive because we realize every business is different. At the same time, there is a foundational bunch of common scenarios such as this, which come up time-and-time again, which we get asked about a lot. It's an extremely valid question. It's very appropriate.
There are several things around this that I can break down. The first is, yes, that's an actual concern because you don't want to do any heavy lifting that Stripe can do for you, right?
Chris: Mm-hmm.
Suz: Usually, at the bare minimum, we recommend that you save the customer number or the customer ID, which we give you, so that you can then backreference. But at the same time, we don't necessarily want you to hit the Stripe API every time someone logs in or wants to look at their account page to get that fresh information because it's not as nice of an experience for the user because you're having to go and fetch this stuff. Then also, just hitting our API all the time for that reason is just sort of feels kind of clunky and awkward. Then you have the problem of, as you said, just having to cache those things on your own site and then having to make sure that those things stay in sync.
What I can talk about right now is that we are working on tools to try and help with that. The things that you mentioned such as people being able to view their billing history, being able to update their payment details, and things like that, that is something that we're actively looking into right now.
Chris: Mm-hmm.
Suz: There hopefully should be more news about that. Also, we're trying to come up with a way to be able to give recommendations for people such as yourself without being too prescriptive so that you don't have any foot guns just because you had this other edge case that we weren't aware of, if that makes sense.
Chris: Mm-hmm.
Suz: The biggest thing that I can recommend for you right now is webhooks in order to keep your data in sync. Webhooks can be a little bit weird to learn. I know that, Chris, you're a very established and knowledgeable developer, so you wouldn't have a problem with these. Webhooks can be really great for just being able to listen for when a customer updates something and then you can sync it back to your end. You don't have to have all this other really intense business logic and jumping through hoops and things like that based on the customer's business logic that they're going through, if that makes sense.
Chris: Yeah, it does. Yeah, webhooks are just awesome, period. That's just a nice way to work, I think, for any app. It's nice that you have them.
Suz: Yeah, it's a slight non-answer for you but, at the minimum, you want to store the customer ID. But I understand that you also want more information so that you can show somebody that stuff.
Chris: In a way, I want more from the API and less that I have to do, so I'm kind of envisioning, structurally, if we're writing this from scratch on day one, you'd have a database because you need a little bit on your site.
Suz: Mm-hmm.
Chris: If you have paid plans for a website, like if Dave was going to add pro plans to some drawing app he was building or something, the database would have very little in it.
Dave: DaveRupert.consulting.
Chris: It would have a customer ID.
Suz: Mm-hmm.
Chris: It would have whether they're paid or not.
Suz: Exactly.
Chris: And maybe what tier they're on or something but very little else. You know? Not like when they upgraded because that's the stuff that gets out of sync. All your database needs to know is, do I need to show this div or not because they're pro or not.
Suz: Exactly. Yeah. You've just got to think about what's the bare minimum that the user needs to see and then I can implement that logic, right? Sometimes users just want to see the last four of their credit card because they want to log in and be like, "Oh, I got a new credit card. It has a different number. Do I need to update this account or did I do it last week? I forgot." Right? If you can just show them last four, most of the time, unless they've gotten a new expiry date or whatever, but Stripe handles a lot of that for you now.
Chris: Yeah.
Suz: Unless they have the same card, a different expiry date, they can immediately see if they need to update that.
Chris: Oh, that's cool.
Suz: So just like little bits of magic are the things you want to store.
Chris: I wouldn't even store that. Screw it.
Suz: Yeah, exactly. [Laughter]
Chris: I would store nothing.
Suz: It really depends on what you want to do for your user because, yes, you can actually just completely rely on Stripe for that data and just grab it just in time for the user, but it's really up to what experience you want to offer for them.
Chris: Do people--? Now I'm thinking, okay, this database table has customer IDs and whether they're pro or not. Maybe you don't even have tiers, so it's just a bullion and the webhooks update it. You get a webhook from Stripe that says, "Oh, their plan expired." Okay, the one turns to a zero then.
Suz: Mm-hmm.
Chris: On my end, the user's experience is totally different in my app because they're not pro anymore. That's all I need but that's so little that it makes me not even want to have that table. I think that would be next level for Stripe to be like, "You don't have to store anything. You can even ask Stripe if they're pro or not on every page load." I mean that might be a little heavy API usage, but I think that would be cool. I don't have to code any billing anything because it's entirely handled by Stripe.
Suz: It is really nice. Unless you have millions of users all logging in at once. So, for example, I know that Twitch extensions have this problem because everyone will join a Twitch stream at once and then that extension just gets hit with a massive load of traffic.
Chris: Right.
Suz: Because it's like a plugin for their Twitch page, right? And so, you have to throttle those things. The reason why that's relevant is because Stripe has API limits, and so it's approximately 100 a second for reads, 100 a second for writes. So, if your users are all going to log in for a specific event on CodePen, that's when that would fall over because you're going to get a bunch of 429s.
Chris: We couldn't. We couldn't do it on CodePen, but for a small-scale thing, we could do it.
Suz: But it is hard to be prescriptive because that's a very valid example of why you wouldn't want to hit the API and rely on it for everything, right?
Chris: Yeah. Plus, it's like JavaScript only, right? That's not true. Why would I say that? I just think of it that way because we do everything that way.
Suz: Yeah, we have other staircases, too, on the backend.
Chris: Yeah. It just feels weird. It always feels weird to me to hit a third-party API from server-side code in real-time. You know? Because then it's like, then the page, the document--
Suz: Yeah, it's just calling.
Chris: It doesn't load until -- yeah.
Suz: Yeah, that's the thing.
Chris: Here's a hard one for you.
Suz: Okay.
Chris: This is not hard but, like--
Suz: I love that this is just like CodePen Clinic with Stripe. You know? [Laughter]
Chris: Yeah, but then I'll stop.
Dave: Yeah.
Chris: We should talk about other stuff, but I need some advice here. This is one that's less -- you probably get it all the time, but we'll see.
At one point, we decided, I think we're leaving money on the table by not offering PayPal as a payment method to users because I think there are certain users. This was kind of a guess. There are certain users out there that just are like, "Oh, they don't have PayPal. Screw it." This was a lot of years ago, so I don't know if times have changed or what.
We decide, we've got to have that. You know? Braintree is a competitor of Stripe that offers the same kind of stuff, but they're like, "Oh, Braintree. It's amazing. You get Apple Pay and you get credit card stuff too." It's like, "You should use it," and they're owned by PayPal. If you want good PayPal APIs, the trick is to use Braintree.
But, the second you do that, you've really complicated your billing workflow a lot because now you have two payment providers you have to deal with. You have two sets of webhooks and the APIs are not going to be the same. They're going to be weird. You're writing middleman stuff. I don't know. That's another predicament we're in. It's not terrible but it's certainly -- it's not twice as hard. It's got to be 10x hard to deal with two of those things. Do you have general advice you shell out around that? Is Stripe for PayPal coming? Probably not.
Dave: [Laughter]
Suz: I don't have a lot to share on this topic. I totally empathize that that is absolutely an issue. Stripe does support Apple Pay and Google Pay.
Chris: Mm-hmm.
Suz: As you mentioned, Braintree also supports that. It's just that we don't support PayPal, so that is likely to be your actual reality that you just described there.
Chris: Yeah. Yeah. Not a big deal. I'm just curious because the question is, are you actually leaving money on the table if you don't support something like PayPal or is that just BS or is there never an answer to that because it totally depends on what your audience is and what they care about?
Suz: Yeah. I think that, with billing, it's more complicated. Let's say it's just like a one-off donation or something. You can just throw the PayPal button on there, you know, as like an embed or whatever.
Chris: Mm-hmm.
Suz: And try to see and do a test to see how many you get. Short of actually reimplementing all of that just to try it and then only to have to get stuck with managing that if you get three payments and then now you feel like that's grandfathered in because those people are going to be on those payments forever, it is a really tough problem to solve because you don't know, right? Whereas, other payment options such as let's say you're on Stripe and you want to tick the Apple Pay box, you want to tick the Google Pay box, and then you want to tick XYZ country, you can just kind of trial that country and it doesn't actually cause any extra work for you. You know what I'm saying?
Chris: Sure.
Suz: But the PayPal issue definitely causes that extra work for you because you're actually writing the code to implement it. Yeah, it is a hairy problem.
Chris: I really like that advice, though. I like the advice of, like, as a test, make it available but not for real. Just with a little Pay Now button where--I don't know--maybe it's only your annual plan or something and you can do it that way.
Suz: Or you could be a little bit naughty. I'm not actually recommending this but I know that there is a practice in the industry--again, I'm not necessarily recommending it--where people will just put a button and it'll have a quick modal saying, "Sorry, that's not available right now," or something and then you just see how many times people click on it.
Chris: Oh, yeah. Just as a UX….
Suz: It's a slight inconvenience for the user, so it's a little controversial, but it's just like doing a little bit of research to see how many people actually clicked on it.
Chris: It is. I mean, whatever. There may be some degree of sketchiness to it but set that aside for a second. What it doesn't do is -- let's say it actually -- that's just their first instinct is to click that thing but would they have upgraded or not? What you want to know is people that can only pay that way or that absolutely walk away if that's not on the table.
We can look at our numbers now and be like, hey, it's X percentage PayPal and Y percentage Stripe, so that means if we got rid of PayPal, that X percentage is gone. That's not true because, certainly, some chunk of those people that pay with PayPal would have paid some other way. They just chose not to because we equally support both.
Dave: Yeah. Well, I have a lot of -- we do ShopTalk via PayPal, but I have a lot of kind of fluid cash. Discretionary income, we'll call it, in my PayPal.
[Laughter]
Dave: It's like, "Oh, I want a keyboard. What's in my PayPal? Okay, I can get a keyboard." I'm probably in that camp that would want to just use PayPal because that's where all the money is already at. But I'm also in that, like, if they click the upgrade button, they probably don't care. They've got the credit card out anyway. They just want it to come out the right amount every month. They don't really care which service.
Suz: Yeah.
Chris: The real answer here is for Stripe and PayPal to just be super friends, get together, port all the data over to Stripe, all the APIs work the same way. It's going to be great. It's coming next year.
Just kidding. It's totally not, I'm sure.
Dave: (Indiscernible)
[Laughter]
Suz: There's this new standard.
Chris: Yeah.
Suz: As per SKCD, right? There's this new standard that we're all working on and that's going to be the one that saves us all, right?
Dave: That's the one. Yeah. Yeah.
Suz: That's exactly what got us here in the first place.
Dave: Don't even contribute to the old stuff because the new stuff is coming. The new stuff is going to be here.
[Banjo music starts]
Chris Enns: This episode of ShopTalk Show is also brought to you by X-Team. That's x-team.com/shoptalkshow.
X-Team allows you to work from anywhere for the world's leading brands and get support to do more of what you love as a developer. Maybe you haven't heard of X-Team before but X-Team is a 100% remote company that helps companies scale their development teams by providing them with extraordinary teams of developers from around the world. They believe in living a life of freedom that allows developers--that's you--to spend more time getting energized by your passions. They foster a unique, active lifestyle and culture around this idea that continues to attract thousands of developers to apply every day.
X-Team is the energizing community for developers in the world. What separates X-Team from their competition is a level of attention and care they give to their developers. They proactively support them, fund their learning and growth, and connect them in roaming hacker houses around the world and then give them a remote environment that motivates and inspires them on a daily basis. Where other companies simply place and drop their talent, they foster and cater to their unified team of developers centered around the same beliefs, values, and lifestyle.
Check out X-Team if you'd like the chance to work with big brands like Riot Games, FOX Broadcasting, Kaplan Incorporated, Coinbase, Beachbody, and more. You get to live and work in one of their roaming hacker houses, X-Outposts they call them, around the world that changes locations monthly, allowing you to explore and work remotely in the most beautiful locations. You'll get to take part in adventures, share passions, and learn how to be a better remote developer.
You'll get to take part in one of the most energizing communities for developers in the world by participating in their seasons, a three-month experience filled with challenges, rewards, games, competitions, and more, all centered a theme that will inspire and energize you. And you get $2,500 per year to spend on doing more of what you love and staying energized. Use it on conferences, courses, video games, photography equipment, and more.
If you're a developer who is looking for a chance to try out remote work, visit x-team.com/shoptalkshow and find out more. Our thanks to X-Team for sponsoring this episode of ShopTalk Show.
[Banjo music stops]
Chris: Can we talk about streaming for a minute? You're into that, right?
Suz: Yeah, we can talk about that.
Chris: What is your -- like, why are you into it? What do you do there? Tell me about streaming, period.
Suz: Yeah, I think it was 2016, I saw my friend Nolan Lawson stream himself working on Patch DB. Patch DB is a huge, open-source library, right? I contribute to open-source libraries too, but they're very small, SMOL, and they don't have a huge user base but they're very useful to the people who use them. Does that make sense? It's like the quality over quantity rather than quality and quantity.
I was so fascinated watching him maintain open-source because I was like, "What is it like to have a really stressful project? I wouldn't even know what that was like."
I loved watching that and I said to him, "People always feel intimidated about the hardware SDKs that I write and that's mostly what I write," and it especially was at the time. "I'm just writing JavaScript at the end of the day. Do you think if I streamed this, people would -- the penny would drop, they would get it, and then they would want to maybe contribute?"
Chris: Mm-hmm.
Suz: Or they would not put me on a pedestal as much because I really don't enjoy that. He's like, "Yeah, you'd be surprised." I think his comment was literally, "You'd be surprised at what people would watch." [Laughter]
Dave: [Laughter]
Suz: So, we did a stream.
Dave: That's like ominous and cool.
Suz: I know. I know.
Dave: [Laughter] Yeah.
Suz: Let's keep it just about development but, yeah, it was a very funny comment. I thought, well, I'm definitely a home-body. I don't do a lot on the weekends, and so I thought, "Well, what if I just turn a webcam on, use a pair of Apple headphones, and just do it?" I rehearsed it the night before and it was like, I can't make a single mistake. I'm going to have everything perfect and things like that.
It was really fun and I had like nine people, I think, join and that's because I put it on Facebook and a bunch of social media, so it was really my friends and family just going along with it to make me feel better, right? It kind of grew from there and it became much more about why I initially did it. I don't rehearse it anymore, but I do have a sophisticated setup that just allows me to record and go, which is very cool.
Dave: I will say, you're one of my favorite streamers. You're in the chill stream camp. It's very chill stream. You're not like, "Dudes, check out my project!" It's great.
Chris: [Laughter]
Dave: But one thing I always cite about your stream is you're doing open-source, right? But I feel -- and maybe it's my fault. Maybe I have to go do something else on Sunday mornings or whatever, but I feel like a lot of your stream is just managing pull requests. [Laughter] You spend about a good hour of the two-hour stream, or however long you do it, just looking over PRs. I think that's really awesome for two reasons. That's open-source. I think people think it's this glorious, like, "I'm just slaying code, you know, just bashing it out. I wrote a bash script to write code for me," or whatever.
Suz: [Laughter]
Dave: It's like, "Okay. Let's see. This is -- they PR'd this. Okay. Well, yeah, that looks good," and then you just merge it. Then you add a bitmoji or whatever.
[Laughter]
Dave: I just think that's awesome and I feel like you really harness good, open-source maintainership. I find that very wonderful, so thank you.
Chris: Is that what it mostly is or all is this open-source maintenance? Is that the spirit of the stream?
Suz: I think Dave is right. Dave clearly watches my stream so I totally believe….
[Laughter]
Suz: That's exactly what it's like. We also have like 20 minutes of chitchat at the beginning. We're like, "What did you do this week? Look at this cool swag I got and look at this cool website that I made." Other than that, yes, that's actually been the evolution.
The delightful thing is, I started this stream because I wanted people to be less scared about perhaps contributing and now I actually just have so many contributions that happen. What I mean by so many is, you know, two or three a week, which is enough to fill an entire hour of looking at stuff and explaining it and understanding the code and maybe pulling it down and manually testing it.
Chris: Awesome.
Suz: Some people will open it on Saturday night because my stream is on Sunday morning. I'm like, "I see what you did there. You'll sort of get one in for the queue, right? You're queuing it up."
Dave: [Laughter] Trying to get on the show.
Suz: Which I love.
Dave: Yeah.
Suz: I actually used to just predominantly write code for two hours and now I do much less of that because other people are writing code for me. That's actually really fun. Then if I'm not merging pull requests, sometimes I'm getting issues open of actual bugs and then we just sit there and laugh at my bug. I'll say, "Oh, I know exactly what this is. Let's pull down the code and let me show you. Let me show you the exact line that this is happening that I wrote four years ago that I knew would eventually be a problem and now it is, right?"
We also just make fun of past mistakes and then we have this lovely kind of chill, satisfying feeling of fixing them as well. I would agree that these days it's less me, like, you know, churning out code like base mode, if that makes sense, as much as I roll my eyes at that.
Dave: Yeah.
Suz: It's more about the collaboration side of things, which I didn't expect to happen but that's been a nice accident.
Chris: You heard it here. Sunday mornings, watch.
Dave: Yeah, it's Sunday morning entertainment. For me, it's hard because of kids and whatever, you know. It's interrupted time at that time, but it's just very cool because, hey, this is good vibes and you'll do some stuff. I feel like you do some because it's all hardware and we should probably say that too. It's not just a coding stream. It's like coding JavaScript for Arduinos, basically, right?
Suz: Mm-hmm.
Dave: Is that--? Which I'm also interested in and that's why I watch. [Laughter] And I have tons of questions. But do you find it trouble? Is it hard to show what Arduinos are doing on your stream? Because now you're just physical. It's not just code. It's like I'm trying to get this light to show up or whatever.
Suz: Yeah, sometimes that happens. I do still get comments a lot in chat because Twitch has a live chat you can ask questions in if people haven't actually seen a live stream before. People will still say, "I have no idea what you're doing but I'm happy to watch." That to me says that there's still kind of like a breakdown of understanding there.
Usually, if I'm running anything on our Arduino, I'll hold it up to the webcam or have a second webcam because I'm trying to explain what's happening. I do have some chat macros so that if people say, "What is this library?" or, "What does it do?" I can just do a quick little command and it'll do an explanation for them so that we don't have to drop everything.
It's still hard to, I guess, communicate that virtually, if that makes sense. For those who haven't ever really -- for those who aren't even familiar with concepts such as like input/output pins, which is totally, like, it's very normal to not be familiar with that stuff if you never have to touch hardware. Just explaining that on a basic level, you know, requires a lot of backing up and just talking about binary and things like that, which is really interesting.
Dave: Is there a good start point for getting into programming chips with JavaScript? I have one of those Spark Kit Inventor Arduinos or whatever. It's pretty cool. Is that what it is? Yeah. I like it but that's more like, is it Java-based or something? It's like you're typing more C code style stuff or Arduino code, but I want to write JavaScript on these things. How do I get started into that realm of hardware?
Suz: Mm-hmm. Yeah, the good thing is that the ecosystem is so wide and large and varied now that you can get away with doing that quite a bit. There are a couple of options for you. You can buy a microcontroller that's able to run JavaScript. For example, the Tessel is one of those. The Tessel 2 runs Linux and you program on your regular computer, which is nice because you have your whole ID set up and all of your stuff. Then it can just deploy that code over to your Tessel 2, which is really fun. It's small enough that you can pretty much pull off most projects with it.
I think it's a better out-of-the-box experience than a Raspberry Pi. A lot of people say, "What's the difference between a Raspberry Pi and a Tessel?" It's just that the Tessel is just specifically very good at running a JavaScript for you, it doesn't do anything more, and the abstractions are a little bit better.
The other option you have is if you're comfortable learning Lua, which is very similar to JavaScript. There's a bunch of boards out there that can run Lua, such as Espressif.
Chris: Espressif like I-F at the end, Espressif?
Suz: Yes. Yes, it's Espressif.
Chris: Is that more--? You know, from the world I live in, I would think everybody just wants the JavaScript board, but is that language just as popular or more in this world?
Suz: Yeah, I think if you have -- so, if you have an ESP8266, that is a bunch of numbers and letters but that's a very common microcontroller that you can actually put Lua on, and so I was trying to find the different brands that actually make that a little bit easier. People prefer that just because the boards are a lot less expensive. If you go to AliExpress or a super-discounted Web store like that, you can get those things for $5 and they have all the pin breakouts and everything that you would want and they're a lot smaller too.
If you have a really small project and you want to be able to do a lot in a small, little footprint, they can be actually a better option for you. They're just more resource-constrained. They're not running Linux and your code, depending on the architecture, is either actually running Lua with an interpreter or it's actually compiling it down to a totally different thing like it could be compiling it down to Assembly instead.
Chris: That's wild. A Tessel 2 does run Linux and an ESP8266 doesn't?
Suz: Yeah, that's kind of how it is. It's basically like, what do you want your abstractions to be, what do you want your size to be, and what's your budget? It's just like every other tool that you're choosing, right? What are your variables?
Dave: It's like all the hobbies, right?
Suz: Yeah, what are your variables?
Dave: Yeah.
Suz: What do you want? I think the hardest thing with hardware is that there are so many things that you don't necessarily know what questions to ask and you don't know what you want. What's helpful is finding someone such as me to just walk you through the basic questions and then give you a recommendation.
Dave: Okay. Can I pitch an idea? This is going to be my whole fricken' retirement startup, but here's my idea. Can you help me?
Chris: [Laughter]
Dave: I want Arduino that's connected to the Internet. Whenever somebody assigns a GitHub issue to me, a thermoprinter will print out a ticket, almost like a short-order cook. Every time I get assigned an issue, I get a little piece of paper that's like, "Hey, you've got an issue," and I rip it off and I pin it to--
Chris: To one of those spinny with the spring on it.
Dave: Yeah, with the spinny, like, roof thing, yeah.
Chris: What's going on there?
Dave: Yeah, just like a short-order cook.
Chris: What do you got there?
Dave: Is that something you already have built?
Suz: Yeah, so I have a thermoprinter that I'm actually holding up, so those listening at home won't actually see that but we're on video chat. You can actually do this in the browser now. If you wanted to, you could have a back-end JavaScript webhook that does that for you. There are some really good node.js thermo-libraries out there, thermoprinter libraries.
Dave: Okay.
Suz: But you can also do it in the browser. I did a Gameboy camera Gameboy printer emulation.
Dave: Oh, wow.
Suz: Not emulation but a Web version and you can actually connect to one of these thermoprinters with either Bluetooth or USB and you can use Web Bluetooth or Web USB.
Dave: Okay.
Suz: Absolutely, you can do that right now.
Dave: Interesting. Okay. Well, I'll have to get the SKU there on the thermoprinter.
Chris: In your house, you could just glue it to the wall.
Suz: Mm-hmm.
Chris: It's got wi-fi so, what, it's hooked up to your router, I guess. How does it--? Just because it has wi-fi, does that mean it takes a webhook then? How do you--?
Suz: It doesn't have wi-fi, but this is where you could get one of those EPS8266s, basically set up and access point and webhook on it, and then you just sent it the string that you want to print. That would be very quick. But again, Bluetooth and USB tends to be quite common. You might be able to find a wi-fi one, which makes it way easier, but it's harder to lock it down security-wise, I guess.
Chris: It requires your computer too. Could you make one that's computer independent?
Suz: It's going to depend. Most of the time, you need at least a Raspberry Pi or something like that.
Chris: Okay. Yeah.
Suz: To actually do the connection for it. Have you seen the RAP? Lots of tears about this, but did you ever see the little Berg Cloud Little Printer?
Dave: Yeah!
Chris: Mm-hmm. Mm-hmm.
Dave: It's like -- I forget where. Did it come out and then it kind of went away? Is that right?
Suz: Yeah, hardware startups are really hard because they cost a lot of money and feedback cycles are very slow, so you have to keep that money and your runway going for a lot longer than software startups. That one, unfortunately, went down.
I did have one and what it would do is, you would subscribe to feeds such as, "I want a daily poem today," or, "I want the weather." Then it would print you out a little report every morning. It was the cutest thing ever. You could send each other pictures too, and it would just print the pictures out. It was the best thing.
Dave: Aw. I love it.
Suz: It had a little modem that you plugged into your router, and that was basically the little computer that would securely talk to the printer.
Chris: Oh!
Suz: It would be a very similar setup to that, if that makes sense.
Chris: It does. Somebody could have bought this thing who doesn't have a computer at all and still make it work, maybe.
Suz: Yeah, it was the most adorable thing ever. They ended up open-sourcing their back-end cloud server, so people have gone and reimplemented it and hosted it. Their little printers are living on, which is adorable.
Chris: Yeah. It's sad. It's a cool URL too, littleprinter.com. It just spins and spins. Didn't even renew the domain name. Sad.
Dave: Aww. It's adorable, fricken' adorable. You send daily puzzles?
Suz: It was the best and then it would stop. It would print. The paper would go behind this face silhouette cutout and, every time it stopped printing, it would print the face and then feed it through so that the face was showing again on the printer. That was its default.
Chris: [Laughter]
Suz: Just the details in it was so beautiful that, yes, it did actually make me excited about thermoprinters. That's why I went out and bought one and I've been playing with them for years, ever since.
Dave: Oh, man. I wonder. Yeah. I want this. I would love a little analog-y side of things, you know. Because I don't know. I feel like, specifically, with GitHub issues or whatever, maybe this is good for your stream too. When it's all digital, you're just like, "Dude, I don't know. Which issue was that? Where was that? I have no ideas." But if you had the little thing, little QR code to the issue or something.
Suz: No, this is the kind of IoT that I absolutely love. It's like little tiny augmentations. I think that I prefer those kinds of things.
I would also recommend Adafruit has a clone. They have a do-it-yourself version.
Dave: Okay.
Suz: They don't obviously reference the little printer, but it's like a kit with laser cut plastic and you put the thermoprinter in to make it look prettier.
Dave: Okay.
Suz: Yeah, if you Google Adafruit, they have a couple of kits and they have a tutorial that walks you through it. If it's just Python, you can swap that out for JavaScript if you want. But they have a lot of Python libraries that they do for that kind of stuff.
Dave: That's cool. I'll have to try to -- yeah. Here we go. All right. I'm just going to get the old credit card out.
[Laughter]
Chris: No, no, no, no, no, PayPal.
Dave: PayPal bucks. Yeah, my Stripe….
[Laughter]
Chris: Yeah.
Dave: Yeah.
Chris: We should be able to have--
Dave: Empty out the old account.
Chris: I always thought that would be cool to have a pay with Stripe where it was your Stripe account not a credit card. I guess that's what credit cards are for.
Suz: Yeah, we need Stripe Bucks. Stripe Bucks is like a joke we have internally.
Chris: [Laughter]
Dave: Yeah.
Suz: We don't have that. We're just like, "Oh, just use your Stripe Bucks." Yeah, it doesn't really exist.
Chris: [Laughter]
Dave: Ah, well.
Chris: We just have a little time left. I thought it would be interesting. It was six months at Stripe now and two and a half years or something like that at Microsoft before that. Also, DX and you mentioned Kickstarter before that. You bounced around at a lot of big places. At one point, you were a just straight-up front-end, right?
Suz: Yeah.
Chris: Now X. [Laughter]
Suz: [Laughter] Yeah, I was a front-end developer for 12 years and would just have to inherit different back-end languages as I went along, too, because let's be real. A front-end developer still has to edit Ruby sometimes and things like that. Yeah, and then I just kept being promoted to tech lead or promoted to, like, be "the responsible one" on the team.
[Laughter]
Suz: It was mostly because I was just angry that we weren't focusing on the user or I was just angry. I was like, "This matters for our experience as developers but we're actually making it a ton worse for the user by choosing ourselves and prioritizing ourselves in this case." I would just get angry all the time and I would want to fix things.
Whenever I went on run or on call, I was like, "Yes, this is my time to fix all the things that I wasn't allowed to fix." That made me think maybe developer advocacy would be better for me because I'm clearly passionate about this and maybe I will feel like I can actually have a better impact.
My job is literally to be persuasive about this stuff full time and so that's why I wanted to try doing that because the worst feeling in the world to me is when someone tries to run one of my libraries and it just blows up immediately and then they blame themselves. I just want people to not feel like that, so that was sort of why I moved. I just got so outraged by just this navel-gazing that sometimes developers do and I felt like I was the only one on the team that was actually thinking about the fact that we were shipping something to users and that they're the ones that are important. I'm not saying that everyone is like that, but it was just a common theme that I was the outlier on every team who was getting furious about this stuff.
Chris: Now you're at a company that has friction logs, so I guess you win.
Suz: That's like the best feeling. I can't even tell you how good it is when people are like, "Yes, we want you to tell us," and also, "If we don't have time to do it, you can just go ahead and pull request it and we'll accept it." I'm like, "Yes! This feels so good." [Laughter]
Dave: [Laughter] That's wonderful. Well, speaking of not having time. I know we have some hard stops here. This is another hard stop edition of ShopTalk, so we should wrap up. Thank you so much for coming on. This is such -- I don't know. This ticks a lot of boxes for stuff I wanted to talk about, so thank you. For people who aren't following you and giving you money, how can they do that?
Suz: [Laughter] Don't worry about giving me money. I think that I'm in a very privileged position being a developer. But you can definitely find me online through one basic social media handle, which is noopkat. You can call me "noop kat" at well. It doesn't really matter how you pronounce it. That's N-O-O-P-K-A-T.
Dave: All right. Twitch stream Sunday mornings if you're still doing that, I assume.
Suz: Mm-hmm.
Dave: And change, but Sunday mornings on Twitch. There you go. You can do bits. You can … bits.
Suz: Yeah, bits are fun.
Dave: [Laughter] Well, cool. All right, well, thank you very much. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.
If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. Chris, do you have anything else you'd like to say?
Chris: ShopTalkShow.com.