Screaming in the Cloud - Gitting After It with Katie Sylor-Miller

Episode Date: September 14, 2021

About KatieKatie 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.Links:Etsy: https://www.etsy.com/Design Systems Handbook: https://www.designbetter.co/design-systems-handbookBook of staff engineering stories: https://www.amazon.com/dp/B08RMSHYGGstaffeng.com: https://staffeng.comohshitgit.com: https://ohshitgit.comdangitgit.com: https://dangitgit.com

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. This episode is sponsored in part by Thinkst Canary. This might take a little bit 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, or anything else like that, that you can generate in various parts of your environment, wherever you want them to live. It gives you fake AWS API credentials, for example. And the only thing that these are empowered to do is alert you whenever someone attempts to use them. It's an awesome approach to detecting breaches. I've used something similar for years myself before I found them. Check them out. But wait, there's more because they also have an enterprise option that you should be very much aware of. Canary.tools. Take a look at this. What it does is provides an

enterprise approach to drive these things throughout your entire environment and manage them centrally. You can even get a physical device that hangs out on your network and impersonates whatever you want it to. Whenever it gets NMAP scanned or someone attempts to log into it or access files that it presents on a fake file store, you get instant alerts. It's awesome. If you don't do something like this, instead, you're likely to find out you've gotten breached the very hard way. So check it out. It's one of those few things that I can look at and say, this is an amazing idea. I am so glad I found them. I love it. Again, those URLs are canarytokens.org and canary.tools. And the first one's free because of course it is. The second one is enterprising. You'll know which one of those you fall into. Take a look. I'm a big fan. More to come from Thinkst Canary in the weeks ahead.

This episode is sponsored in part by our friends at Jellyfish. So, you're sitting in your office chair, bleary-eyed, parked in front of a PowerPoint, and oh, my sweet feathery Jesus, it's 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 insight 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. And 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. That's jellyfish.co and tell them Corey sent you. Watch for the wince. That's my favorite part. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Katie Seiler-Miller, who's a front-end architect at Etsy. Katie, thank you for joining me. Hi, Corey. Thanks for having me. 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 front-end architect at Etsy,

you're a co-author of the Design Systems Handbook, and you were recently interviewed and included in Will Larson's book of staff engineering stories that people are mostly familiar with at staffeng.com. Yeah. 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 Front End Conference in Zurich. Yes, before either of us were known for anything.

Exactly. And it was, oh, great. I wound up getting invited to speak at a Front End Conference, and my response was, okay, Zurich sounds lovely. I'm thrilled to do it. Do you understand who you're asking? There are front-end 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 back-end folks who write the API side of things and what the deep lifting do. And, oh, that's the way of the future.

And people look at me and they think, oh, you're a backend person, if they're frontend. If they're backend, they look at me and think, oh, you're a DevOps person. Great. 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 front-end conference. And the reason that they invited me at all, it 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. Yes. 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, which is amazing. 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... Because someone gave a talk about Git. Oh, I'm absolutely stealing credit for your work. Oh, yeah, you know,

that was my idea. Five years from now, I'm going to call myself the founder of it, and you're just on the implementation detail. That's right. I'm going to VC bro my way through all of this. No, no, no, no, no, no. My recollection is that my talk about being a team player and a front-end 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. A likely story. 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 like, oh, okay, you know, 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, 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 called it like gitshit.txt and hopefully your listeners don't mind lots of swears because I'm probably gonna swear quite a bit no no it's true 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 well it's sort of a subversion to get if if you will. Yes, exactly. Subversion fans, don't yell at me.

Anyways, so I remember I tweeted something like, oh, you know, what about if I took this text file that I had where, you know, every time I got into a Git mess, I would go onto Stack Overflow, as you do, and I would Google. And it was so hard. I couldn't find the words to find the answer to what I was trying to fix. Because one of the big problems with Git that we can talk about in 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, and I said, okay, well, maybe if I publish on my blog about these Git tips that I had saved for myself. And I remember I tweeted and, you know, I got a handful of likes on the tweet, including from Eric Meyer, who is one of my like big idols in the front end world. He's one of like 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 like maybe half a dozen of my co-workers 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 I, my Twitter had blown up. I was on the front page of Hacker News. I had co-workers pinging me being like, oh my God, Katie, you're on Hacker News. Like, this is insane. Wait, wait, for a good thing or the horrifying kind of thing? Because Hacker News. Well, 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 disagree with as well. Oh, absolutely. It's one of those, oh, it 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.

Awesome. I love, I hope that people take you up on that. Oh, that'd be an amazing live stream, wouldn't it? 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 and what about that? And I was just like,

I don't know. 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. 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. Like, 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, you know, that I can't think of off the top of my head. But, you know, I went out and I sort of slowly but surely developed this mental model internally of how Git works. And, you know, 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 like a SVN or a CVS type source control system that was completely integrated into Visual Studio. So it was completely, you know, visual. Like 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 kind of 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, you know, I give talks, I do full day training workshops, I do training workshops at work. And it's kind of become my thing now, which is like flabbergasting because I never intended for, you know, I didn't set out to go and be this like Git expert or to be quote unquote famous for a given value of famous for knowing stuff about Git. Like I'm a front end 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 I don't know. So that's my OSHA Git story. And now- It's a great one. Thank you. Git is one of those weird things where the honest truth of where terrible ideas in Git,

my talk, came from, was that I had 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. And the 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 this is accessible to everyone, not just people who are super deep into the weeds, but also be able to explain, get to my mother. And unlike virtually every other time where that, let me explain something 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? She's just so good at talking, so good. And it was, yeah. Oh, yeah. No, I totally, I understand that. Like, 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, 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 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 sort of 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 a beginner, it's absolutely the wrong way to approach teaching Git.

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 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, 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. 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 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, you know, 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, you know, I've come out and put these very, like, very simple, like here, step one, step two, step three, and people might disagree or argue 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, you know? So I still think that we have a long way to go when it comes to teaching Git. 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. It really is. 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. Well, you know, it's quote unquote soft skills. So they're hard as hell.

So it's a terrible name. Yeah, no, I could not agree more. 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, of taking something that's a really complex technical concept and understanding your audience and, you know, having some empathy to put yourself in the shoes of, 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, you know, 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 like scalability and reliability? And you have to be able to put yourself in the shoes of someone whose goals are like totally different than yours. You know, like product people's goals are all around timelines. They're around costs.

They're around things like 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 you budget. Nobody's going to put it in a team's backlog unless you have that skill. 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. 100%. 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, okay, 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 kind of has to be there. Like, 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 front-end architect than I write HTML or CSS or JavaScript because I'm doing data analysis and I'm doing, you know, 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, it's, 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. 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 asterisk next to the word free. This is actually free, no asterisk.

Start now. Visit snark.cloud slash oci-free. That's snark.cloud slash oci-free. On some level, you hear people talking about wanting to get promoted. And what they're really saying, and it doesn't seem like 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. Yes. Yeah. Yeah. And in some ways, in some ways, I think that, you know, you've got to kind of

learn to accept it. And there are some people, I think that once you get past the, the like 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. 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. 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 front end 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. Yes. And I'm looking at my own, and they are dog shit, 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 Sense, because if you're doing something bad, do it worse and then make it look intentional. Like 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 front end. 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. Yes. Yes. Everyone likes to know that they are not alone in the world, particularly folks who are, you know, maybe underrepresented minorities in tech and who are afraid to speak up and say, oh, you know, 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, you know, 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. You know, 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? Like, it's so powerful and it unblocks people and it gives them this confidence that like, 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 as 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 OSHA Get 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, you know, not just am I not the only one, but that people are like universally frustrated and universally get 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. 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 there 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 how the fact that you wound up intentionally misinterpreting what we're saying. And that's basically licensed 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 your 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. 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.

See, Corey, I don't know. You say that you're not really a front-end person, but that is a very strong UX mindset. My front-end stuff is actually pretty awesome because as soon as I have to do something that even borders on front-end, 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. Well, thank you. On behalf of all front-end engineers everywhere, I applaud that and I appreciate it. 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 gonna YOLO my way through this nonsense. Mm-hmm. Yeah, I don't know if we'll want to include this in the final recording, but I have a really hilarious story actually about Amazon. So. Oh, please. They listen to this and they love customer feedback. I'm not being sarcastic. I'm being very sincere here. Well, this was many, many, many years ago. I mean, probably, oh gosh, this was probably eight years ago at this point. I was interviewing for a job at Amazon. It was a job to be a front-end engineer on the homepage team, which at the time I was like, oh my God, this is Amazon. This is front page and it's, oh, I can fix this. There's so much to fix here.

Yes. And then reality catches up of, I might not be the first person in the world to have made that observation. What's going on in there? Yeah, well, I'll tell you what's going on. So I think I did five different phone interviews before they invite you out to Seattle. 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.

I am so unfamiliar with the front-end 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 the time, based upon the way you're framing that. It was basically like half an hour. So when you are a front-end 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 type something into my browser tell me what happens after I type a url into my browser. And I think that just told me everything that I needed to know about how Amazon approached the front end and why their website was such a hot mess was, you know, because they weren't actually hiring anyone with real front end skills to work on the front end.

They were hiring back end 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 front-end engineer. And then they didn't actually ask about any front-end engineering skill sets in the job. They didn't offer me any. I don't think I got invited to go to Seattle, but I probably wouldn't have anyways. 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. Yeah, definitely. I think you can see that when looking at their front end. Harkening back a little bit to what we were talking about

earlier is like, you don't go to Amazon and learn patterns of interaction that are applicable to every single site on the web. You know, 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. People learn, oh, this is what I do on Amazon, and then... Oh, that's the biggest problem with bad user experience is people feel dumb. They don't think this company sucks at this thing. They think, I must not get it. And I know this, and I'm subject to it.

I run into this problem all the time myself. Oh, yes. And that is a problem. 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. Like a good UX researcher is worth absolutely their weight in gold because I don't know if you've ever sat in on like 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 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 know, 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, like, recording or a call, I want to scream, like, through the computer and be like, oh my gosh, this is how you do it. But, you know, you can't do that. So I think it's important to like 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? 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. Yeah. And you'd really wish on some level that

they would be able to articulate this as an industry. And when 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 back end. 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. Totally. And I think working at a former startup,

there's a tendency to really focus a lot on those backend problems. 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 front end, especially for a lot of organizations that really focus on, well, we're a tech company. It's easy to get into this like, oh, engineering is all of these big, hard systems problems,

when really, like, 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, you know, 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 front end is seen as like, 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. 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 it 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. Yes. Katie, thank you so much for taking the time to speak with me about several things. It's weird. Normally, when someone says, thank you for speaking to me about Git, there is no way that that isn't a sarcastic statement. But in this case, it is, in fact, genuine. 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. Of course. If people want to learn more, where can they find you? 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. Terrific. And we will, of course, put links to these wonderful things in the show notes. Thank you so much for taking the time to speak with me. I really appreciate it. 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. I know. It's amazing how the world works. Really? Katie Seiler-Miller, front-end 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. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill 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 humble pod production stay humble