Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode -- Holiday Season episode -- of the ShopTalk Show. I'm Dave "oh, shit" Rupert and with me is Chris "dangit" Coyier.

Chris Coyier: [Laughter]

Dave: [Laughter] Hey, Chris.

Chris: I'm cool with being the PG version of our duo.

Dave: Okay.

Chris: That's fine with me.

Dave: Sorry for the bleeps. There's probably going to be a lot of that in this episode, but we'll get through it. Hey, Chris, who do we got in the studio today?

Chris: Well, we have a very special guest. There's all kinds of stuff that we can talk about. I'm very excited to have her on. Katie Sylor-Miller, hey, how are you?

Katie Sylor-Miller: Hi. I'm good. How are you?

Chris: Good. I'm very good, very good. Dave's joke was that one of the things that you're famous for is a website about everybody's favorite version control system, Git.

Katie: Yes.

Chris: Your website -- [Laughter]

Katie: [Laughter]

Chris: --which I'll let you introduce, is called -- get ready to bleep this -- OhShitGit.com.

Katie: [Laughter]

Chris: You know what? For the unbleeped version of both the website and this podcast, there is DangitGit.com that you can visit--

Katie: Yes.

Chris: --that's just a mirror of the same thing.

Katie: Yes, without the swears. [Laughter]

Chris: Yeah, fantastic. We just like to keep our clean rating here at ShopTalkShow.com. Maybe we'll bounce back and forth but, first of all, you're Katie. You're Boston. You're Etsy.

Katie: Mm-hmm.

Chris: What else? Can you tell us those things, but in your own words?

[Laughter]

Katie: Yeah. Yeah, so in addition to making swear filled websites, I also am a front-end architect at Etsy. As you mentioned, I am remote, so I live in Boston. We're headquartered in Brooklyn, so I get to go to New York several times a year and visit the office. Gosh--

Dave: See, that's the ideal, I think, for me.

[Laughter]

Dave: If a client or a company -- I could live where I want to, but then I get to visit New York.

Katie: Yeah. No, and it works out nice because my partner is not the biggest fan of New York and I absolutely love New York, so he doesn't have to come with me. [Laughter]

Dave: You can go do the New York things, eat a bagel in 20-degree weather.

Katie: Yep. Yep.

Chris: It's not next door, but it's not crazy, right? What, four hours by train?

Katie: Yeah, it's like three and a half hours on the train, which is a million times better than flying anywhere. Train travel is civilized. You just walk on and you have a nice, comfy seat with lots of legroom and wi-fi.

Chris: Oh, God.

Dave: Oh, living the life.

Katie: I know.

Dave: You know my favorite thing about New York isn't the Natural History Museum or Central Park. It's paying $14 for a beverage. I think that's just what -- that's my favorite part of the whole NY experience.

Katie: Yeah.

Chris: [Laughter]

Katie: It's crazy. It's crazy.

Chris: So, you go down to Boston once in a while, but I almost mostly want to talk about life at Etsy and what the heck a front-end architect is and all that stuff. We already did the Git thing, so let's go there first. What is it?

Katie: Yeah, so the Oh Shit, Git!?! website kind of came out of when I was learning Git myself. I had been a .NET developer for a really long time. When you are using the Microsoft ecosystem, you used to use this other source control system called Team Foundation Server, which is all visual and built into Visual Studio.

Then I kind of got thrown into Git and someone was standing over my shoulder and saying, "Okay, type this into the command-line. Type this into the command-line. Oh, wait, you don't have that alias CO set in your Bash profile."

[Laughter]

Katie: "So, wait. What's the real command?" It was a disaster, basically. I kept making these mistakes and I would Google and look on Stack Overflow, and so I had this list of notes, the problems that I got into all the time, and then how I eventually figured out how to solve them.

Chris: It's just every week for me, still.

Katie: Oh, well--

Dave: I don't merge without Googling first.

Katie: Yeah.

[Laughter]

Dave: The most basic, because you flip those two around, you get very different, like, Git merge master my feature.

Katie: Mm-hmm.

Dave: Or Git merge my feature master. Those are two very different commands.

Katie: Extremely different.

Chris: …origin.

Katie: Yeah.

Chris: Yeah.

Dave: Oh, yeah. Oh, yeah.

Katie: Yeah, so you would always want to do origin but, yeah, Git is so baffling, I think, when you're first learning it. It's baffling because everything is in the command-line. I don't know about both of you, but I'm a very visual person. That's why I'm a front-end developer is because I'm a visual person. Having a bunch of text in a command-line just didn't make any sense at all to me what was happening under the hood because you can't see it, you know.

Chris: Are you command-line Git to this day, or did you -- because there are options to not command-line Git, for sure?

Katie: Yeah. No, well, I think the thing is that because of the website and it going viral and people all of a sudden treating me as though I was a Git expert when really I was barely functionally literate in Git, it kind of forced me to actually go out and learn the underlying principles and fundamentals of what are the data structures; what do all these commands actually do under the hood? Now, I do everything on the command-line and I feel super comfortable with it because the picture is in my head of what are all these commands doing?

Chris: Yeah. Yeah.

Katie: I don't need to have it visually on the screen. I have it in my head as, like, a solid mental model.

Chris: Would you believe people think I know how to do CSS, too?

Katie: [Laughter] I mean, isn't your Twitter handle like @CSS?

Chris: I bought that, though, with money.

[Laughter]

Dave: You just buy my problem. I think that's awesome that you were like, "I'm going to learn a thing. I'm going to make a website about the thing I'm learning," which is just the classic, quintessential, "What project should I do?" You should do that kind of project. I think it's great, but it's not even a "how to use Git," exactly. It's specifically how do I fix my problem. I have broken it. The head is detached, whatever that means. How do I get out? I find this site very useful.

Katie: Thank you. Yeah.

Chris: What's one? This is our thing on the show is to attempt to do things over audio that should never, ever be done via audio. Sometimes we do mouth blogging. That's one of our favorites.

Katie: Okay. Okay.

Chris: Or we try to explain some CSS concept in 45 minutes that's like float left, you know.

Katie: Mm-hmm.

Dave: Yeah, let's just tackle the command-line via audio.

Chris: Yeah.

Katie: Yeah.

[Laughter]

Dave: This should be great.

Chris: Well, this one would be like one where I'm on a feature branch and I made some changes. I committed them and I pushed them.

Katie: Mm-hmm.

Chris: Or, wait. Let's stop one short of that. Let's say I committed them to my local brand. I'm like, "Nope. Bad. Did not want to do that." That happens to me, I'd say, all the time.

Katie: Yeah.

Chris: That would be an "oh shit" moment, right, where I'd be like, "Oh, I absolutely don't want to commit that thing. It actually has a mistake. Most likely, I'm on the wrong branch, like I'm on master and I don't want to be. I want to be on my feature branch. Can we mouth blog that one?

Katie: Yeah. Yeah, totally. I think the first thing, which is kind of a pro tip I tell everyone, is if you Google Git branch in Bash command then there's a bunch of different solutions that come up for how to update your Bash prompt so it shows you which branch you currently checked out in Git.

Chris: Oh!

Katie: With Git, obviously, you can make mistakes and there are ways to fix them, but I think the best solution is not to make the mistake at all.

Chris: That's a nice sentiment.

Katie: [Laughter]

Chris: Okay, so you're morphing your terminal to have some visual aspects to it to help you.

Katie: Yeah.

Chris: I don't even use a terminal. I mean I can kind of do it, but I use Git Tower. I've experimented with other landscapes of it, but it helps me in that there's a big thing that says, "HEAD."

Katie: [Laughter]

Chris: It's attached on the sidebar to the branch that I'm on, but it's the visual equivalent of that, right? If you're on your terminal at all and you happen to be CD'd into a directory that has Git in it.

Katie: Mm-hmm. Yep, and it'll show you whatever is the currently checked out branch so, as you said, whatever branch head is currently pointing to.

Chris: But it's possible you're in your code editor making changes and you didn't even think about what branch you're on, right?

Katie: Oh, totally. Yeah, so in that case, if we can't prevent the problem because obviously you can't prevent every problem, the solution is to use what's called Git Reset. What Reset does is, you pass in either a direct commit reference, so like a hash for a commit in history, a previous one, or you can pass in a bunch of shorthand properties like HEAD~ (head tilde), which takes you back in time one commit or HEAD~2, which takes you back in time two commits.

Chris: It's that easy? Seriously?

Katie: It is. Yeah. Then what Reset does is it takes those commits that you've specified. It detaches them from the brand and then drops all those changes that were made in that commit back into your staging area or your workspace depending on….

Chris: That's good for people to know, too. It's not like you have to delete your work. They just go to un-staged files again. Oh, thank gosh.

Katie: Yeah. Yeah.

Chris: Now I can stash them, probably. I don't know how many people use stash, but I feel like that's my most commonly used thing ever because I make so many mistakes about which branch I'm on - constant, constantly. I should probably reevaluate my life because I am always on the wrong branch, always.

Katie: [Laughter]

Dave: Git stash, Git pull, Git stash pop.

Chris: Yeah.

Katie: Yeah.

Dave: …every day all day.

Katie: Yep.

Chris: I almost think that maybe Tower gives me bad habits because it's so inconsequential when I am on the wrong branch that when I go to switch without committing the files, it's like, oh, you probably just want to stash those quick before you switch, right? It just automatically does that.

But then it doesn't automatically un-stash them, so whatever. I have to grab them out. But that's my trick, right? Even if I commit it, I go, "Oh, crap. Back up." What you're saying is very easy on the command-line. Just Git HEAD~.

Katie: Yeah, Git HEAD~. Yep, and head is H-E-A-D all in caps and then the tilde.

Chris: Oh, nice. Yeah.

Katie: And it goes back one.

Chris: Or two or three or whatever.

Katie: Yep.

Chris: Then probably stash them and then probably move branch and then probably un-stash the stuff and then get it on the right branch. Oh, we did it. We mouth blogged a mistake.

Katie: Whoo-hoo!

Chris: What's the most common mistake, though? Is there one that you chose to make the first thing on this website because it's so common?

Katie: There were a bunch. Yeah, there were a bunch of them. Another one that I think was super common for me was, I would commit something and then I didn't do the right formatting for the commit message, like if I'm committing to master. Typically, we have a set format where you are supposed to put a link to a Jira ticket so it would be like [FES-1234 for, like, I'm on the FES team and we have ticket number 1234 in Jira. Then you put your description. A lot of times I would forget to put in the right text or I would realize after the fact.

Chris: You need to change your commit message.

Katie: Right.

Chris: Yep.

Katie: There's gitcommit--amend.

Dave: Oh!

Katie: Which will open up. For me, because I'm in the command-line, it opens up VIM and gives me the existing commit message. Then I can use VIM to edit the commit message and then hit Esc:w.

Chris: Ah, yeah, it's amend, not append.

Katie: Yeah, amend. That is a really good tool for, like, "I just messed up my commit message and I need to fix it." Amend also works if you forgot to add a file to staging and you want to commit it with your other changes. You add the file into staging and then run gitcommit--amend. Then it'll add that file into the previous commit.

Chris: Oh.

Dave: Then you have to force push it up, right, because GitHub or whatever usually doesn't like that.

Katie: That is actually -- that's something to note. All of these changes that we're talking about like reset, amending a commit to change it, those are things that you should really only do if you haven't pushed up the current state of your local branch to a public place because all of these changes, they change the hash of that particular commit.

Say I push up my branch and Chris pulls it down and starts doing more work and adds another commit onto the branch. The commit he just added is going to be looking for a parent that has a specific hash value. It's going to be looking for ABCD123. If I amend that commit or if it reset that commit and I push it back up to master, then the commit that Chris's branch is attached to is gone, so Git can't find it in order to add onto it in history.

Chris: Okay.

Dave: It's like I need ABC123, but I only see BBC123.

Katie: Exactly. Exactly because when you make those changes, if you change the commit message, if you change the number of files, if you change the time and the date, then you're changing that hash because that hash is made up of all of those different factors. You have to be careful about not changing hashes on public branches. That's why you have to do a force push is because you've rewritten history and it's sort of Git's way of protecting you from getting into a situation where you've rewritten history out from underneath another person.

Dave: Yeah. GitHub, specifically that product, used to not -- you could force push to it fine. It would just update. Now, it'll say, "Dave Rupert force pushed this branch," or whatever. I'm like, "You jerk!"

[Laughter]

Katie: So, everyone knows to blame you.

Dave: Here I am trying to be Mr. Professional, super stealth and fix my error, but GitHub is like, "Dude, check out this idiot! He forgot a package.json," or whatever.

Chris: It's like the real meaning of Git Blame.

Dave: Dude, it's just Git Public Shaming, so oh well.

[Banjo music]

Chris Enns: This episode is brought to you by Backlog. Tis the season to be organized. With the holidays quickly approaching, Backlog is the perfect tool to help your team collaborate on work in one place. With task management, bug tracking, wikis, and Git rolled into one platform, Backlog provides the powerful features development teams need with an easy interface anyone can use. Easily onboard your whole team and start working on tasks in minutes.

Right now, through December 5, 2019, you can sign up for a free trial of Backlog and get entered into a holiday giveaway up to $1,000 in gifts for you and your team. Invite your coworkers and get an additional entry per member that joins. To learn more, visit Backlog.com/holidaygiveaway. Terms and conditions apply.

Our thanks to Backlog for sponsoring this episode of ShopTalkShow.

Chris: Okay, so just one more and then we'll talk about something else, unless you guys want to talk about this forever, in which case that's cool too because I kind of love it.

Let's say you went one step further and you did actually commit it and it did actually go public, which is like, oh, then you're really embarrassed because you're like, "Oh, gosh. Smurf it. That's not what I wanted to do."

Katie: [Laughter]

Chris: Now everybody can see my mistake. I'm so nervous about it because, I think, like in the early days when we were learning Git, one of the value propositions was like, oh, the whole point of this is that you can roll back so effortlessly. How do you roll back when all you've been doing is FTPing to your server? You absolutely can't. You just have to remember what to change and then go change some stuff.

With Git, you just move -- is rollback even a command in Git? I think it might be. I don't know. To this day, other people do, so it doesn't matter particularly that I don't know because this problem gets solved at bigger companies, as you know. Probably by you.

Katie: Mm-hmm.

[Laughter]

Chris: I'm so mortified of it. I don't really get it. I'm like, you know what I'm going to do? I'm going to look at what I changed because I can see in the change log in the commits what happened. I'm going to commit new commits that undo the things that I did because pushing is very familiar to me.

Katie: Yeah.

Chris: I can just move the train forward, but that's not what you're supposed to do, right?

Katie: No.

Chris: If you make an actual mistake, you're supposed to go back in time.

Katie: Yeah. Yeah, so the command that you would use in that case is Git revert. Revert basically does for you exactly the thing that you did manually by looking at the previous commit and creating essentially a reverse patch that undoes the work.

Chris: What's confusing to me is that it's a new commit that reverts, though, right?

Katie: Yes.

Chris: It doesn't -- yeah.

Katie: Well, it's confusing, but that's the whole idea of, like, we can't change the public history is the reason why is because by creating a new commit on the tip of your branch, you can now push that up and the history of the branch hasn't changed. If other people have done work on top of that commit that you want to undo, it doesn't get disconnected from history.

Chris: I see. I like that.

Katie: It's weird. It's weird, I know, but that's the reason why is so that you have this surgical knife where you can go back in time to one or even you can revert multiple commits at the same time and then create a new commit that fixes it so that you don't rewrite history and screw up other pieces.

Chris: You literally can't rewrite history? Isn't there actually weird circumstances where you can but it's a bad idea or something?

Katie: Yeah. Any time that you rebase a branch and force push, you're rewriting history but that's a good thing. If you're on a feature branch and you want to bring it up to date with the current state of master, then you would do Git rebase origin master and then you'd have to force push your feature branch, but that's a good reason to rewrite your history.

Chris: Hmm.

Katie: What rebase does, in that case, is it gets the latest state of master. It basically disconnects your new commits on the branch and then replays them back on top of master so that the history in master is all part of the history of your branch.

Chris: Is that desirable sometimes and not other times?

Katie: Oh, that's desirable, I think, all the time. I'm team rebase because the other option you have to keep a feature branch up to date is to do a regular pull, which is a merge, so that creates a new commit that--

Chris: Merges.

Katie: --has two parents instead of one, so it has your feature branch and then it'll have whatever state of master. I hate those because that creates this extra commit that has nothing to do with the work that you're actually doing. It's just a merge that will take the history of these two different branches and connect them together.

Dave: It's like a maintenance step. It's not like a feature … or something.

Katie: Exactly. Exactly, yeah. It's not work that I've done or that I've changed and it creates this commit. You're like, "Well, I didn't do anything. I just want to be up to date with master. Why do I have this extra commit hanging around?"

Dave: Yeah.

Katie: I'm on team rebase. You can do gitpull--rebase and it'll do a rebase to update your branch instead of a merge to update your branch.

Dave: What about team squash and merge?

Katie: Yeah.

Dave: Team squash?

Chris: You like squashing too? I can't -- I barely understand all this, but I do enough to be effective at it but it's hard to wrap my mind around it. Here's a moment, though, that I can articulate where you have a feature branch and there's some stuff. You're about to push it onto master. Great. Then something goes wrong. Meh. Not the end of the world, but we want to roll back because the feature has some problems. If you did this replay all the commits over master, what commit do you roll back to?

Katie: Mm-hmm.

Chris: How do you even find where it happened? At least if you have the merge, you can find where that merge happened and just go one before it and be like, "Okay, that's where. That's pre- this feature," so at least I know where to roll back to.

Katie: Yeah, totally. No, and I think you're totally right, Chris. If you do a rebase and merge when you're merging your feature branch back into master, you do end up in that position. Also, a lot of times, if you look at my feature branch, I have 20 commits and they're all junk and the messages don't mean anything. It's like, maybe this will work this time, commit.

Dave: Yeah.

Katie: Yeah, so I don't think that is the best option. I think doing either a merge commit like you said where you do have that one point that you revert if something goes wrong or we can do a squash and merge, which basically takes all of the new commits on your feature branch and smooshes them into a single commit that gets added into master. You're still in that point where, if you have to roll back if you have a bug, you just have a single commit.

Chris: It's just one commit.

Katie: Yep.

Chris: Yeah. That's kind of nice because the branch that all the work was done on is still there. If you still need to look and see who did what--I don't know--it exists somewhere to look at but it's just not on master. You can't tell on master who did what, but who cares, right? Master doesn't have to be the one source of truth. The whole tree is the source.

Katie: Mm-hmm.

Chris: I don't know.

Katie: No, I think you're right. [Laughter]

Chris: Cool, so check out the website Dangit, git! or the PG13 version of it and check that out. We can still talk about Git stuff if it comes up, but you obviously -- like I'm sure you're a reference for Git stuff at Etsy. You're a front-end architect. Your job much transcends all of this stuff, right? Can you tell us about what life is like now?

I remember we were together, actually, at the JAMstack Conf when you kind of got the news or at least announced the news, right?

Katie: Yeah, thank you. Yeah, that was super exciting. It's something that I've been working towards and kind of asking for, for like a year now, so it's been a long process of proving why we need someone in this role and then why am I the right person to be in the role. I'm super excited. It's really fun.

Chris: Is there one of you or are there a bunch of front-end architects?

Katie: There's one, there's me, and first ever at the company. We have a few other architects who have been around for a couple of years, but they're doing a lot more systems things.

Chris: Mm-hmm.

Dave: How do you all define architect? I'm in a three-person company, so I guess I'm an architect. [Laughter] I guess I've worked with other companies and the role of architect has always been somewhat nebulous to me. Is it somebody who commits code? Do they not commit code? Is it somebody who, I guess, are they a manager of some sort? Do people have to vet things through them? How do you or, I guess, can you describe the role of architect and then specifically what a front-end architect does?

Katie: Yeah, so I think that architect, at least at Etsy, is one of -- to step along the IC technical track, so it's specifically not a management role. I've been a senior and a tech lead and a staff engineer and then this is sort of like the next logical step up. The more senior that you get, the more that the work that you do has impact and reach at the company outside of just your team. We have--oh, gosh--something like 300-something engineers total.

Chris: Holy cow. Really?

Katie: [Laughter]

Dave: That's front- and back-end?

Katie: Yeah, that's -- well, that's front-end, back-end, full-stack. We have mostly full-stack folks, but then there's a lot of systems people who are managing our networking. They're managing our computers that we run on in the cloud. We have data engineers whose entire job is to manage our big data stack. We have machine learning engineers. Then we have product engineers who are the ones who are doing the full-stack website development where they're implementing things in PHP. They're using our design system to implement things in the front end.

Gosh, I want to say there are at least 15 product teams and they're all doing different things. Then I have been, for my time at Etsy, I started on the design systems team and then moved into front-end infrastructure. Our job really was to support all of those product teams and to make sure that they have the tools and the processes in place that they need in order to build interfaces that are performant, that are reusable, that are accessible. How do we do dependency management between PHP and CSS and JavaScript because most of our core buyer-facing pages are written in PHP with more of like a vanilla/jQuery JavaScript codebase? We were solving a lot of these questions and these problems.

To me, architect is sort of just like taking the role of my team and making it very specifically my role to have those connections across the product teams to know what's happening and know what they need, and just make sure that we're solving the right problems--

Chris: Fascinating.

Katie: --for all of these product teams.

Chris: There's not -- otherwise, wouldn't be much glue between the teams.

Katie: Yeah.

Chris: It's kind of your job to make sure that you're glue.

Katie: Yeah.

Chris: Or at least a little bit.

Dave: That seems so important. I've been in a lot of companies where it's very siloed.

Katie: Mm-hmm.

Dave: It's like this is the whatever team, XYZ team. This is the ABC team. Neither team knows what the other one is doing and they're just putting up whatever and self-code reviewing. That crosscutting individual role seems really important.

Chris: What could do -- what's something--? No, you have one in your head, Dave. Let's hear it.

Dave: Well, I guess, accessibility is probably a great example. It's like one team is doing tabs one way and then the other team is doing it a totally different way and neither one is great. Do you end up being an escalation point for stuff like that? You're like, "Okay, here's actually how you do it," or is it educational?

Katie: Yeah, I think there is a big piece of it that's educational. Thankfully, we have a really, really great culture around using our design system and patterns in place that we've developed to make sure that all of our design system components like overlays, tabs, or some of those things that are really, really complicated, experiences to get right for accessibility. We provide canonical implementations of that for product teams to use.

Dave: I guess, let's say somebody new is hired fresh out of college or something. Is it then kind of your role to educate or onboard them to the design system and stuff like that?

Katie: Yeah, I think it would be. I think it would be more like meeting with newer engineers and having them say, "Oh, well, I didn't feel like I learned enough about the design system when I was onboarded," and then my job would be to sort of reach out to the folks who do onboarding and reach out to the design systems team and say, "Hey, y'all. I've heard this feedback. Let's look at what we're doing right now. Can we improve it? Do we need a new code lab?"

That's a practice we use is where you learn things by having a toy implementation that you pull down a Git repo and you go and you try to build something. Maybe we need to improve our code lab or maybe we need to have someone who is doing accessibility reviews set up a one-hour meeting with new hires to walk them through the process.

I think a lot of it is more like identifying the problems and escalating to the right people, "Hey, this is a problem. Let's all work together and figure out how we're going to solve it."

[Banjo music]

Chris Enns: This episode is sponsored by An Event Apart. An Event Apart is a premier Web design conference for UX and front-end folks just like you. Each event they put on is three days of design, code, and content for introduction designers and developers packed with tips, techniques, and insights into the future from industry shakes and shapers. All of their 2020 show dates have been announced: Washington, D.C. in April, Seattle in May, Boston at the end of June, Minneapolis in August, Orlando in October, and San Francisco back in December.

I asked Chris Coyier what else I should say here about An Event Apart and he said--

Chris: It's a good conference. You should go.

Chris Enns: For full details and for registration information, check out AnEventApart.com. Our thanks to An Event Apart for sponsoring this episode of the ShopTalk Show.

[Banjo music]

Chris: When I think of front-end, which is half of your job title, it's the browser, right? That's what the front-end means, usually, when we're talking about this kind of thing. It's the browser stuff. Then does that mean it's not native stuff, too? Etsy has got a bunch of native apps too, right? Do you get to peace out of that, or do you have to deal with it?

Katie: No, I generally am not super involved with the native app. However, we have certain pages in the app that load the website inside of a Web view because we haven't had the time or the resources to duplicate, you know, like checkout is insanely complicated, so we don't have right now a native checkout experience. It loads the regular Web checkout in a Web view, so there are touchpoints where something--

Chris: That's fascinating. Really? You'd think the native checkout would have all these advantages, right? Oh, then it's integrated with Android pay automatically or whatever. I could see how checkout on Etsy specifically is weird because it's like, send to this address or pay with PayPal or your saved credit card.

Katie: Mm-hmm.

Chris: Checkout is a little unique on Etsy, isn't it?

Katie: Yeah. Yeah, or what if you're buying items from two or three different sellers and each of them has a different policy?

Chris: Oh, yeah! That's what's really tricky, right?

Katie: Yeah.

Chris: The money goes to them, not to you, in a way.

Katie: Exactly, yeah. Yeah, so the money -- yeah, so I think it's just like -- as with everything in a big engineering organization, you're constantly making decisions about tradeoffs. How much is it worth investing in one thing over another? What's the consequence of that? What's the smartest decision here? Maybe sometimes we trade off something like having a super slick, completely native checkout app with the reliability of having a single team that owns all of checkout and owns a single code base. They don't have to be native engineers. They can just make the webpage. We're constantly making these tradeoffs.

Chris: That makes a ton of sense. You would be involved in that choice or whatever. I don't know.

Katie: Yeah, theoretically. [Laughter]

Chris: It feels like we're drilling you about your day-to-day job responsibilities. It's just because we're fascinated, I think, you know. What a cool role. It's like you stepped up the ladder a little bit and can look down upon a little wider view of what's going on. Is that what's happening?

Katie: Totally. Totally. Yeah.

Chris: What is a day-to-day kind of experience?

Katie: Well, I mean it's only been a couple weeks but, really, a lot of it is -- it's funny. I'm like this front-end architect, but the main thing that I've been doing is writing SQL to do data analysis [laughter] to try to figure out, like -- a big project I'm working on is rethinking our internal Web performance dashboards and metrics. What are we tracking? What are we looking at? What's important? How do we surface that? It's a lot of writing SQL to go and look at our RUM data and decide, okay, what's a better way to display this? What are the trends?

Gosh, another thing I've been working on is someone from our QA team reached out about having better integration between what the front-end infrastructure teams are doing and what the QA teams are doing, and so we had a meeting to talk about that. This is actually something I'm really excited about is to try to figure out for infrastructure teams to know, okay, what do we need to be doing. What do we need to be working on? We're going to do this UX user research and come up with a user journey map of the product development experience and use that to surface touchpoints and opportunities for where can we improve things like documentation. Where can we improve onboarding? Where are our systems not providing exactly what product engineers need in order to build a product and ship it out to the world and run an experiment and all of that?

Yeah, it's a lot of seeing problems and thinking about how are you going to fix them. Then a lot of it is going to be convincing other people that we need to go out and actually do this work.

Dave: Let's say QA or something. You could be like, "Oh, what's--?" just start using Cypris or something and maybe you do a proof of concept or something. You're like, "Hey, isn't this great?" But then to do the full coverage is going to be a lot of work.

Katie: Mm-hmm.

Dave: How do you start that or does that now politicking? Is that part of the job too?

Katie: [Laughter] Yeah.

Dave: I mean any office job.

Katie: I think it is going to be and it's something that I had already been doing a lot of. There's this concept. Maybe it was two years ago or a year ago. A guy named Kumar Garg, who used to work for the Office of Technology under President Obama, published a blog post and some tweets talking about this concept of influence without authority. I think that that really perfectly describes what it's like to grow as a technical leader at a big company is that you're expected to start tackling these bigger problems and these wider-reaching problems and have this wide impact. Yet, I don't have any authority to tell anybody what to do.

I'm not a manager. I'm not a product owner. I don't have budgetary oversight. All I can do is sort of come up with, okay, here is a problem. Here is why we need to solve it. Here is what I think we should maybe try to do and then go out and it's all convincing other people of believing that fact too. [Laughter]

Dave: Yeah. It does feel like you're a doctor. I do this in client service stuff. You're kind of like, "Okay, here's what it looks like the problem is. Here are some solutions to get around it. But, ultimately, it's up to them to take off with that and adopt. I can raise my voice and write blog posts or whatever, but it's ultimately up to some system of engineering managers or product owners to prioritize it.

Chris: If you need a minute to ruminate on it, that's cool, but I'm fascinated. You've been there a minute. What is some stuff you all do really well that you think is interesting?

Katie: Yeah, so I think something that we are really, really good at is culture of openness. I could probably jump into just about any Slack channel of any team at Etsy with a question about, "Hey, can you help me understand this?" or, "Hey, I need to make a change."

A lot of times, especially when I was on design systems, we would have to make these changes that are side wide. You have to constantly reach out to a million teams and be like, "How do I test this? How do I make sure that what I'm doing is right? Can you help me with this?" Universally, whenever that happens, people are kind, helpful, and generous with their time. I think, if you're thinking about what are the things that Etsy does really well, I think that having that culture of trusting each other.

Chris: That's awesome. It transcends a technological thing that you're doing, right? It's almost more important.

Dave: Yeah, I don't know. I think not responding for three days is usually the better solution. I don't know. Has anyone tried that? Is it just me?

Katie: [Laughter] Right. There was a place that I worked for a little while. I didn't work there for very long because I didn't like this attitude, but everything was very siloed. I reported into the UX org as a front-end engineer, and this is not Etsy, to be absolutely clear.

I wanted to make a change to a Jenkins job to output our CSS source maps. I said, "Hey, I know how to do this in the Grunt process. I know what I need to do to update this. Can somebody help me change Jenkins? Can we get this to happen?" They said, "Oh, well, no. You're not an engineer. You can't touch this system," because I didn't report into the engineering org and I wasn't in the right team to touch the Jenkins job.

Something like that would never-ever-ever happen at Etsy. [Laughter] People would be like, "Oh, you want to learn about Jenkins? Yes, please! Let me teach you," like, "Do my job for me. I love it." You know? [Laughter]

Dave: Oh, man. That's great. Yeah, it can get -- those silos are weird. Yeah, I've seen every which way.

Katie: Mm-hmm.

Dave: Even just how the Agile system churns. Like so-and-so may have whatever, 2,200 story points this sprint and they literally can't take time off to help you with a dear Jenkins problem because they'll get yelled at by their scrum master for not, whatever, slipping their average velocity or blah-blah-blah.

Katie: Mm-hmm.

Dave: It depends on that aspect of it too. Like your team -- whatever. If your team is so siloed and so, I guess, I want to say hydrophobic, but can't blend with any other team, that seems like a problem.

Katie: Yeah, totally.

Chris: Oh, my gosh. It's been a while.

Dave: I know Etsy has a big performance culture too.

Katie: Mm-hmm.

Dave: We've had Lara Hogan on the show. If you don't like her, that's fine. You can just say that.

Katie: No, I love her.

[Laughter]

Katie: I miss her every day. I love Lara.

Dave: You know, I know performance was a big part of Etsy's culture and you all worked very hard on that. Is that still--? You had mentioned you're redoing the performance dashboards. Is performance still one of the table stakes of Etsy?

Katie: Yeah, I think it's really interesting because company culture changes over time. A lot of it depends on the people. I think that, for a little while, we let performance slide a little bit. Something that my team has been working on and now I'm specifically focusing on is improving our culture of performance.

We've hired a bunch of new engineers who have come on, and so, with new people and new ideas, you have to constantly reinvent what your values are and reinvent your culture for these new people. Performance is something that is coming back into vogue, almost. People are starting to more--

Chris: I appreciate the honesty there. That's nice. It's true that sometimes stuff just -- even though you were great at it in the past doesn't mean you're great at it every day forever. There's kind of a rollercoaster of caring about stuff.

Katie: Mm-hmm.

[Laughter]

Katie: Yeah, and I think performance in the front-end space is really hard. We've always had a performance culture on the server where, if something added a couple hundred milliseconds to the server response time, then it would be very much like everyone was on top of it. People would be getting messages left and right. The kind of support structure would come up and be like, "How can we fix this? How can we solve this?" I think that the front-end part of it is really what I mean when I say that people hadn't really been thinking about it as much.

Dave: That's a really good point. One hundred milliseconds on the server, all of a sudden people show up. [Laughter] Managers are getting involved and stuff. One hundred milliseconds on the client and people are like, well--

Chris: Meh.

Katie: Yeah.

[Laughter]

Dave: Meh. Call me when it's ten million milliseconds or whatever.

Katie: Yeah, exactly.

Chris: That's the best. That's true facts.

Katie: Yeah. It was very much like, "Oh, well, browsers are fine. You just keep shipping all the JavaScript--"

Dave: Put it down there.

Katie: "--and it's fine."

Dave: They'll figure it out.

Katie: Yeah, so I think that I will amend to say that it's more front-end performance that hasn't been -- that kind of fell to the wayside as part of the culture. Server performance has always been huge. Yeah, so working on trying to fix that and surface that and help people understand why it's so important.

Dave: Performance and maintaining performance is hard. I consider myself very performance-minded. I went to webpagetest.org/ez, put my site in there, and I was like, "Sure, I'm fast. Right?"

Chris: What's /easy?

Dave: Like, nope. It's basically the easy or easy config mode.

Chris: Okay.

Dave: It just basically sets it to a mobile client and configures all that sort of stuff, like the right latency and stuff like that. I ran my site and it's like 45 seconds load or something. I just was like, "Goodness. What did I do? I added four little podcast thumbnails to my homepage. Did that really do it?"

It turned out it was how I was loading my fonts. I fixed my fonts and shaved off 33 seconds. I don't think that's scientific, hard data, but a 33-second page load improvement for fonts is incredible. It's so easy to get wrong or backtrack, I guess, like you were saying, like backslide. It's so easy to be like, "Oh, I'm now in a non-performant situation." I know the tools to get there or I can figure it out, but it's hard to monitor that and be aware all the time.

Katie: Yeah, totally. It's cumulative too, so one team runs an experiment that adds 30 kilobytes of JavaScript to the global bundle and then another team writes a different experiment that adds that same amount. Each individual team, when they're running their experiment, they might not see a huge degradation in perf. But once both of them are ramped up to 100% of traffic and they're interacting with each other, the effect really gets compounded over time.

You're right. It's very hard to lose track of the overall performance picture and it's little changes that one team makes that another team makes and, once they end up in the wild, it's worse for everybody.

Dave: Yeah, well, and it's always like, "Oh, well, this moved whatever revenue 1%. That's like $48 billion a year." You're like, "Ah! Is it, though?" Anyway. If it was really $48 billion a year, we would all have space yachts.

Katie: [Laughter]

Dave: [Laughter] One time … (indiscernible). Clearly, it did not add that much money because we are all not stupid rich.

Katie: Right. [Laughter] I wouldn't mind having a space yacht.

Dave: Yeah.

Katie: Let's solve that problem.

Chris: Whoo!

Katie: [Laughter]

Dave: [Laughter]

Chris: Space yacht?

Dave: Don't stop until space yacht.

Chris: That's amazing. WebPageTest is open source, isn't it? Somebody just -- how has nobody hopped in here and been like, "Just going to do a little cleanup design-wise here"?

Dave: Oh, if WebPageTest wants to reach out to [email protected], this would be a dream project because, goodness.

Katie: Well, the crazy story is it's one person, Pat Meenan, who I think--

Chris: Mm-hmm.

Dave: Mm-hmm.

Katie: I can't remember. He used to work at Google. He recently went somewhere else. He basically has been running it for years and years and years and he had a rack of devices in his basement because when you run a WebPageTest, most of the time when you choose a mobile device, it's actually pulling up the page on a real mobile device, which is why WebPageTest is so awesome and so useful is because you're seeing the real effects of having a low CPU or having reduced latency. He just had a rack of devices in his basement. [Laughter]

Dave: Yeah.

Katie: I don't know if that's true anymore.

Dave: And his grandma's basement in North Carolina, or something.

Katie: Yeah. [Laughter]

Dave: It's just different, but I don't -- I'm sure -- Google is, I think, pretty bought into this here. I'm sure they fund it. He has private instances, which I don't know. Do you get your own rack of devices in the basement or what?

Katie: No, you have to provide your own devices if you have a private instance.

Dave: Oh, really?

Katie: Yeah.

Dave: In your own office or in your own--?

Katie: In your network somewhere.

Dave: You have to send them to Dallas.

Chris: It has to be….

Katie: I could be wrong. From what I understand is if you run a private instance because we used to have one that is dead.

Dave: Oh, sorry.

Katie: If you had a private instance, unless you had your own farm of devices, it would just do the simulated device.

Dave: Dave Rupert does have a farm of devices [laughter] I have collected, so maybe I should open for business.

Katie: I could be wrong about that. I am definitely not a WebPageTest custom instance expert.

Chris: That was a lot of words. [Laughter]

Katie: I know, I was--

[Laughter]

Dave: If you want to get an API key to run automated, you have to email Pat, right? I think you still email somebody to get an API key. It's kind of wild.

Katie: Yeah.

Chris: I'm doing good on mine. I like the easy thing. I didn't know that, but I'm getting an F for cache static content only because of gravatar only.

Dave: Yeah. Gravatar, any third-party ad solution usually just fails.

Chris: I have a lot of Etsy tabs open right now, too, just because I was like, "Well, if Katie is going to be on the show, I'm going to open up Etsy just so I can be looking at the site while we're talking." Then I'm like, dum-du-dum. Now I have like 15 tabs open.

Katie: [Laughter]

Chris: Gosh, dangit!

Dave: Is there a secret coupon for Etsy?

Chris: [Laughter]

Katie: No.

[Laughter]

Katie: People ask me that all the time.

Dave: Christmas is coming up and--

Katie: No, we don't. We aren't the ones making and selling the items and getting -- we just skim a tiny little bit off of the top, but all the money goes to our amazing, creative, talented sellers directly, so we don't get discounts. The only discounts we get is if somebody has a sale on their shop and you happen to find it and you can use that but, no, we don't get a corporate discount or anything like that.

Chris: While we're doing absolutely inappropriate requests for Etsy, I really like the love, obviously, because then I can remember stuff. That's obvious on Etsy because now I have 15 new things I've hearted that I may or may not purchase at some time.

Katie: Mm-hmm.

Chris: I would think there'd be machine learning up the yahoo at Etsy. I want to teach it once that I don't want to see customizable drumsticks.

Katie: [Laughter]

Chris: Nope. I don't care about that. Or if something is obviously not of my taste, I want to be like, "Downvote!"

Katie: Ooh.

Chris: I want it to learn from what I don't like, and then I want my home screen to just be like a machine learning masterpiece of things that I do like.

Katie: Yeah, well, just teach it what you like.

Chris: I'm gonna. I'm gonna.

Dave: It'll happen. Okay.

Chris: I'm just kidding. I bought a marble tower for my daughter on Etsy for her birthday recently and now it's showing me 5,000 marble towers, but I'm cool with it because I like marble towers.

Katie: [Laughter] Marble towers are really cool.

Chris: Yeah. [Laughter]

Katie: Don't you want to buy more of them? Come on, Chris.

[Laughter]

Chris: I went big and I went too big because the marble tower is taller than she is. I actually put it in the closet for her next birthday because it's just straight-up too big. [Laughter]

[Laughter]

Dave: I go to my Etsy. Dave Rupert has maybe been looking at too much Dungeons & Dragons.

[Laughter]

Dave: The whole thing is Dungeons & Dragons. Well, Katie, thank you for coming on the show. Very excited about your role as front-end architect and what that will entail, so very curious. Keep us posted--

Katie: Yeah.

Dave: --on how that goes and what you're learning there--

Katie: Definitely.

Dave: --because it's very interesting. But for people who can't follow you or aren't following you and giving you money, how can they do that?

Katie: Yeah, you can follow me @KSylor on Twitter and there's a Twitter handle for the bleeped website. [Laughter] Yeah, I think Julia Evans and I, actually, of the wizard zines, we worked together to make a zine for Dangit, Git!

Chris: Amazing. Yay!

Katie: I'll make sure to give you the link that we can put in and send people to go and by the zine. It's only like $10, I think.

Dave: Oh, yeah.

Katie: It's a nice little thing to have. It goes into a lot more detail than the website does.

Dave: I love it. I actually need to purchase this.

Chris: You should put it on Etsy, huh? But now it's on Gumroad.

Katie: Yeah, it's on Gumroad.

Chris: That's cool.

Katie: That's where Julia has all of her zines.

Dave: Cool. Thank you, again, so much for coming on the show. 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, you got anything else you'd like to say?

Chris: [Loud inhale] ShopTalkShow.com.