Gitting After It with Katie Sylor-Miller

Katie Sylor-Miller, Frontend Architect at Etsy, has a passion for design systems, web performance, accessibility, and frontend infrastructure. She co-authored the Design Systems Handbook to spread her love of reusable components to engineers and designers. She’s spoken at conferences like Smashing Conf, PerfMatters Conf, JamStack Conf, JSConf US, and FrontendConf.ch (to name a few). Her website ohshitgit.com (and the swear-free version dangitgit.com) has helped millions of people worldwide get out of their Git messes, and has been translated into 23 different languages and counting.

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.

Corey: This episode is sponsored in part by our friends at Jellyfish. So, you’re sitting in front of your office chair, bleary eyed, parked in front of a powerpoint and—oh my sweet feathery Jesus its the night before the board meeting, because of course it is! As you slot that crappy screenshot of traffic light colored excel tables into your deck, or sift through endless spreadsheets looking for just the right data set, have you ever wondered, why is it that sales and marketing get all this shiny, awesome analytics and inside tools? Whereas, engineering basically gets left with the dregs. Well, the founders of Jellyfish certainly did. That’s why they created the Jellyfish Engineering Management Platform, but don’t you dare call it JEMP! Designed to make it simple to analyze your engineering organization, Jellyfish ingests signals from your tech stack. Including JIRA, Git, and collaborative tools. Yes, depressing to think of those things as your tech stack but this is 2021. They use that to create a model that accurately reflects just how the breakdown of engineering work aligns with your wider business objectives. In other words, it translates from code into spreadsheet. When you have to explain what you’re doing from an engineering perspective to people whose primary IDE is Microsoft Powerpoint, consider Jellyfish. Thats Jellyfish.co and tell them Corey sent you! Watch for the wince, thats my favorite part. 

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. I’m joined this week by Katie Sylor-Miller, who is a frontend architect at Etsy. Katie, thank you for joining me.

Katie: Hi, Corey. Thanks for having me.

Corey: So, I met you a long time ago—before anyone had ever heard of me and the world was happier for it—but since then you’ve done a lot of things. You’re obviously a frontend architect at Etsy. You’re a co-author of the Design Systems Handbook, and you were recently interviewed and included Will Larson’s book of staff engineering stories that people are mostly familiar with at staffeng.com.

Katie: Yeah.

Corey: So, you’ve done a lot of writing; you’ve done some talking, but let’s begin with the time that we met. To my understanding, it’s the only 
time we’ve ever met in person. And this harkens back to the first half—as I recall—of 2016 at the frontend conference in Zurich.

Katie: Yes, before either of us were known for anything. [laugh].

Corey: Exactly. And it was, oh, great. And I wound up getting invited to speak at a frontend conference. And my response was, “Uh, okay. Zurich sounds lovely. I’m thrilled to do it. Do you understand who you’re asking?”

There are frontend folks—which, according to the worst people on the internet is the easiest form of programming; it isn’t a real engineering job, and if that’s your opinion, please stop listening to anything I do ever again—secondly, then there’s the backend folks who write the API side of things and what the deep [unintelligible 00:02:03] and oh, that’s the way of the future. And people look at me and they think, “Oh, you’re a backend person,” if their frontend. If they’re backend, they look at me and think, “Oh, you’re a DevOps person.” Great. And if you’re on the DevOps space, you look at me and think, “What is wrong with this person?” And that’s mostly it.

But I was actually invited to speak at a frontend conference. And the reason that they invited me at all—turns out wasn’t a mistake—was that I was giving a talk that year called, “Terrible Ideas in Git,” which is the unifying force that ties all of those different specialties together by confusing the living hell out of us.

Katie: Yes. [laugh].

Corey: So, I gave a talk. I thought it was pretty decent. I’ve done some Twitter threads on similar themes. You did something actually useful that helps people and is more lasting—and right at that same conference, I believe, you were building slash kicking it off—ohshitgit.com.

Katie: Yes. Yeah. It was—

Corey: Which is amazing.

Katie: Thank you. Yeah, it was shortly thereafter. I think the ideas were kind of starting to percolate at that conference. Because you know—yeah I was—

Corey: Because someone gave a talk about Git. Oh, I’m absolutely stealing credit for your work.

Katie: No, Corey—

Corey: “Oh, yeah. You know, that was my idea.”

Katie: [laugh].

Corey: Five years from now, I’m going to call myself the founder of it, and you’re just on the implementation details.

Katie: I don’t—nonononono—

Corey: That’s right. I’m going to D.C. Bro my way through all of this.

Katie: [laugh]. No, no, no, no. See, my recollection is that my talk about being a team player and a frontend expert with a T-shape happened at exactly the same time as your talk about Git because I remember I wanted to go watch your talk because at the time, I absolutely hated Git. I was still kind of learning it. So yeah, so I don’t think you really get any credit because I have never actually heard that talk that you gave. [laugh].

Corey: A likely story.

Katie: [laugh]. However, however, I will say—so, before I was up to give my talk, the emcee of the conference was teasing me, you know, in a very good-natured ribbing sort of way, he was teasing me about my blog being totally empty and having absolutely nothing in it. And I got on the plane home from Zurich, and I was starting to think, “Oh, okay. What are some things that I could blog about? What do I have to say that would be at all interesting or new to anyone else?”

And like I think a lot of people do, I had a really hard time figuring out, okay, what can I say that’s, maybe, different? And, I went back home, I went back to work, and at one point, I had this idea, I had this file that I had been keeping ever since I started learning Git and I call it, like, gitshit.txt. And hopefully, your listeners don’t mind lots of swears because I’m probably going to swear quite a bit.

Corey: No, no. I do want to point out, you’re accessible to all folks: dangitgit.com, also works but doesn’t have the internal rhyming mechanism which makes it, obviously, nowhere near where it needs to be.

Katie: [laugh]. Well—

Corey: It’s sort of a Subversion to Git if you will.

Katie: Yes, exactly.

Corey: I—Subversion fans, don’t yell at me.

Katie: [laugh]. Anyways, so I remember I tweeted something like, “Oh, what about if I took this text file that I had,” where every time I got into a Git mess, I would go on to Stack Overflow—as you do—and I would Google and I—it was so hard. I couldn’t find the words to find the answers to what I was trying to fix. Because one of the big problems with Git that we can talk about it a bit more in detail later is that Git doesn’t describe workflows, Git describes internal plumbing commands and everything that it exposes in its API. So, I had a really hard time with it; I had a hard time learning it.

And, you know, what I said, “Okay, well, maybe if I published on my blog about these Git tips that I had saved for myself.” And I remember I tweeted, and I got a handful of likes on the tweet, including from Eric Meyer, who is one of my big idols in the frontend world. He’s one of the godfathers of modern CSS. And he liked my tweet, and I was like, “Oh, okay. Maybe this is a real thing. Maybe people will actually find this interesting.”

And then I had this brilliant idea for this URL, ohshitgit.com, and it was available, and I bought it. And I swear to you, I think I spent two hours writing some HTML around my text file and publishing it up to my server. And I tweeted about it, and then I went to bed.

And I kind of expected maybe half a dozen of my coworkers would get a little sensible chuckle out of it, and like, that would be the end of it. But I woke up the next morning and my Twitter had blown up; I was on the front page of Hacker News. I had coworkers pinging me being like, “Oh, my God, Katie, you’re on Hacker News. This is insane.” And—

Corey: Wait, wait, for a good thing, or the horrifying kind of thing because, Hacker News?

Katie: Well, [laugh] as I have discovered with Hacker News, whenever my site ends up on Hacker News, the response is generally, like, a mix of, “Ha ha ha, this is great. This is funny,” and, “Oh, my God, somebody actually doesn’t understand Git and needs this. Wow, people are really stupid.” Which I fundamentally disagree with and I’m sure that you fundamentally [laugh] disagree with as well.

Corey: Oh, absolutely.

Katie: Yeah. So—

Corey: It’s one of those, “Oh, Git confuses you. You know what that means? It means you’re human.” It confuses everyone. The only question is, at what point does it escape your fragile mortal understanding? And if you are listening to this and you don’t believe me, great. I’m easy to find, I will absolutely have that discussion with you in public because I promise, one of us is going to learn something.

Katie: [laugh]. Awesome. I love—I hope that people take you up on that because—

Corey: Oh, that would be an amazing live stream, wouldn’t it?

Katie: It would. It would because Git is one of those things that I think that people who don’t understand it, look at it and think, “Gosh, you know, I must be stupid,” or, “I must not be cut out to be a developer,” or, “I must not know what I’m doing.” And I know that this is how people feel because that’s exactly how I felt myself, even when I made ohshitgit.com, that became this big reference that everybody looks at to help them with Git, like, I still didn’t understand it. I didn’t get Git at all.

And since then, I’ve kind of been forced because people started asking me all these questions, and, “Well, what about this? What about that?” And I was just like, “Uh… I don’t know. Uh…” and I didn’t like that feeling, so I did what, you know, obviously, anyone would do in my situation and I sent out a proposal to give a talk about Git at a conference. [laugh].

And what that did is when my talk got accepted, I had to then go off and actually learn Git and understand how it works so that I could go and teach it to other people at this conference. But it ended up being great, I think because I found a lot of really awesome books. There’s A Book Apart book called Git for Humans, which is incredibly good. There’s a couple of websites like learngitbranching.com.

There’s a bunch more that I can’t think of off the top of my head. But I went out and I sort of slowly but surely developed this mental model, internally, of how Git works. And I’m a visual thinker and I’m a visual learner, and so it’s a very visual model. And for what it’s worth, I think that was my biggest problem with Git was, like, I came from Microsoft .NET environment before that, and we used a program called TFS, Team Foundation Server, which is basically like a SVN or a CVS type source control system that was completely integrated into Visual Studio.

So, it was completely visual; you could see everything happening in your IDE as you were doing it. And then making this switch to the command line, I just could not figure it out until I had this visual mental model. So yeah, so ever since then I’ve just been going around and trying to teach people about Git and teach people this visual mental model that I’ve developed, and the tips and the tricks that I’ve learned for navigating Git especially on the command line. And I give talks, I do full-day training workshops, I do training workshops at work. And it’s become my thing now, which is flabbergasting [laugh] because I never intended [laugh] for—I didn’t set out to go and be this Git expert or to be, quote-unquote, “Famous” for a given value of famous, for knowing stuff about Git. I’m a frontend engineer. There’s still a piece of me that looks at it, and is like, “How on earth did this even happen to me?” So, yeah, I don’t know. So, that’s my Oh shit, Git!?! story. And now—

Corey: It’s a great one. It’s—

Katie: Thank you.

Corey: Git is one of those weird things where the honest truth of were, “Terrible Ideas in Git”—my talk—came from was that I kept trying and failing to understand Git, and I realized, “How do I fix this? I know. I will give a talk about something.” That is what we know as a forcing function. If I’m not quite ready, they will not move the conference. I know because I checked.

Katie: Yep. [laugh]

Corey: And one in Zurich was not the first time I’d given it, but it was very clearly something that everyone had problems with. The first version of that talk would have absolutely killed it, if I’d been able to give it to the core Git maintainers. And all, you know, seven of those people would have absolutely loved it, and everyone else would have been incredibly confused. So, I took the opposite tack and said, “All right. How do I expand this to as broad an audience as possible?”

And in one of the times I gave it, I said, “Look, I want to make sure it is accessible to everyone, not just people who are super deep into the weeds but also be able to explain Git to my mother.” And unlike virtually every other time where that, “Let me explain something to my mom.” And that is basically coded ageism and sexism built into one. In that case, it was because my mother was sitting in the front row and does not understand what Git is. And she got part of the talk and then did the supportive mother thing of, and as for the rest of it. “Oh, you’re so well-spoken. You’re so funny. And people seem to love it.” Like, “Did you enjoy my discussion of rebases?”

Katie: [laugh].

Corey: She says, “Just so good at talking. So, good.” And it was yeah.

Katie: [laugh]. Oh, yeah. No, I, I—totally—I understand that. There’s this book that I picked up when I was doing all of this research, and I’m looking over at my bookshelf, it’s called Version Control with Git. It’s an O’Reilly book.

And if I remember correctly, it was written by somebody who actually worked at Git. And the way that they started to describe how Git works to people was, they talked about all kinds of deep internals of Unix, and correlated these pieces of the deep internals of Git to these deep Unix internals, which, at the time, makes sense because Git came out of the Unix kernel project as their source control methodology, but, like, really? Like, [laugh] this book, it says at the beginning, that it’s supposed to teach people who are new to Git about how to use it. And it’s like, well, the first assumption that they make is that you understand the 15 years’ worth of history of the Linux kernel project and how Linux works under the hood. And it’s like, you’ve got to be absolutely kidding me that this is how anyone could think, “Oh, this is the right way to teach people Git.”

I mean, it’s great now, going back in and rereading that book more recently, now that I’ve already got that understanding of how it works under the hood. This is giving me all of this detail, but for a new person or beginner, it’s absolutely the wrong way to approach teaching Git.

Corey: When I first sat down to learn Git myself it was in 2008, 2009, Scott Chacon from GitHub at the time wound up doing a multi-day training at the company I worked at the time. And it was very challenging. I’m not saying that he was a bad teacher by any stretch of the imagination, but back in those days, Git was a lot less user-friendly—[laugh] not that it’s tremendously good at it now—and people didn’t understand how to talk about it, how to teach it, et cetera. You go to GitHub or GitLab or any of the other sites that do this stuff, and there’s a 15-step intro that you can learn in 15 minutes and someone who has never used Git before now knows the basics and is not likely to completely shatter things. They’ve gotten the minimum viable knowledge to get started down to a very repeatable, very robust thing. And that is no small feat. Teaching people effectively is super hard.

Katie: It really is. And I totally agree with you that if you go to these providers that they’ve invested in improving the user experience and making things easier to learn. But I think there’s still this problem of what happens when everything goes wrong? What happens if you make a mistake, or what happens if you commit a file on the wrong branch? Or what happens if you make a commit but you forgot to add one of the files you wanted to put in the commit?

Or what happens if you want to undo something that you did in a previous commit? And I think these are things that are still really, for some reason, not well understood. And I think that’s kind of why Oh Shit, Git!?! has fallen into this little niche corner of the Git world is because the focus is really like, “Oh, shit. I just made a mistake and I don’t know what to do, and I don’t know what terminology to even Google for to help me figure out how to fix this problem.” And I’ve come out and put these very simple, like, here: step one, step two, step three.

And people might disagree or argue [laugh] with some of the commands and some of the orders, but really, the focus is, like, people have this idea in their head, I think, particularly at their jobs, that Git is this big, important thing and if you screw up, you can’t fix it. When really a lot of helping people to become more familiar and comfortable with Git is about ensuring them that no, no, no, the whole point of Git is that just about everything can be undone, and just about everything is fixable, and here’s how you do it. So, I still think that we have a long way to go when it comes to teaching Git.

Corey: I would agree wholeheartedly. And I think that most people are not thinking about this from a position of educators, they’re thinking about it from the position of engineering, and it’s a weird combination of the two. You’re not going to generally find someone who has no engineering experience to be able to explain things in a context that resonates with the people who will need to apply it. And on the other side, you’re not going to find that engineers are great at explaining things without having specific experience in that space. There are exceptions, and they are incredibly rare and extremely valuable as a result. The ability to explain complex things simply is a gift.

Katie: It really is.

Corey: It’s also a skill and you can get better at it, but a lot of folks just seem to never put the work in in the first place.

Katie: Well, you know, it’s quote-unquote, “soft skills.” So [laugh].

Corey: Oh, God. They’re hard as hell, so it’s a terrible name.

Katie: [laugh]. Yeah. Though I could not agree more, I think something that I really look at as a trait of a super senior engineer is that they are somebody who has intentionally worked on and practiced developing that skill of taking something that’s a really complex technical concept, and understanding your audience, and having some empathy to put yourself in the shoes of your audience and figure out okay, how do I break this down and explain it to someone who maybe doesn’t have all the context that I do? Because when you think about it, if you’re working at a big company, and you’re an engineer, and you want to, like, do the new hotness, cool thing, and you want to make Kubernetes the thing or whatever other buzzword term you want to use, in order to get that prioritized and on a team’s backlog, you have to turn around and explain to a product person why it’s important for product reasons, or what benefits is this going to bring to the organization as far as scalability, and reliability. And you have to be able to put yourself in the shoes of someone whose goals are totally different than yours.

Like, product people’s goals are all around timelines, they’re around costs, they’re around things short-term versus long-term improvements. And if you can’t put yourself into the shoes of that person, and figure out how to explain your cool hot tech thing to them, then you’re never going to get your project off the ground. No one’s ever going to approve it, nobody’s going to give budget, nobody’s going to put it in a team’s backlog unless you have that skill.

Corey: That’s the hard part is that people tend to view advancement as an individual contributor or engineer purely through a lens of technical ability. And it’s not. The higher you rise, the more your job involves talking to people, and the less it involves writing code in almost every case.

Katie: One hundred percent. That’s absolutely been my experience as an architect is that, gosh, I almost never write code these days. My entire job is basically writing docs, talking to people, meeting with people, trying to figure out, where, what is the left hand doing and what is the right hand doing so I can somehow create a bridge between them. You know, I’m trying to influence teams, and their approach, and the way that they think about writing software. And, yes there is a foundation of technical ability that has to be there.

You have to have that knowledge and that experience, but at this point, it’s like, my God—you know, I write more SQL as a frontend architect that I write HTML, or CSS, or JavaScript because I’m doing data analysis and [laugh] I’m doing—I’m trying to figure out what does the numbers tell us about the right thing to choose or the right way to go, or where are we having issues? And, yeah, I think that people’s perceptions and the reality don’t always match up when it comes to looking at the senior IC technical track.

Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking databases, observability, management, and security.

And - let me be clear here - it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build.

With Always Free you can do things like run small scale applications, or do proof of concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free. No asterisk. Start now. Visit https://snark.cloud/oci-free that's https://snark.cloud/oci-free.

Corey: At some level, you hear people talking about wanting to get promoted, and what they’re really saying—and it doesn’t seem that they realize this—is, “I love what I do, so I’m really trying to get promoted so I can do less of what I love and a lot more of things I hate.”

Katie: [laugh]. Yes. Yeah. Yeah. [laugh]. In some ways, in some ways, I think that you’ve got to kind of learn to accept it. And there are some people, I think that once you get past the senior engineer, or maybe even the staff engineer, maybe they don’t even want to go there because they don’t want to do the kind of sales pitch, people person, data numbers pitching, trying to get people to agree with you on the right way forward is really hard, and I don’t think it’s for everyone. But I love it. [laugh]. I absolutely love it. It’s been great for me. And I feel like it really—it plays to my strengths in a lot of ways.

Corey: What I always found that worked for me, as far as getting folks on board with my vision of the world is, first, I feel like I have to grab their attention, and my way is humor. With the Git talk, I have to say giving that talk a few times made me pretty confident in it. And then I was invited to the frontend conference. And in hindsight, I really, really should have seen this coming, but I’m there, I’m speaking in the afternoon, I’m watching the morning talks, and the slides are all gorgeous.

Katie: Yes. [laugh].

Corey: And then looking at my own, and they are dogshit. Because this was before I had the sense to hire a designer to help with these things. It was effectively black Helvetica text on a white background. And I figured, “All right, this is a problem. I only have a few hours to go, what do I do?”

And my answer was, “Well, I’m not going to suddenly become an amazing designer in the four hours I have.” So, I changed some of the text to Comic Sans because if you’re doing something bad, do it worse, and then make it look intentional. It was a weird experience, and it was a successful talk in that no one knew what the hell to make of what I was doing. And it really got me thinking that this was the first time I’d spoken to an audience who was frontend, and it reminded me that the DevOps problems that I normally talked about, were usually fairly restricted to DevOps. But the things that everyone touches, like Git, for example, start to be things that resonate and break down walls and silos better than a given conference ever can. But talking instead about shared pain and shared frustrations.

Katie: Yes. Yes. Everyone likes to know that they are not alone in the world, particularly folks who are maybe underrepresented minorities in tech and who are afraid to speak up and say, “Oh, I don’t understand.” Or, “That doesn’t make any sense to me,” because they’re worried that they’re already being taken not as seriously as their white, male counterparts. And I feel like something I really try to lean into as a very senior woman in a very male-dominated field is if I don’t understand something, or if I have a question, or something doesn’t make sense is I try to raise my hand and ask those questions and say, out loud, “Okay, I don’t get this.”

Because I can’t even tell you, Corey, the number of times I’ve had somebody reach out to me after a meeting and say, “Thank you. I didn’t understand it either.” Or, “I thought maybe I just didn’t understand the problem space, or maybe I just wasn’t smart enough to understand their explanation.” And having somebody who’s very senior who folks look up to, to be able to say, “Wait a minute, this doesn’t make sense.” Or, you know, I don’t understand that explanation.

Can you explain it a different way? It’s so powerful and it unblocks people and it gives them this confidence that, hey, if that person up on stage, or leading this meeting, or writing this blog post doesn’t get this either, maybe I’m not so stupid, or maybe I do deserve to be in this industry, or maybe it’s not just me. And I really hope that more and more people can feel empowered to do that in their daily lives more. I think that’s been something that has been a tremendous learning through all of this experience with Oh shit, Git!?!

For me is the number of people that come up to me after conference talks, or tweet me, or send me a message, just saying, “Thank you. I thought I was alone. I thought I was the only one that didn’t get this.” And knowing that not just am I not the only one, but that people are universally frustrated, and universally Git makes them want to swear all the time, I mean, that’s the best compliments that I get is when folks come up to me and say, “Thank you, I thought I was alone.”

Corey: That’s one of the things that I find that is simultaneously the most encouraging and also the most galling. Every once in a while I will have some company reach out to me—over a Twitter thread or something—where I’m going through their product from a naive user perspective of, like, I’m not coming at this with 15 years of experience and instinct that feed into how I approach this, but instead the, I actually haven’t used this product before. I’m not going to jump ahead and make assumptions that tend to be right. I’m going to follow the predictable user path flow. And they are very often times where, “Okay. I’m hitting something. I don’t understand this. Why is it like this? This is not good.”

And usually, companies are appreciative when I do stuff like that, but every once in a while, I’ll get some dingus who will come in, and like, “I didn’t appreciate the fact that you end up intentionally misinterpreting what we’re saying.” And that’s basically license for me to take the gloves off and say, “No, this was not me being intentionally dumb. Sure, I didn’t apply a whole bunch of outside resources I could have to this, but it wasn’t me intentionally failing to get the point. I did not understand this, and you’re coming back to me now reinforces that you are too close to the problem. And, on some level, when your actual customers have problems with this, they are hearing an element of contempt from you.”

Katie: Totally.

Corey: “This is an opportunity to fix it and make it more approachable because spoiler, not a lot of people love paying money to something that makes them feel stupid.”

Katie: [laugh]. See, Corey, I don’t know. You say that you’re not really a frontend person, but that is a very strong UX mindset. Like that—

Corey: Oh, my frontend stuff is actually pretty awesome because as soon as I have to do something that even borders on frontend, I have the insight and I guess, willingness to do the smart thing, which is to immediately stop talking and pay someone who knows what they’re doing.

Katie: [laugh]. Thank you. On behalf of all frontend engineers everywhere, I applaud that, and I appreciate it.

Corey: It comes down to specialty. I mean, again, it would also be sort of weird from my perspective, which is my entire corporate position is I fix the horrifying AWS bill. So, if you’re struggling with the bill in various capacities, first, join basically everyone, but two, you’re not alone so maybe hire someone who is an expert in this specific thing to come in and help you with it. And wouldn’t it be a little hypocritical of me to go in and say, “Oh, yeah, but I’m just going to YOLO my way through this nonsense?”

Katie: Mm-hm. [laugh]. Yeah, [laugh] I don’t know we’ll want to include this in the final recording, but I have a really hilarious story, actually, about Amazon. So—

Corey: Oh, please. They listen to this and they love customer feedback.

Katie: [laugh].

Corey: I’m not being sarcastic. I’m very sincere here.

Katie: Well, this is many, many, many years ago. I mean, probably, oh, gosh, this is probably eight years ago at this point. I was interviewing for a job at Amazon. It was a job to be a frontend engineer on the homepage team, which at the time, I was like, “Oh, my God, this is Amazon. This is such an honor. I’m so excited.”

Corey: And you look at amazon.com’s front page, and it’s, “Oh, I can fix this. There’s so much to fix here.”

Katie: Yes.

Corey: And then reality catches up if I might not be the first person in the world to have made that observation.

Katie: [laugh].

Corey: What’s—

Katie: Well—

Corey: Going on in there?

Katie: Yeah. Well, I’ll tell you what’s going on. So, I think I did five different phone interviews. You know, before they invite you out to Seattle, there’s—and again, this was eight years ago, so this was well before everyone was working at home. And in those five hours of phone interviews, I want you to make a guess at how many minutes we spent talking about HTML, CSS, and JavaScript.

Corey: I am so unfamiliar with the frontend world, I don’t know what the right answer is for an interview, but it’s either going to be all the time or none of it, based on the way you’re framing it.

Katie: Yes. [laugh]. It was basically, like, half an hour. So, when you are a frontend engineer, your job is to write HTML, CSS, and JavaScript. And in five hours, I talked about that for probably half an hour.

It was one small question and one small discussion, and all the rest of the time was algorithms, and data structures, and big O notation, and oh, gosh, I think they even did the whole, like, “I typed something into my browser, tell me what happens after I type a URL into my browser.” And I think that just told [laugh] me everything that I needed to know about how Amazon approached the frontend and why their website was such a hot mess was because they weren’t actually hiring anyone with real frontend skills to work on the frontend. They were hiring backend people who probably—not to say that they weren’t capable or didn’t care, but I don’t know. That’s my favorite Amazon story that I have is trying to go work there, and they basically were like, “Yes, we want a frontend engineer.” And then they didn’t actually ask about any frontend engineering skill sets in the job. They didn’t offer me anyth—I don’t think I got invited to go to Seattle, but I probably wouldn’t have anyways.

Corey: No. Having done it a couple of times now, again, I like the people I meet at Amazon very, very much. I want to be very clear on that. But some of their processes on the other hand, oh, my God. It shows that being a big company is clearly not necessarily a signal that you solved all of these problems. In some cases, you’re basically just crashing through the problem space by sheer power of inertia.

Katie: Yeah, definitely. I think you can see that when looking at their frontend. Harkening back a little bit to what we were talking about earlier is you don’t go to Amazon and learn patterns of interaction that are applicable to every single site on the web. Amazon kind of expects that users are going to learn the Amazon way of shopping and that users are going to adjust how they navigate the web in order to accommodate Amazon. You know, people learn, “Oh, this is what I do on Amazon.” And then, you know, they’re—

Corey: Oh, that’s the biggest problem with bad user experience is people feel dumb.

Katie: Mm-hm.

Corey: They don’t think, “This company sucks at this thing.” They think, “I must not get it.” And I know this, and I am subject to it. I run into this problem all the time myself.

Katie: Oh, yes.

Corey: And that is a problem.

Katie: Yeah. It’s why I think, like you said earlier, it’s so important when you work somewhere to figure out how do you get that distance between being a power user enough so that you can understand and appreciate what it’s like for a regular user who’s not a power user of your site. And what do they do? And UX researchers are amazing. A good UX researcher is worth absolutely their weight in gold because, I don’t know if you’ve ever sat in on a UX session where the researcher is walking a user through completing a specific task on a website, but oh my God, it’s painful.

It’s because [laugh] you just want to, you want to push them in the right direction, and you want to be like, “Oh, but what about in the upper right over there, that big orange button,” and you can’t do that. You can’t push people. You have to be very open-ended, you have to ask them questions. And every single time I’ve listened in on a UX research recording, or a call, I want to scream through the computer and be like, “Oh, my gosh. This is how you do it.”

But, you know, you can’t do that. So, [laugh] I think it’s important to try to develop that kind of skill set on your own of, “Okay, if I didn’t stare at this website every day, what would it be like for me to try to navigate? If I was using a keyboard for navigation or a screen reader instead of a mouse, what would my experience be like?” Having that empathy, and that ability to get outside of yourself is just really important to be a successful engineer on the web, I think.

Corey: Yeah. And you really wish, on some level, that they would be able to articulate this as an industry. And I say ‘they,’ I guess I’m speaking of about three companies in particular. I have a lot more sympathy for a small startup that is having problems with UX than I am for enormous companies who can basically hurl all the money at it. And maybe that’s unfair, but I feel like, at some point of market dominance, it is beholden on you to set the shining example for how these things are going to work.

I don’t feel that way, necessarily about architecture on the backend. Sure, it can be a dangerous, scary tire fire, but that’s not something your customers or users need to think about or worry about, as long as it is up from their perspective. UX is very much the opposite of that.

Katie: Totally. And I think, working at a former startup, there’s a tendency to really focus a lot on those backend problems. You know, you really look at, “Okay, we’re going to nitpick every single RPC request. We’re going to have all kinds of logging and monitoring about, okay, this is the time that it takes for a database API request to return.” And just the slightest movement and people freak out.

But it’s been a process that I’ve been working really hard on the last couple of years, to get folks to have that same kind of care and attention to the stuff that they ship to the frontend, especially for a lot of organizations that really focus on, “Well, we’re a tech company,” it’s easy to get into this, oh, engineering is all of these big hard systems problems, when really your customers don’t care about all of that. Yes, ultimately, it does affect them because if your database calls are really, really slow, then it has an effect on how quickly the user gets a response back and we know that slow-performing websites, folks are more likely to abandon them. Not that it doesn’t matter completely, but personally, I would really love it to see more universally around the industry that frontend is seen as this is the entirety of your product and if you get that wrong, then none of the rest of your architecture, or your infrastructure, or how great your DevOps is matters because you need customers to come to your site and buy things.

Corey: It turns out that the relationship between customers coming to your site and buying things and the salaries engineering likes to command is sometimes attenuated in ways that potentially shouldn’t be. These are interesting times, and it does help to remember the larger context of the work we do, but honestly, at some point, you wind up thinking about that all the time, and not the thing that you’re brought in specifically to fix. These are weird times.

Katie: Yes.

Corey: Katie, thank you so much for taking the time to speak with me about several things. Usually—it’s weird. Normally, when someone says thank you for speaking to me about Git, there is no way that isn’t a sarcastic—

Katie: [laugh].

Corey: —statement. But in this case, it is in fact genuine.

Katie: Yes, I will bitch about Git until I am blue on the face, so I appreciate you having me on board to talk about it, Corey. Thank you.

Corey: Of course. If people want to learn more, where can they find you?

Katie: They can find me at ohshitgit.com, or as you pointed out, the dangitgit.com swear-free version. As a little plug for the site, we now have had the site translated by volunteers in the community into 28 different languages. So, if English is not your first language, there’s a really good chance you’ll find a version of OSG—as I like to call it—that is in your language.

Corey: Terrific. And we will, of course, put links to these wonderful things in the [show notes 00:39:16]. Thank you so much for taking the time to speak with me. I really appreciate it.

Katie: Thank you, Corey. It’s been lovely to reconnect, and gosh, look at where we are now compared to where we were almost five years ago.

Corey: I know. It’s amazing how the world works.

Katie: Really.

Corey: Katie Sylor-Miller, frontend architect at Etsy. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star 
review on your podcast platform of choice along with a comment written in what is clearly your preferred user interface: raw XML.

Katie: [laugh].

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

This has been a HumblePod production. Stay humble.