Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another hard-stop edition of the ShopTalk Show. I'm Dave--in the shed--Rupert and with me is Chris--in the booth--Coyier. Hey, Chris. Who do we got today?

Chris Coyier: Gosh darn right. Somebody who hasn't been in the show in a hot long time but we've been friends and acquaintances in the tech industry forever. Back from the famous yayQuery days where even YouTube was.... It's Rebecca Murphey. Hi, Rebecca.

Rebecca Murphey: Hi. [Laughter] That's right. YouTube, we posted yayQuery on Vimeo because it wasn't clear. [Laughter]

Dave: It wasn't a winner, right? There wasn't.

Rebecca: There wasn't a winner.

Dave: There was not a winner in the video space. Yeah.

Rebecca: Yeah, it's circa 2009, hand-editing and RSS files. Good times.

Dave: Wow.

Chris: That was a show like ostensibly about jQuery but really just about whatever and jokes and stuff. Wonderful. Anyway, that was always a side gig anyway. So, what's up now? What have you been doing for the rest of your life?

00:01:25

Rebecca: [Laughter] The rest of my life. Well, I'm an engineering manager of sorts at Stripe these days, so I've been at Stripe for two years almost. It'll be two years in November, and I joined there to keep up the JavaScript team. I joined to start a JavaScript infrastructure team there.

Chris: Oh, no kidding.

Rebecca: Yep, and so I built that team. You might have seen our big write-up about our migration from Flow to TypeScript. That was kind of our big two, one of our two big projects in the year that I had that team.

Chris: That's funny.

Rebecca: At the beginning of this year--

Chris: It wasn't from not typed to typed. It was just typed to just different types.

Rebecca: No, it was from typed to, like, better typed. That's another case where there was no clear winner when Stripe made that choice. Flow was--

Chris: Could have won.

Rebecca: Flow was Facebook and React is still around, so who would guess that Flow wouldn't be? Anyway, I did that for about a year. Now I'm leading a team called Engineering Success at Stripe, and it's focused on just understanding and improving the experience of doing software engineering at Stripe.

We had a lot of teams that were focused on making great tools, making those tools fast, but really no one who was focused on what it was like to use those tools altogether, like what the experience of actually writing software was. So, we have a small team getting larger that's focused on trying to understand that and help other teams realize where they could be making improvements in their tools.

Chris: Hmm. It's like developer experience developer experience.

Rebecca: Yeah. [Laughter]

00:03:00

Dave: That's... Okay. This feels like a good place to start because how do you go to your bosses who control the purse strings, and you're like, "It doesn't feel good." You know? [Laughter] Like how do--?

Oh, and they're like, "Oh, yeah. Here's a billion dollars. Go fix it," or whatever.

Rebecca: I wish. Yeah, that's exactly how it worked.

Dave: Yeah.

[Laughter]

Rebecca: Still got the check in my back pocket.

No, I mean one of the reasons that I joined Stripe is that I was excited about working with in the space of Stripe. This is not me just pruning Stripe. This is true.

One of the reasons that I joined was that every six months, we do a survey of the whole company, so engineers - the whole company. They have a really, really high response rate because people know that the answers are read and responded to.

That means that every six months, we were getting an influx of, you know, people saying they were sad at using our tools. And that they felt like they could be more productive than they were.

And so, Stripe is a low margin business, so the more -- [laughter] basically, the more we can eke out of our engineers without burning them out, the more money hopefully we can make. But we make a tiny, tiny slice of every transaction, and so we are doing well, but it is a low-margin business that means that anything -- like I said -- anything you can eke out matters.

Chris: That's funny to think about that it's low margin. I could see if you bought a wicker chair for $100 and you sold it for $105. That's low margin. But if you didn't even have to buy the chair--

Rebecca: [Laughter] Well, I mean--

Chris: Your 5% is pretty good.

Rebecca: Well, but we have stuff that we have to pay for too, like some of that goes to the credit card companies, and you've got to pay me. You know those are things.

Yes, I know that we take a fee that they prefer to complain about.

Chris: [Laughter]

Rebecca: I'm not on that side of the business, so I don't know anything about that. But yeah, as businesses go, it is a lower-margin business than many.

00:05:22

Dave: Well, and engineering is expensive. There are maybe ways you can cut costs but, in my experience, I feel like you really cut costs and you cut some quality and you cut some deadlines and things like that. But engineering just is kind of a giant cost center, so you're saying anything you can do to make it function better or more efficiently is money in the bank, as it were. Or you get an ROI, right?

Rebecca: Basically that, and so we've always done this survey twice a year. We also now do more regular surveys. We may talk about paper cuts in this, which is another thing that we do to get feedback.

Really getting the money, in this case, was easier than anywhere I've tried to get money before just because I had this body of evidence of people saying this is really hard. People writing friction logs explaining what their experience was trying to ship a feature or something like that. So, we had a lot of evidence of a problem, and it was more figuring out are we going to just put more people on the same teams that we've always had or do we need something that's looking at the whole experience. And so, it's been -- yeah.

I always like more money. I personally like more money, and I would love to hire more people. But generally, the organizational support has been incredible and really frightening levels of visibility around the work as well.

Chris: Well, what does a win look like then when you're in developer embitterment? Developer success, I guess you'd call it?

Rebecca: Developer embitterment.

Chris: Yeah.

Rebecca: And engineering success, yeah.

Chris: Yeah, okay, so there's a paper cut, or worse, or something that sucks about your job as an engineer. Then it's your job to kind of triage it or see if there's a solution to it that can - I don't know - put a band-aid on that thing?

00:07:23

Rebecca: Some stuff works that way, and that was kind of our thing for our first quarter was we get the paper cuts, so basically with paper cuts, we made it really easy for engineers to complain anywhere in their development tools. So, they can do it in Slack. They can click a button. They can type a command line. We just made it really, really easy for people to complain in our editors, everywhere.

Dave: That's a bold move, by the way. [Laughter] I know Jen Simmons will get on Twitter sometimes and just be like, "Complain about Safari." I'd just be like, "You're opening yourself up to this firehose."

Rebecca: That was exactly the plan was to get just this stream of gentle but critical feedback about our tools. It's hard to take that to the CTO or the CEO and have them not want to do something about it. It was a great way to show evidence of the problem.

The thing about paper cuts, though, is yeah, sometimes it's stupid stuff where it's like, oh, there's some CSS layout issue, for example, where this thing is covering up this thing, and I can't click on it. Those are just like we can dispose of those pretty quickly, and those are easy. But what we really found was that our real value wasn't in finding these little things. Our real value was in saying, "Oh, my gosh. Our system for managing permissions and access is really high friction for engineers."

Dave: Mm-hmm.

Rebecca: Especially in this scenario that is a very common scenario. So, we were able to kind of collect--

Because we were getting this feedback from the whole engineering organization, we were able to see things that no one else could see about what was going wrong. We could see that, "Oh ... between deploy and orchestration all the time. What's that about? Where is the confusion? How could we have a better support story?"

It really almost turned into an internal dev -- like it's turning into an internal dev rel kind of situation instead of just let me fix stuff.

Dave: Yeah.

Chris: Hmm.

Rebecca: It's really turning into -- I said I'm sort of an engineering manager. I'm also sort of a product manager, and my product is productivity at Stripe.

Dave: Yeah.

Chris: Whoa.

Dave: The only way you could have got all these friction points, especially cross-team, would be to get every engineering manager into the same room and then they all list every problem they've ever heard a developer complain about. Right?

Rebecca: And we'd rabbit hole on exactly one of those problems by halfway through the day is usually how that would go.

Dave: Yeah. Yeah. Yeah.

Chris: Oh, my God.

Rebecca: [Laughter]

Dave: Well, and then, "Who is going to pay for it? Budget. Budget." Yeah.

Rebecca: Yeah, it's been interesting how it's turned into more of almost an advocacy role, internal developer advocacy role.

Dave: And how many developers is this, if we were to quantify?

Rebecca: More than 1,000, less than 5,000.

Dave: Okay.

Rebecca: In that ballpark.

Dave: That's good for me. I was like, "It's not 12 people, right?" [Laughter]

Rebecca: It's not 12 people, and it's not Google, right?

Dave: Right. Right.

Rebecca: Yeah.

Dave: It's not 16,000 or 100,000 or something.

Rebecca: Right. Right. Yeah. it's not Google, but it's not... It is a startup, still ... nor is it a startup in terms of headcount.

Dave: You made it easy to complain, and then what did y'all do?

00:10:44

Rebecca: The minute a user complains, we also (at the same time) we're trying to make it – just kind of elevate the conversation around productivity at Stripe. So, we had been – you know we did the survey twice a year, and that was one data point that we had. And then we didn't really have other data points coming in (in the old days).

So, what would happen is that people would get really fixated on two things. Number one, a metric that updated exactly twice a year. [Laughter] And so—

Chris: Yeah. You care about what you measure. Classic thing.

Rebecca: But it only updates twice a year, so you can't – you couldn't tell if you were making any progress until you ran the survey again in six months. We also, in the absence of other more fluid numbers, we really zeroed in on activity metrics, which gets real close to counting lines of code that people are writing. We all know that is bad to count the lines of code that people are writing because I too can write a lot of lines of code if that's what you'd like me to do.

Chris: Right. But sometimes two weeks of thinking results in two lines of code, kind of thing.

Rebecca: Two lines of code, right.

Dave: Sometimes you don't want to maintain that 500-line browser sniffer. You know? Sometimes you just shouldn't have done that. You know?

Rebecca: Shouldn't have done that, maybe.

Dave: Yeah.

Rebecca: Yeah, so this is the other thing we had to kind of try and figure out how to solve was how to talk to the business about productivity because the business, at the end of the day, wants to know, "I'm spending this much money. How much value am I getting for spending this money?"

Chris: Mm-hmm.

Rebecca: If we were working on an assembly line selling airplanes or cars, that would be a plausible calculation.

Dave: Yeah.

Rebecca: But in software—

Dave: One more line, 100 more people. Done. Yeah.

00:12:56

Rebecca: Yeah, was that line good? Was it bad? Did it cause an incident? Was it a stupid feature idea that we never should have spent six months building?

We really had to explain to the business that we needed to take a more nuanced look at what was impacting productivity and with outcomes of our work. So, we looked at the SPACE framework, which is a paper from Microsoft and GitHub that lays out kind of five pillars of productivity. It's satisfaction and well-being, performance and outcomes, activity, communication and collaboration, and efficiency and flow.

Instead of just looking at how much code is coming out the end of the pipe, we started to look at do people have enough time? Are they in meeting all day? Do they have enough uninterrupted blocks of time during the day? How often are they having to rely on another team to get their code reviewed? How often are they--? How long are they waiting for API reviews or other internal review processes?

We just started to paint this fuller picture of productivity and really arrived at -- it wasn't a shocking conclusion for me, but it was a surprising conclusion for the business that tools weren't really our problem. Yes, our tools could be better. No doubt our tools could be better. But I started to hypothesize that we could drive all of the tools to 100 or zero or whatever you want to call good and we wouldn't have solved the problem. And I just kind of felt this viscerally. Just making the tools better is not going to solve this. There are cultural and gross challenges that we need to address too, you know, the ways of working and the way of thinking.

Dave: You couldn't NPM install your way out of the problem is what you're saying.

Rebecca: Yes. Yes.

Dave: Yeah.

Rebecca: That we were going to -- we couldn't write code to solve this. We could write some code and it would make things better. But if we were actually looking for a step change, we had to start talking about some bigger things.

Chris: Hmm.

Rebecca: That's been kind of the nine-month arch of this team is starting by thinking we would fix paper cuts and improve workflows. And there's still plenty to do there, but it's really become a discussion with senior leadership about what's really making it difficult for engineers to be maximumly effective.

00:15:24

Dave: Out of this was the flow to TypeScript, kind of a product of this?

Rebecca: No, so that was my last -- my previous job at Stripe, which I can also talk about. But I have other people you should have on to talk about that in technical detail. I'm just a manager. So, that was in a previous team I joined Stripe to build, the JavaScript infrastructure team, and that was--

It's really fun to have a new team because nobody expects you to do anything because nobody knows what to expects of you. [Laughter] Also, JavaScript -- there were lots of really excellent JavaScripters at Stripe. Alex Sexton is there and Andrew Lunny and TJ Fontane. Lots of excellent JavaScripters were there. But again, the business didn't really understand where JavaScript fit into the software development process and what the experience of that was like.

Really quickly, you're like... [laughter] We showed up to like 20-minute Webpack builds and 60 different versions of Flow installed in a mono repo because nobody was accountable for the experience of engineering at Stripe. And so, to big projects we did: one, introducing Metro for local development of front-end instead of Webpack, which is basically like instantaneous builds.

Dave: Hmm.

Rebecca: Then the TypeScript project, so the Webpack to Metro was about a six-month project, and then the TypeScript project. I was just talking to Andrew Lunny about it yesterday, and we wrote a doc in April of 2021 saying that it would be done in Q2 of 2022, and it was. I've never--

Chris: Damn.

Rebecca: [Laughter] I have never pulled anything off like that.

Chris: The first time ever. Where's your reward? Yeah.

Rebecca: Yeah. So, yeah, it was a huge, huge undertaking.

Chris: At least you didn't say next week. You did a year. Yeah.

Dave: I've had a couple of, like, "Oh, my timeline was right. Whoa!"

Rebecca: Wow...

Dave: Once you feel--

Chris: What does it feel like? I've never, never experienced this.

00:17:32

Rebecca: Especially on a year, this was quarters, and I got it right. I was so impressed.

Dave: Yeah. That's impressive.

Rebecca: And I shouldn't say I got it right. We got it right.

Dave: Everybody. Yeah.

Chris: So, a meta kind of thing. Stripe builds stuff for developers. It's not for your average citizen of the world to use. It's just for other developers. So, I don't know. I wonder if there's just more. If you make it great for internal developers that the fallout is closer to a better product for other people, too.

If you're an engineer at Vox Media, you still care about the experience of the developers there. But it's a little less connection because you're just making news about Apple products or whatever.

Rebecca: Yeah. I think one of the challenges of working in a space like this is that the connection to that end user can be tenuous, and especially when a group like this just starts and product engineering is kind of 80%, and you've got these Infor people off doing some stuff. You don't really understand what it is. Maybe they don't like to talk to people too much.

[Laughter]

Rebecca: It's really easy for engineering culture to center on product engineers, and it can be really easy for Infor engineers to feel actually disconnected from, like, "Why are we here?"

Dave: Mm-hmm.

Rebecca: What are we doing?"

So, I do think -- I think that the work that we are doing will have benefits to end users, but I can never draw that line. I can never actually attribute our work as the reason that there was not an incident, for example. You can imagine that the work that we do will make it easier to build more reliable software because we will improve the testing situation or whatever. That's a pretty plausible story is that we will make it possible to build more reliable software.

How do you measure reliable software? By the absence of bad things. [Laughter] And so, it's hard to make that connection but I think it's there.

00:19:57

Dave: Yeah. Our favorite Internet mad guy, Alex Russell, he feels like the DX leads to better products is a total lie.

Chris: Oh, I love this argument.

Dave: You've seen it at massive scales that I haven't. I personally am like, well, it seems to help me. It helps me. At least I'm not -- I don't have blank page syndrome, I guess, where I'm just like, "Oh, man. What would be the best way to install or create a user auth flow?" I don't do that. I try not to do that.

Rebecca: Yeah. Alex and I are friends. Alex lent me a couple hundred pounds when I lost my wallet in Brighton at the conference whose name I can't say because they changed it to ffconf. But it wasn't back then.

I like Alex as a human. I think he's super wrong and kind of disconnected from reality on this front. I think that what he's right about is that there are tradeoffs and that if you optimize only for experience and then you have the 50-meg download on your homepage, you screwed up. Definitely. I agree with that.

Dave: That's a screwup, yeah. Yeah.

Rebecca: But not every page is your homepage. Not every product is your homepage. Not every product is latency sensitive. And sometimes it's actually the right call, especially for internal tools. Sometimes it's the right call to make it easy, not just--

Will pay 100 milliseconds of latency internally on a tool. Yes, that would be nice to recover. I don't disagree. But come on. If we were able to build some valuable internal tool in two weeks instead of two months, it's a no-brainer. I think his position is very absolutist.

Dave: Sure. Sure.

Rebecca: And doesn't take into account the reality of money and people and real tradeoffs that businesses have to make. Retention too, for that matter. That's definitely part of the story of engineering success is that frustration with tools can become a retention issue.

Dave: Yeah.

Rebecca: And so, I think if you're just like, "Suck it up! Be a real engineer. Just write JavaScript," then I might go somewhere where I don't have to do that. [Laughter] I can make the same amount of money.

Chris: That's real stuff, man.

00:22:54

Dave: I've also seen (just anecdotally) quite a few developers. There seems to be a type of developer who the minute they encounter a tiny problem, they're like, "This thing is terrible." Web components or whatever, the second they're like, "Oh, it's weird about styles. It's dead." You know? You're just like, "Ah, but--"

So, there is something to be said for tools like React that are kind of very malleable where people abuse it to meet their needs. There's something to be said about that.

Rebecca: TypeScript, I think, is a great example where we could write code without it and the code that we ship is bigger because we use TypeScript instead of not using TypeScript. But it's the kind of thing that engineers were begging us for because they would come from another company and show up to Stripe and be like, "Flow? What's Flow? There's no documentation for Flow. There's no support network for Flow. There's no community around Flow."

The cost of using a tool or not using a tool is real. That was part of our motivation for the TypeScript conversion. Flow Types, you could make an argument that one is just as good as the other on pure functionality - maybe. But the ergonomics and the community was really missing from Flow.

Chris: You fricken' switched to TypeScript for hiring reasons. That's amazing.

Rebecca: I mean not -- no. We switched to TypeScript because TypeScript won. That's why we switched to TypeScript.

Dave: Well--

Chris: Yeah.

Dave: And Dave Rupert, a credit card user, does actually want types on the credit card. [Laughter]

Chris: Oh, yeah. I was going to say that. I want Stripe using TypeScript. Please use TypeScript.

Dave: Yeah. I want Stripe using types. Yes.

Chris: Whatever backend, I want you to use types too, please.

Dave: [Laughter]

Rebecca: I put these types there too, yeah.

Chris: Yeah.

Dave: Yeah.

00:25:08

Rebecca: That's why we have our own special flavor of Ruby as well.

Dave: Whoa!

Chris: You typed Ruby?

Rebecca: We have typed Ruby.

Chris: Weird.

Rebecca: You too can have typed Ruby. It's open source. It's called Sorbet.

Chris: Oh, my gosh. Sorbet. Okay.

Dave: Now you're going to have to re-rewrite CodePen, Chris.

Chris: It autocompletes to Sorbet Stripe when you type it into Google. Did Stripe build it? Did you build it?

Rebecca: It did. We did. I didn't but my former boss...

Chris: Wow. All this time, you could have just used Go.

Rebecca: Was Go around in 2011?

Chris: No. No.

Rebecca: Okay.

Dave: Oh, no.

Rebecca: Yeah. Yeah.

Chris: Just kidding. That's fantastic.

Rebecca: I could learn Go. But yeah, learn some types and your types in your Ruby. There you go.

00:25:56

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Split. That's split.io. Split.io/shoptalk, actually.

A very clever name for a product because it has to do with splitting the users that use your website. Imagine a basic use case of that being something like A/B testing, like I want to show some percentage of people this version of the website because I want to test the effectiveness of it without necessarily rolling it out to everybody. Test the effectiveness meaning literally measure the impact that it has and see if it's kind of good or bad.

But that same kind of technology then can be used for feature flags. That's essentially what you're doing. You use their product to set up these feature flags, like these 100 people or this 25% of the user base have this feature flag, which you use their dashboard to do. Then it allows you to write if/else statements essentially right in your own code base that says, "If this flag is turned on, deliver this piece of JavaScript, back-end code, or whatever it is. Otherwise, do this."

It gives you that ability in your code, but it separates the ability. You don't have to deploy in order to change the 100 people or the 25% or something. You manage that elsewhere, which ends up being a pretty nice experience.

Then again, it helps. It's for rolling things out. You have a brand new feature. You don't want to roll it out to everybody. You want to roll it out to a subset and get feedback from them. That's the whole point of feature flags and Split helps you do that. Split is the feature delivery platform you need to help execute these modern expectations and continuous and progressive delivery because if you're not delivering, you're falling behind.

You and a team of ten can create your first feature flags at split.io/shoptalk. Split.io/shoptalk, create your first feature flags with a team of ten. Thanks for the support.

[Banjo music stops]

00:28:06

Chris: Well, I'm curious about that. You've been JavaScripting it for a while. I mean I know you're a manager, but I'm sure you're a highly competent JavaScript programmer to this day, much better than I am. But you never peaced out. You never did the, like, "Sorry, JavaScript."

Dave: I do Rest now.

Chris: Yeah. You never.

Rebecca: Well, now I build dashboards. That is my special skill is writing SQL and then JavaScript [laughter] to build dashboards to explain everything I said earlier to the business. Yeah, I still get to write some.

For about five years, I didn't write much of any code. And then, in the last year, I actually got the survey that we send to engineers because I wrote enough code to be counted as an engineer in the dashboard.

Chris: There's no D3 of Rust, so apparently you're stuck.

Rebecca: [Laughter] Yeah, I'm stuck. Yeah, thankfully our tooling around all of this is pretty plug-and-play for these dashboards, so it's lots of cargo culting. Don't even really have people who write code.

Chris: You know we had, I think, Suz Hinton on a year and a half ago or something like that who, it looks like, just recently left Stripe.

Rebecca: Just left Stripe in the last few months.

Chris: Yeah. She had a lot of similar things to say about this friction logging and stuff. You said the word once, but that's the spirit of having a little button you can click everywhere to report problems, right? But you actually made it into a little tool. Bu the friction logging is more of a generic concept, right?

Rebecca: Yeah.

Chris: It's kind of like watching somebody do a job and then being like, "Ooh, they had a little problem right there. I'm going to write that down quick," kind of thing. But that was for user-facing stuff, so it's cool to see the synchronicity between testing your products and how people use them and applying that methodology and then just doing the same exact thing internally, really.

00:29:56

Rebecca: Yeah. One thing that's really cool at Stripe that I really appreciate is that senior-senior people (Patrick and David Singleton as two examples, so CEO and CTO), they do what's called an engineer-ication or engineer-ification. I don't know the word sort of comes out.

Dave: How they noun-ized it.

Rebecca: Yeah. I'm not sure what the noun -- they engineer-icated? I don't know.

Anyway, they spend -- [laughter] About once or twice a year, they spend about a week doing project development and experiencing what it's like to do product development. They keep--

A friction log isn't just, "Oh, I'm frustrated. Let me write it down." A friction log is, "I'm going to write down everything. I'm going to write down, like, I am sitting down to add this payment type to this country." And so, it's more than just, "I got stuck here. I got stuck here." It's the narrative that you can replay in your head as you're reading it and kind of feel what that experience was like.

Yeah, I really like that we do that as a cultural thing. On the other hand, I hate to be on the receiving end of a friction log.

Dave: Yeah.

Chris: Do you have to tune your brain? I feel like sometimes I'm bad at identifying? I guess that's why you write down everything. But let's assume it's not. You click the button when you think you have a problem. You're like, "Ah-ha! I'm sick of typing this flag in the command line. I always forget it, so I'm going to tell somebody that." Then that's going to go into this log that's actually taken seriously.

Sometimes my brain is like, "I don't know. Of course, you need -- like, it's a universal truth that you need the flag." You know what I mean?

Rebecca: [Laughter] [Indiscernible]

Chris: But I don't identify it as friction. I identify it as that's the way it is. It's got to be that way.

Dave: Chris's deal with it glasses just came down from the top.

Chris: Yeah. [Laughter]

Dave: Yeah.

Chris: I'm getting better at identifying it because we do this a lot, even in our very, very tiny team at CodePen. It's like, "No! We're going to rename that table column because we were confused about it once." You know?

Rebecca: [Laughter]

Chris: [Laughter]

Rebecca: Let's do a massive migration!

Chris: Yeah. It's called "Name" on this table and "Title" on this. We are going to standardize, goddamn it.

Rebecca: [Laughter]

Chris: We do that kind of thing, but that's only kind of recently that we've thought that way. The attitude that got us into that before was more hot and loose attitude on those things.

Rebecca: Mm-hmm. Mm-hmm.

Chris: But there was definitely a long time where I'm like, "I don't know. I can't change the table. It's just the way it is. Code around it."

00:32:41

Rebecca: We did eventually decide -- and God bless our program manager who fought to make sure that we did this, [laughter] to add a kind of impact little dropdown to the thing that comes up.

Dave: Yeah.

Rebecca: Now people can actually be like, "I'm just being annoying."

Chris: [Laughter] How mad are you?

Rebecca: "I'm going to record this. I wanted to record this, but I acknowledge that I'm just being annoying."

You know what? That's fine because then you can pile those up and hand them to a team and say, "You've got a new grad, and he wants to do UI work. Here's a stack of paper cuts in here."

Chris: Ah...

Rebecca: They're genuinely paper cuts in your UI.

Chris: #goodfirstchew - or whatever.

Rebecca: Yes. [Laughter] Exactly. Starter bug.

Dave: Yeah.

Rebecca: Yes.

Dave: Do your bosses that become engineers or re-become engineers? Is it like Undercover Boss? They put on fake mustaches?

[Laughter]

Rebecca: No.

Dave: No?

Rebecca: No.

Dave: It's not that cool?

Rebecca: No, it is the CEO or CTO showing up to the dev productivity channel and asking questions about why their dev box is broken. [Laughter]

Chris: Hmm.

Dave: You have to take their issues a bit more seriously than Alex Sexton's?

Chris: Uh, yes, Dave. Jesus. [Laughter]

Dave: No. No, you treat them like dirt. Like Alex. You just give them the same treatment.

Rebecca: I don't know if Alex has ever-- No, he did. He did the other day. I can't say that anymore. I think he hadn't filed a paper cut until recently.

Dave: Oh, okay.

00:34:11

Rebecca: But I try really hard not to. I might try.

Another thing that we found with this whole process is sometimes people, of course, would love for these things to be fixed. That's their dream. But that they are even acknowledged and somebody says, "I hear you, and that sucks," that can work on executives too. [Laughter]

Dave: Yeah. Yeah.

Rebecca: We put a big emphasis--

Chris: I have a text expander for that in customer support. You know? "I know that you want to only pay for one feature and not two. We are seriously considering your request. Thank you for sending it into us."

I know it sounds like bullshit, but some people are like, "Actually, thanks."

Rebecca: Thanks. That's all I wanted. Yeah, so that was another really interesting sort of sociological thing about this was that I think that we got a lot of goodwill out of just telling people we heard them. Every one of these paper cuts still comes to my personal inbox. Of course, it goes to Jira as well, but it comes to my personal inbox. I have at least a glance at every single one. Being able to go in front of people and say that, just that has really changed the kind of way that people feel. And they can also see bigger actions starting to be taken.

Dave: I've written a few manifestos in my day and sent it to management, and I think that's a terrible way to do it. I like your way much better.

Rebecca: [Laughter]

Dave: But I think it's at least writing down your problems. This was something I wanted to ask you about because you talked about writing is a valuable engineering asset. Even just writing down your big grievances about the app and here's some data, some observations, experiences I've had. I feel like that's a point where people can go, "Oh, yeah. It is kind of bad." You know?

I went through and I tracked every day my environment was down for this client. It was like 12 days a month I was out. They were like, "Oh, gees. And we paid them for that?" You're like, "Yep. You did." [Laughter]

00:36:17

Rebecca: Yeah, I mean I think that it has let us highlight sometimes things that once we realized that the whole authentication and authorization stuff was kind of janky, we weren't overnight able to put people on it, but we were able to put people on it and it's being worked on now. Then we'll write an email at the end that says, like, we did this because you complained.

Yeah, I think that showing people that we hear them, and that's the other challenge is being really, really communicative because a lot of the stuff we do is invisible or doesn't change overnight. We try to be really communicative with our stakeholders, our users, our everybody, our fellow engineers in developer productivity about what we're doing so that there is this sense of progress that's being made.

Dave: That's cool. Yeah. What would you recommend to somebody who wants to start this at their company? Do they have to be a certain size? Even just an informal complaint box or something, what would you suggest?

Rebecca: Yeah, I talked about this with Jenn Creighton on the single-threaded podcast, which I'd also recommend. Yours is the best, of course, but hers is pretty good. We talked about this.

I do think ... huge -- Chris, you probably should not have an engineering success team just is my hunch.

Chris: Yeah. Deal.

Rebecca: [Laughter] I think that there is a number that there's an engineering population that is probably bigger than 500 and less than 1,000. Maybe it's bigger than 400. I'm not sure where the lower end is, but it's in the hundreds. It's not in the tens because, in the tens, usually, you're solving these things yourself. You're talking to each other. You're like, "Oh, this tool annoys me. Let me remove that flag." Then you made Chris mad, but whatever.

This stuff is getting solved kind of organically in the course of doing business. So, I think that this is only necessary when a business reaches a certain size where you can't all sit around a table anymore or run into each other in the office or whatever. It becomes necessary to have a centralized function that's thinking about builds, thinking about how do we execute our tests because all these things that I certainly didn't appreciate were problems are really cost challenges at scale.

For example, running all of our tests all the time is really expensive. We need to be smarter about what we're running. [Laughter]

Dave: Yeah.

Rebecca: If you get enough engineers writing enough code and you're running all your tests all the time, well, that was a perfectly fine thing to do when the code base was smaller.

Chris: Two hundred engineers ago.

Rebecca: Yeah. But now we have problems where running all of our tests is expensive and also slow, which means that engineers are frustrated. And so, you start to have these problems that only exist at scale.

Dave: Yeah. Yeah.

Rebecca: They just don't exist. Those are the two things. One, you're doing a lot of self-solving at a certain size. Probably at the sub-100 size, you're doing a lot of self-solving. And then you might start thinking about it around 100, and it probably becomes, like, "Oops, we should have done this a year ago," as you're getting to that 500 to 1,000 space.

I think that's usually how it happens is there's somebody -- something is wrong with our infrastructure. It is no one's job, no team's job to fix it. And if we don't fix it, we're going to spend twice as much money in Q3 as we thought. That is often how something like this gets -- how something like a developer productivity organization gets started is because you let it go too long.

Chris: That's interesting, like, "There are so many of you. We need to split you up. But now it's nobody's job to keep you together."

Rebecca: Yeah. Yeah. Exactly. Exactly.

00:40:37

Chris: Well, that's cool. Anyway, if we could talk about you've been in just a revolving around Web technology for an entire career. All of us have, but we have you as the guest on the show. So, what does it make you think about technology as a whole? How do you look at tech and evaluate it and think about it? I know that's a pretty abstract question, but are you pleased with where we are, in a way?

Rebecca: No.

Chris: [Laughter] That was a quick no, so elaborate.

Dave: [Laughter]

Rebecca: Yeah, so I think I'm thinking of this from a cultural standpoint. From a tooling standpoint, my God, like, do you remember what we used to do? [Laughter]

Dave: Yeah. It's a good time for tooling right now.

Rebecca: It's just not that anymore. And anyone who complains about even Webpack. Yes, I know Webpack is getting a little long in the teeth but, still, that's magic compared to what we had. [Laughter]

Anyway, from a technical standpoint, I think that, yeah, this is a good time to be a software engineer and to be a front-end software engineer. The ecosystem is so much more mature. There's so much more respect for the role. There's so much more general recognition that this is a thing that people can be good at and being good at it matters.

I think you're also starting to see front-end people -- you're seeing more--

Chris, I think we talked about this when I was on like ten years ago. That was, I think, when I wrote my baseline for front-end developers post, circa 2014.

I think, at that time, you had people who were front-end developers who were building webpages and you had people who were front-end developers who were building websites and then eventually apps. Apps, not even websites.

I think that the perception of front-end was for building webpages, and the reality has become, "No, you're building the full-on applications with real, substantial engineering concerns." You're working in a distributed system running stuff on other people's computers. This is actually hard.

I think that front-end has gotten a lot more respect, and that's really, really cool to see the respect and the tech have both improved.

I think what I struggle with is that I'm not having as much fun as I was before. I don't know if this is me or the industry or what it is, but I'm having a lot of fun with this particular problem because it's a new problem that I haven't solved yet. [Laughter] So, that's fun.

I'm much more interested in the problems than in the tech now. I think I really gravitate toward people and process, problems that result in developer ergonomics or the lack thereof. But also, if I didn't have to work, I don't think I would. [Laughter] I'm kind of done with tech writ large.

Chris: You certainly don't see a new library drop and you'd be like, "Ooh, that looks interesting. I'm going to have a lookskee."

Rebecca: Yeah, and you had mentioned Go, and I'm like, there is a time that I would have sat down and learned Go, and I don't rule out that I will sit down and learn Go, but it's no longer the, like, [gasp] "I'm going to go home tonight and learn Go and stay up until midnight on my 2009 ThinkPad."

00:44:22

Chris: Well, it might be just because you're mentally tired with all this. But is there something else, too? Is it that it's actually just not that interesting?

Rebecca: I think the money is really convenient and also incredibly gross. I can talk about a place I used to work, and then this gets easier to explain. I used to work at Indeed, which was great. I really enjoyed it there for about five years. Really enjoyed working on the front-end platform team. Again, drove a lot of the change there, so good times.

But even like we had shirts that said, "I help people get jobs," and everywhere it's like, "I help people get jobs." It's our whole thing.

That was a really exciting mission for me for a while of, like, "Ooh, I'm finally doing something good with technology instead of just selling things." But even then, after being there a few years, I got to, like, "Why do people need jobs?"

Dave: Whoa!

Rebecca: [Laughter] Yeah.

Dave: Whoa!

Rebecca: Yeah and, like, "We are perpetuating capitalism here." It's like, well, of course you are because that's how I make money. But I think just the whole thing of it, it feels gross, like Uber. I ride in it every time that I'm out of town, but it feels gross, like what it is, what it is doing.

I think that the tech that I was excited about is the tech that Jenn Schiffer is still excited about is maybe a good metaphor. But that tech doesn't necessarily pay my bills.

Yeah, really mixed feelings about I've gotten very accustomed to an amount of money, and I wish I wasn't, is the true fact.

Dave: Yeah. It's the corporatization, right?

00:46:25

Rebecca: Yeah. I think that we started -- I started in tech at a time that it wasn't clear that it would just be kind of like driving economic efficiencies, and economic efficiencies aren't always necessarily good for humans. So, yeah, that's my actual hot take on tech is that--

Dave: Ooh, I liked it. Yeah.

Chris: Yeah, well, that's what I was getting at, too. Then it maybe trickles down to the fact that going home to learn Go isn't exciting because chances are what you're going to do with it is pluck an IP address out of a database in order to find the geolocation of a car in New York or whatever.

Rebecca: Yeah, it's to optimally show them an ad the next time that they're on Facebook, right?

Chris: Right. But if you were using it to build a super cool watercolor machine for kids or something, you'd be like, "Oh, Go is sweet." You know? [Laughter]

Rebecca: Yes. Yes, I think that's exactly it. It's just not -- I know the destination in a way that maybe I didn't before, and it's just -- yeah, that destination is less interesting.

Chris: There you go. The destination. Because there's all this other stuff that's going on. We talk about it a little bit on this show, but it's hard to talk about because I don't actually know that much about it. And what does the world need my opinion on AI art or whatever?

Rebecca: [Laughter]

Chris: But you can't avoid those kind of conversations. I'm sure people talk about it at Stripe too, like, "What is AI doing for us? And what is blockchain doing for us?" Those things seem like they tangentially touch Stripe.

Rebecca: Yeah. I can't talk about that in any detail, mostly because I don't know much about it, about that side of the world.

Dave: AI payments.

Rebecca: But -- AI payments.

[Laughter]

Rebecca: We will just figure out what you need. Yes.

Dave: Train a robot to pay me.

Rebecca: We're going to guess what you want to buy and it's going to show up on your credit card statement. You didn't need to do anything.

Dave: That's great!

Rebecca: That's our next project. No, there's a lot that feels a lot more uncomfortable about tech. And I don't know if I was just naïve in 1999 [laughter] or what, but there's stuff that just feels more like, "Oh, this is what we did all this for."

Chris: Oy... [Laughter]

Rebecca: Sorry. We've got six minutes to turn this around.

[Laughter]

Dave: Um... Cool. Watch any good anime?

[Laughter]

Rebecca: What I will say is, I say all that, but I am having fun in my individual day. I love my team. I love the work that we're doing. I'm not just saying this to make us happy again at the end here. I really like to hang out with my team and just have dinner.

Chris: Yeah.

Rebecca: Go for a walk.

Chris: It sounds like you're well along in this journey but haven't quite figured it out yet. Not like all the way.

Rebecca: Yeah, not at all. I think what's also really cool is that, yes, I'm the manager, but we're all just trying to figure this out at the same time, and so it's very -- it's not me telling people what to do. It's us getting in a room and saying, "Well, that was interesting. Now what?"

00:49:43

Dave: I read a lot of Shigeru Miyamoto stuff. He's the creator of Mario and stuff like that.

The other week, I came across this article from 1989. He's talking about the secret to success and stuff like that. One of the things he said is the goal is for each staff member individually to contribute to the overall finish of the work. I was just like, "I've never considered that's the goal, just that everyone chips in. That's the goal."

Rebecca: Everybody chips in.

Dave: Everyone chips in.

Rebecca: Yeah, we have a joke about, like, who is the data scientist this week?

Dave: Yeah.

Rebecca: Because we don't have a data scientist on our team. Sometimes it's me and sometimes it's a really fricken' senior engineer and sometimes it's the program manager. But we all know what needs to get done, and we all work together to do it, and that's been really fun.

Dave: Yeah, that stuff seems like the more fulfilling parts, right?

Rebecca: Yeah. Yeah. But truly, take away the people and I'm out of here.

[Laughter]

Chris: That doesn't seem like....

Rebecca: Except for that part where I still have to make money.

Dave: Your new team is going to be seven robots, and you have to manage them.

Rebecca: I'm the manager.

Dave: Good luck. [Laughter]

Rebecca: Yeah. But yeah, I think that's my punchline.

Chris: Well, we didn't even get a chance to talk about Stripe had a big release of this customer portal thing, it looks like just yesterday. That was pretty cool.

Rebecca: I would not know. It's very weird how I get emails about all these things, but they're so distant from what I need to be working on. [Laughter] So, that's cool. I'm glad we did that. Good job, Stripe.

Chris: Uh, yeah, so I won't ask you about that. But I will ask you to please tell your boss that there needs to be PayPal APIs in Stripe because I'm ... support.

Rebecca: No....

Chris: Yeah. Just merge. You and Braintree need to just get together and have one total API.

Rebecca: You just want to talk about all the things that I cannot talk about.

Chris: No. I mention it at the end on purpose.

[Laughter]

Dave: Finish with the feature request. Rebecca, thank you so much for coming on the show. We really appreciate it. Always a joy to have you.

For people who aren't following you and giving you money, how can they do that?

Rebecca: [Laughter] I haven't figured out a way for strangers to give me money yet, but I can work on that. But I'm just @RMurphey on Twitter. That's pretty much the only place I am, and I mostly talk about politics but sometimes I talk about tech. Definitely check out the thread from a few weeks ago about paper cuts, the space framework, and all that. Lots of good commentary and links from other folks there.

Dave: We'll link it up in the show notes. All right, well, thank you.

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 for six tweets a month. And join us over in the D-d-d-d-discord, patreon.com/shoptalkshow.

Chris, do you got anything else you'd like to say?

Chris: Oh, no. Just ShopTalkShow.com.