From Astronaut Dreams To API Development - Interview With Sophia Willows

Hi, my name is Nick Cantino and I'm a principal software engineering manager at Microsoft. In this video interview, I got to sit down with Sophia Willows who is the head of engineering at Rye. In our conversation, we got to dive into what it looks like to be an API developer in contrast to building just general software applications. And it's really interesting if you haven't had to work in this kind of environment before because usually when we're developing applications, we get to own sort of all sides of things. If we have a backend and a front end, we need to change the API. Kind of kind of sucks if we have to break backwards compatibility, but we control both of these things. However, if you're developing an API and all of your customers are developers, you have a very interesting scenario. And when it comes to breaking API changes, it becomes a bit more of a nightmare. I thought this conversation was really enlightening to have this different perspective from Sophia. And I think that you're really going to enjoy it. So sit back and let me know in the comments if you enjoy this kind of thing. Thanks and I'll see you next time. If you want to go ahead if you don't mind giving us a bit of a rundown for your career journey. Uh like I said, you can you can start wherever you'd like. Uh it's kind of funny sometimes people are like uh you know, I knew as soon as I was born I want to get into software and other people are like I had no idea until like it just happened. >> Yeah. Yeah. I'm uh I'm somewhere in the middle. Uh I didn't you know intend to become a software engineer as as a kid like uh >> you know I I think like most kids I sort of cycled through a few different uh dream jobs but the one that was sort of the most consistently recurring was I really wanted to be an astronaut. Like I loved space all these books in my room. Uh this big poster on my wall like showing the the the solar system. couldn't get enough of of space and like this idea of like venturing out there and and and exploring. Um but uh there are height limits to be an astronaut. I'm like remarkably tall. Um uh everybody's always very surprised by it and uh it was looking like oh I might be over over the threshold. In retrospect I can tell you I'm actually under the threshold. >> Interesting. >> Sounds a little overly >> short by the way. So that's kind of funny. >> Okay. So we we balanced each other out. Yeah. >> Um so yeah, in in actuality could have been an astronaut. I wasn't excluded based on height, but it was looking pretty unlikely. I I mean to be fair, like being based out of New Zealand, like it's probably hard to become an astronaut. We don't have like a space academy, and I'm sure there are like security security clearance things that you need if you want to like go work at NASA, right? Um, so it's probably for the best that I gave up on the astronaut dream. And so, uh, yeah, astronaut astronautics did not work out. Had to figure out, okay, I can't be an astronaut. What boring thing am I going to do with my life for, you know, >> anything else is going to be boring, right? Like that's compared to an astronaut. So, >> I mean, yeah, nothing's going to compare. >> Before we continue on, this is just a quick reminder that I do have courses available on dome train. If you're just getting started in your programming journey and you want to learn C, you can head over to dome train. I have a getting started in C course. It's approximately 5 hours of content taking you from absolutely no experience to being able to program in C. And after that, I have my deep dive course which will take you to the next level with another 6 hours of content so that you can start building basic applications. Head over to dorain and check it out. Let's head back to the video. My stepdad like worked with computers and you know I was into video games and and all this kind of stuff and so uh got into computers through him like you know we we played around with like this uh this like DOSS computer um and uh yeah been on the path to becoming a software engineer ever since. This is my villain origin story. Uh so you know I think like for the most part like up until like maybe you know, uh, threequarters of the way through university, like pretty typical story. I went to high school, graduated early, got some scholarships, went to uni, and, uh, it was like my second to last year when, um, I was taking like an industry project paper. It's compulsory for the software engineering degree. Uh, and they gave me a big list of like 20 projects and you had to stack rank your your, you know, top 10 and you get given them. There was like this little uh local startup called Quimmation that I put as like my rank nine project and uh of course I got given this project I didn't want to work on. Right. This is this is how it works out. >> Yes. Yes. >> Bitterly disappointed because I wanted to work on this cool like computer vision project for detecting like a cancerous lesion lesions. Uh but yeah, I got this this local startup and um it actually turned out to be like the greatest accident of my life because a month or two into this project, I got hired on as like their founding engineer. Learned a lot. I was there for for a few years before we uh wound up running out of money. Uh ended up working uh at a place called Crimson Education, which is like this big uh college admissions consultancy firm. And whenever I tell people I was a software engineer there, they are shocked because they don't realize that like this, you know, college admissions consulting firm has an engineering team in the first place. But they do. They have a very large one. there's this big in-house tech platform for managing student data and uh recently like a bunch of like recommendation engines and and things like this, you know, AI tools which like consume the student data and um produce insights on like a student's candidacy or recommend ways they can boost their candidacy. >> Oh, awesome. >> So, I was there for a while like leading a team at Crimson Global Academy, which is like the online high school part of Crimson. uh ended up running the AI team at like the core like college admissions consulting business uh you know last year and then at the start of this year uh I changed job I'm now working at Ry as their head of engineering running the engineering team and we're building uh developer tools for for online commerce which is a dream job for me because I have this huge passion for developer experience and developer productivity and like building really beautiful elegant easy to use AP API, writing a lot of documentation. I love documentation. I'm in that phase of my career, I guess. Um, and uh, you know, historically I haven't been able to get as deep into these things as I want to because it's always been like a, you know, a product company, right? We're building like a SAS product for a business or we're building uh, you know, a consumer app for a student or something like this. And at Ry, we are building an API. We ship our API. And so just like you would have like a user experience expert telling you how to build your sign up form for like your social media app so that grandma can can make an account and start start posting. Uh we need developer experience experts at Bry to make sure that our API is sort of uh you know thoughtfully designed and uh easy to use for for people outside of the company who might not have as much sort of context and understanding as us. Um, so that's that's a little bit about, you know, me and and and how I got to to where I am. Yeah, >> that's awesome. Uh, I I have a I guess a question about the journey it sounds like going from from being I guess like an IC, right, to to being able to leading engineering teams? Like what what did that transition look like? Was it kind of like a fell into it or was it like very uh you know planned? Like what what did that look like? Um yeah, it's a good question. Uh it wasn't super planned. I sort of had like uh this vague notion in my head at one point uh that like oh you know you should become a manager to to progress in your career and like you know reach that next level. Uh and then you know after you know a year or two after that I sort of you know had a mindset shift. Um, you know, management and and people leadership is not a promotion. It's a totally different sort of career track. >> That's right. Yeah. >> Um, uh, and you know, I have firsthand experience of of how true this is. Um, uh, you know, like when when I first sort of took up the team lead role at at at Crimson, um, I I'm a researcher, right? Like I'm always googling and and trying to figure out things like ahead of time. Uh, huge planner. And I was googling ah how do I be a good manager? And every single thing that you run into on the internet will tell you like hey there is no amount of research you can do that will adequately plan prepare you for this like you are going to be horrible at this job for like at least a year's time. >> Um and it's going to be a huge mindset shift and very challenging. And I sort of read this and I'm I'm pretty smart. I don't think it's going to be that big of an issue and it was very very challenging. So um when people say it's like a parallel track and like it's it's not a promotion like you know this is this is very true. It's like very different skill set like you're not directly extending the things that you had become an expert on as an IC. Um obviously like at some companies like this thing about it being parallel tracks is like kind of less true, right? Like there are some companies where you do just like legitimately sort of cap out at like senior level as an IC and there's no real progression beyond that. Um but I would say like most technology or software companies that you'd want to work at and are sort of high performing will have this understanding that like hey there is sort of this uh group of like top performing IC's that um you know need to need to progress and be given more scope and responsibility over our technology. Um and the correct way of leveraging these people may not necessarily be giving them uh people responsibility because you know they're either not interested in it which is the case for a lot of like uh people I know or um you know maybe they have an interest but they don't have the aptitude and they're and they're better off like focusing in on like the the technical side of things. Uh so yeah not planned kind of fell into it when I joined Crimson I had joined as like a senior software engineer and like that was what I was quite happy with. So, Crimson doesn't have like staff plus levels and uh you know it was literally like my third day I had my my first one-on-one with the VP of engineering and and and you know up until this point like Crimson had been very flat like it was you know everybody in technology reported directly to the VP and yeah my third day he was like hey by the way we're looking to uh you know introduce team leads like I'm sick of having you know 40 direct reports it's impossible >> it's a lot like guys calendar was like genuinely depressing. Like every time I looked at it, I was just like, "Man, I'm glad I'm not that guy." Um uh it's yeah, it's a lot. Um and so yeah, it was like totally accidental, right? Like I didn't explicitly join the company with the intention of like making this this switch and and I had to think about it for a little bit when the when the opportunity had been presented to myself like okay, do I do I really want to do this? Like uh yeah. >> Awesome. Yeah. And then uh so now like leading so leading engineering is a is your current role like is that also is that more of a uh sort of like a technology fit or does that also include like leading the people in engineering as well? >> Yeah, good question. It's like predominantly um technical like I think um uh you know HR and and people responsibilities are kind of split a little bit like we have an operations team that handles like a lot of the um you know HR responsibilities like I'm not approving like leave requests or anything. >> Okay. Yeah. >> Um and then you know like people management in terms of like you know giving feedback and things like this it's kind of like partitioned between me and the the CTR. >> Okay. Uh and uh yeah, the bulk of what I do is kind of like executionoriented, like making sure that uh the trains run on time, so to speak. >> Y >> um you know, things are are getting out the door and and people are not blocked and and people are able to succeed and we're sort of making good uh like technical decisions for the uh uh growth of the company. >> That's awesome. Yeah. No, I like I like uh asking a little bit about these kinds of things because as as people watch and listen, I guess depending on the information they're gathering from different sources, they might have a very cookie cutter idea of like, okay, there is developer, there's senior developer, then there's staff principal, okay, then there is PM, then there is engineering manager roles, then there are like it's very just like clear-cut. And I think the reality is like >> that's just not the case, right? There's a lot of common things you'll see, but there's also differences. So, uh, when you're describing a role, I I was kind I was just curious like, yeah, what does that look like? Because other people maybe they have seen roles like this, maybe they haven't, and the context is kind of interesting. So, >> yeah, it's like it's super variable between between companies and like titles are just not transferable at all. Like you always need to dig into like, okay, well, what did you actually do? Um especially I think like you know there's a lot of like um uh like uh title inflation right so we have a lot of like senior engineers who are in like for a year or two and like there are some like extreme outliers who like reach that point very quickly and they just are like very naturally gifted but like I would say most of the time it's it's an example of of title inflation. So yeah, >> I'm the senior executive VP chief of engineering. >> Uh yeah. >> Yeah. With like one person co-working with them, right? >> Yeah. And it's it is what it is. But yeah, it's I totally get the the title inflation part. It's it's a thing. >> Awesome. No, that that's that's cool. Uh it's uh >> definitely an interesting journey. It sounds like smaller smaller companies for the most part though like in terms of the engineering part or was the you mentioned the the school one maybe was a little bit bigger. >> Yeah, Crimson's a little bigger. Oh, it's like it's like big in terms of New Zealand, right? So, I think like we capped out like sort of just under 30 engineers which is like tiny in in US terms. >> Sure. Yeah. But it's not like a couple of people uh >> Yeah. >> in a you know in an office. It's uh Yeah. Got got a little bit more. But that's cool. >> Exactly. like there were there were lots of time zones to manage and it's like a big sort of global company and and engineering is like one piece of it. Yeah. >> Right. Okay. Awesome. So, okay. Uh as you kind of transition into this role though, uh you had mentioned that like your focus and something that you're passionate about is like is developer experience. So, I think this is unique because uh and I I like that you were kind of able to touch on this a little bit through the career journey, but I I don't know for a lot of people, they might not realize as they're going through their engineering journey, like you might be in roles where you're literally building uh enduser products, right? Like they're, you know, you're shipping mobile applications or you're building websites or like it's literally something that you're going to have consumers interacting with. Uh, and that's, you know, one sort of mindset when you're building things, but as you're describing as well, like in your case, your end users are developers, right? There are other people that are building on top of these things. So, >> um, I'm curious from your perspective, like what's the thing that like that you like because you mentioned like you you really like that, right? Like what what kind of makes that stand out for you that's different? Yeah, like the big thing that's different is like you know at Ry like because we're selling an API to developers, we don't directly sell the API but the API is monetized, right? It's our product. It's what we lead with. It's what we want people using. >> Um you know our engineering department is um you know functions like a profit center, right? um at and and this was true like at the New Zealand startup I worked at like we were selling like a product to end consumers. um it wasn't true at Crimson where you know engineering was really like an enabler for uh you know our service departments helping students out like I think it's increasingly true that um engineering is a is a profit center as like more sort of product lines get built um but for the most part like most of my tenure there like it was very much a cost center right and I think like uh the thing that's different for between Ry and those other two companies is is um you know one we're a profit center like you know quotation the the local New Zealand uh startup uh and two like we're not selling like a UI right so when you're selling this consumer product to people like they really could not care less about what it looks like under the hood just so long as like the product sort of meets their requirements and and suits their needs. And historically it's been true that uh capital has been very cheap to raise. And so I think a lot of like engineering leadership has earned on the side of like well we can take on a lot of tech debt and our code base can be a little messy and it's fine because it's going to be very easy to assuming we get a little bit of growth out of it. it's going to be very easy for us to do another capital raise and like expand the team and we can sort of just like scale our way out of like these uh uh you know constraints imposed on us by technical debt. >> It's a little different today like that doesn't quite work um because raising is hard. Uh and at Ry like we're kind of in this environment where we know that um we have a great product and like we can easily raise but like would that would it be on on on favorable terms like it's unclear uh maybe in a year or two. Um and we also know that um uh a key success criteria for us is the developer experience. like people actually do care about what our thing looks like under the hood because they are directly integrating with it like programmatically, right? Um so in exactly the same way that like you know you might have like a one-on-one with like a report and they complain to you about uh how spaghettified your codebase is and how impossible it is to work on uh sort of the project they've been assigned to lead. um we we potentially can have those exact same discussions with our end customers where they will tell us like hey this API endpoint is like really hard to use like it's it's it's uh making it really hard for us to like build our integration on top of you guys uh and you know we'll get some feedback and and iterate there it's not something that we can paper over like we like you can when you're just shipping a UI like the underlying API the underlying implementation can be as horrible as you'd like so long as you can put a nice like uh coat of paint on top. >> Uh it all works out but like at Riy it's it's fundamentally different. So we have sort of like economic constraints which force us to uh sort of be a lot more intentional about incurring technical debt and a lot more like strategic and and long-term oriented. And then the other thing is like we don't have this nice like UI abstraction layer in between us and our end customer. Our end customers are directly interfacing with whatever we ship and yeah sure like you can cut a V2 API but like forcing people to move from V1 to V2 is like impossible. It's hard to do internally in an engineering organization. it's impossible to do when you have like people outside of your company who um already have an integration that's it's already working for them. Um so and and so that also puts a lot of constraint on us like we need to think very very carefully about our public APIs and like what we're shipping and like is this the right abstraction? Have we gone too far? Have we not gone far enough? Like what's the story for uh evolving this thing over time? like have we sort of boxed ourselves into a corner? Can we build more sort of affordances into the schema so that we have flexibility in future if things change? Like these are front of mind at Ry in a way that uh they just haven't really been uh at past companies. >> Yeah, that's super interesting, right? Because like I think uh probably something that will resonate with many people is like if you're thinking about a typical web stack, right? you have some back end that has APIs you're calling and you have a front end that's going to be calling those things. And yeah, of course, like when you're versioning APIs and stuff like that's a bit of a pain in the butt for sure. Like we're we're not all fans of doing it, but at least if you own both sides of it, you can you can go do that, right? You're like, "Okay, we'll have a plan. We'll introduce a V2. We'll migrate over to it over time." >> And you get there. And but in in the situation you're describing, it's so true. It's like, how are you going to convince all of your users who are paying money, they're happily using V1, let's say, >> and they're going, what do you mean we have to go do more work to change that like how we're doing things like we're paying you like we're not doing more work on this, right? So, uh >> yeah, and and you know, there's a really interesting um uh case study actually or or something that sort of uh this makes me think of um I forget the guy's name, but uh he used to work at at uh at Stripe and he's got a um blog post about the Postgress uh text data type. And so text is different from varcar. Like if you have a var column, it's it's constrained to a particular maximum length. Text is unbounded. And so you might think like oh this is this is a great uh data type to be using. I don't need to think upfront about like the size of my uh database columns. But he kind of mentions that like when they're building Stripe and you know Stripe in many ways is very similar to Ry. It's an API company. have a lot of these sort of developer experience constraints that we have. Um, Stripe used a lot of text columns like back in the early days and uh what they discovered was people were stuffing like super long like JSON objects and stringified form into like name fields in their API to like you know as a sort of metadata store. Um, and it was slowing things down. They had these huge text blobs in their in their database. Uh and so Stripe uh decided uh to do the you know very reasonable thing which is like okay well we'll put some caps in place on these on these fields and you know we'll reject anything longer than 255 characters and that sounds very easy until you realize like Stripe was very deep into their uh uh um uh company at this point. They had a ton of integrations. A lot of developers are are depending on this behavior that they can just send, you know, a giant 2 megabyte JSON string and it and it works. Um, and so, uh, you know, there's this this blog post, um, uh, sort of talks about like how they managed this. They had to find like all the developers who were relying on this and like communicate with them. Some people they just could not manage to reach and like get them to to upgrade. And so, you know, they have like a hard-coded list of like, okay, these users, they get to send giant payloads and everyone else um >> and everyone else is stuck is is, you know, constrained to like, you know, 5,000 characters or something. And uh you know, that's that's the kind of thing you need to do, right? Like it's it's it's very difficult to sell to your customers like hey we're going to break your integration because again like they don't care that like you're running into like operational problems with your database right like this is this is not their problem. It's not their problem. No >> exactly. Um and and you know this is a really great example of how like something really minor like oh okay like what data type you know do we pick like a a var or or text column which is like totally uncontroversial when you're just building like a consumer web app like you own both sides of the stack like this is never going to be an issue you can always just pick a text and be fine >> when you're shipping an API to external developers like totally different story um and uh there's this thing called Hyum's law which which um sort of states that like you know when you with a sufficient number of users of an API doesn't matter what you're promising in your contract like all observable behaviors of your system will be depended on by someone um and you know a text field where you can send you know a 2 megabyte JSON payload is something that you probably don't advertise in your contract but it's an observable behavior and someone's probably going to try do it at some point And uh once someone has done it like it's sort of uh de facto become part of your contract like someone depends on it and it's very much a breaking change to fix that even if it feels like an oversight from from your perspective as the API uh builder. >> But that's a it's such a good point though right because like as you said like once someone does it >> now literally that's at least one person that depends on this as functionality. There was nothing that said they couldn't. they were literally able to do it and they go great now I depend on it. So, I mean, >> if it's early and you happen to notice it and you're willing to say like, "No, we're not putting up with that." Sure. But that's that's a tough conversation. And odds are it's not something that you observe right away. It's something that over time, especially if you're someone like Stripe, >> all these users on boarding all of the like building APIs over years, then all of a sudden you're like, >> I guess it isn't all of a sudden, right? It's uh you reach a point where you're going, "Wait a second, what's going on here?" And then it's like, "Oh crap. Yeah. And and the other thing to touch on too is like the other similarity between Ry and Stripe is like, you know, like what are people depending on us for, right? So like people integrate with Stripe to add payments to their application at Ry. We build like this commerce API. You can, you know, build a social marketplace or a link and bio app and like sell products from any uh Shopify or Amazon store on the internet. Um so you integrate with us you embed commerce into your application like payments and uh selling products like these are for a lot of companies like the most important part of their business okay because you know with stripe you're directly capturing payments from an end user like revenue is pretty important with rye you're earning commissions generally on the things you're selling through our API like again like it's it's you know this is where you make your And so >> people care about that, right? >> It's not like, yeah, people care about this. It's not like we are shipping, you know, like some kind of like managed chat room as a service thing where okay, we have a little bit of downtime and people are upset because their uh chat experience broke for a little bit. Like this is like we go down or we break someone's integration because we ship a breaking change, >> their business stops >> and their business Yeah. their business grinds to a halt, right? like they're not making money anymore. It's it's a huge huge problem. So, these things are just, you know, it's uh elevated to that next level because of like the nature of the product that we're we're giving people and like where we sit in their in their business. >> Yeah, that's uh like Yeah, I was I wanted to say like, hey, yeah, like no pressure, right? Like it's uh it's it's pretty important. So, that's uh that's definitely challenging. That's uh that's cool, though. So, uh it's uh I I kind of mentioned as I was thinking about the like the developer experience part like building APIs, I kind of touched on like okay yeah like you could be building consumer products and I guess the other thing that I didn't really draw the distinction before but uh the work that I've been doing recently is more around like platforms and I guess this is technically different from uh a platform. So when I'm when I'm saying platform, I'm thinking like I used to manage deployment teams. So deployment was the platform. Now I'm managing teams that work on routing infrastructure. So we have routing uh as a platform for different services. But in this case uh it's it's still like a product but the sort of like the service area of the product just looks very different. How it's packaged is not uh it's not something that users are clicking through like and having a visual experience and stuff like that. So, um, yeah, I guess that ends up being in my head. I'm like, I guess it's like a third classification of things like, so I just hadn't really kind of pieced it together that way, but >> yeah, >> probably have a like similar types of interactions, I guess, though. And the this is the I was kind of curious about this part right from like a engineering or developer experience perspective for us as a platform team like serving other internal service owners we're in this position where our like we have true enduser customers like literally people that are using Microsoft products are the end users but a lot of the time we're thinking about our our users as the other service owners and those are other engineering teams they have their engineering constraints. They're building services and I feel like there's probably a lot of similarity there uh to the work that you're doing where like you're working with other engineers. Is that like would you say that's a similar thing? >> Yeah, absolutely. I think um there's a lot of like uh there's a lot of overlap here, right? Like we're both serving um developers like it's a technical audience like they care about the the interfaces you're shipping. Um the the main difference that I would um sort of draw here is like you know uh different sort of uh you're different teams in the same like overarching like organization right the incentives are somewhat although not entirely perfectly aligned and and there's sort of like this um >> uh uh organizational structure you can leverage to like try and and force people to move off of API and um I think like this context that you're talking about like platform engineering like this feels to me like where a lot of the developer experience like conversation and tooling like centers around like there's a tool that uh I've been looking at it's like quite literally called DX um and uh you know like they have this thing called like devx 360 and they pitch it as like quantify internal developer experience and I that term internal uh is very very uh important. Like I think there's kind of like two flavors of developer experience like you've got internal developer experience which is where a lot of the conversation centers around. This is like platform team servicing um sort of product teams or product teams concerned about like the code quality of like their product that they own end to end. And then you've kind of got this uh you know external developer experience concern where you know you are sort of like this island and you've got a bunch of other developers on other islands trying to interface with your uh with your system and the tooling and and the metrics and the uh sort of organizational leverage you have in these two different sort of um camps. Um there's a lot of like overlap but it's also like very different. Yeah, that uh the concept of like that like sort of your organizational uh influence, right, I think is is a really key point because I'm I'm trying to I'm trying to think about my current situation and you're totally right that uh in our org so I work in M365 so like the office 365 product suite >> uh if if we had uh if we had to you know we had some mandate from leadership we have to move in some direction and we go okay we're going to design for this we would have like support from, you know, other teams might be, you know, not totally happy with us if we had to pivot and do something, but we'd be able to rally behind it, >> get buy in and get people to move. And I've seen like from other teams, I've seen this kind of thing happen where we're all kind of like, "Oh man, like that's going to be extra work, but we're like we get like why it has to happen. Like we'll figure out how to schedule like we're going to help you get there." But yeah, it's like it's not great, but we can all align to it because we're in the same org because we have these common business goals. But when you start to lose that, like I am I'm just like I said, I'm trying to picture this situation where we have a team coming to us and saying, "Look, like we're switching things and we know you use this. You're a heavy user of this, but uh the way forward is this and we're planning to deprecate in this time frame." If they weren't in our org, I c I can't even imagine what our response would be like. Like you're joking, right? Like we're absolutely not doing that. >> Yeah, totally. That's that's Yeah, exactly. That's this is um this is uh our our lived experience, right? Like this happens. Yeah. >> Right. No, that's uh do you find like are there situations where you where at least in your experience where you've had to do that where you've had to basically say like we are going to a you know v- next and like and you have to come up with the pitch to them and is it kind of like a if you if that is the case is it like a common message where you're like look uh it's because of some internal you know changes we had to make or like how do you how do you kind of frame that to users so that they're like, "Okay, like we're not happy, but we can get behind it or like what does that even look like to to move forward?" >> Yeah, totally. Um, so, you know, just like as a backdrop, like we try to avoid >> of course >> breaking changes wherever possible. We we don't try we try not to make a habit of it and and we always ask ourselves like okay like you know we do we have had to make some breaking changes and we always ask like you know afterwards like okay how could we have avoided this? Was this predictable in some way? got to learn from it in some some capacity or try to right. >> Yeah, exactly. But to to answer your question, uh you know, like the thing is to always sort of focus on uh uh value and like the reason why we're making these changes. So a lot of our breaking changes come in the form of like uh schema updates, >> okay? because uh you know like we modeled the underlying world like a little bit uh inaccurately and like we need to change a type or we need to uh get rid of a field or something like this. And um the way that I sort of pushed the team to frame this is like you know it's not just that we are going to send these guys a message saying like hey by the way the type of this field uh is changing you know two weeks from now please update. This is a horrible message to receive as might be the reality as an end. Yeah, that's re like this is reality. This is what we did from like a technical perspective. And yes, this is absolutely what they must do in order to sort of get over this hurdle. Like this is all uh accurate. But if you're on the receiving end of this message, like you start asking questions like, well, okay, well, why do why are you guys breaking my integration? Like this is this is busy work, right? Um uh like you said, like we're you know, we're not going to do this. we got other stuff to do. Like that's the that's the last thing we want to go focus on now that we already got it working. >> Yeah, exactly. So, uh you know like when we make these changes so like one that comes to mind which is like somewhat minor is uh we we have like a product API you can get information about products and we expose like the weight of the product. >> Um and uh initially this was modeled as an integer. uh turns out that weights can be uh floatingoint numbers. We we made a mistake, you know, two years ago when this API was first uh introduced and like we've been very lucky up until, you know, about 6 months ago. And so we had to change it to a float, which for something like JavaScript is fine. Uh but for a language like Go is is not so fine if someone's deserializing it as an integer. Um and so you know like we we communicated like hey the type of this is changing it's it's a breaking change depending on you know for for some sort of tech stocks. Um uh and this is what you need to do. It's it's relatively easy lift. There's no major migration here. Uh and the reason why we're doing this is because we you know are are um giving you more accurate information because weight is actually somewhat important if you are uh you know one of our customers has sort of like a warehousing business where people from outside of the US can order product ship it to their warehouse and then have it forwarded on. Uh and so weight is very important for them uh because they need to know like um this information in order to uh optimize their logistics for getting things out of the US, >> right? >> Uh and so having like >> yeah having very accurate weight information like okay sure it's like just some floating point error you know it's like a half a half a kilogram here and there but like it adds up over the over the course of like a full sort of um shipping crate, right? So we need to make this change. we need to be accurate. Um and and the trick is to focus on like okay like what awesome things are we enabling? What new use cases are we are we are we um making possible like what can you now do with our API that you couldn't do previously or what can you do better now uh that you know you couldn't do quite so well uh previously. Um, and that kind of gives people like a carrot for like, okay, I'm going to make this change. Sometimes it's very minor like, you know, I'm gonna change a type. Sometimes it's uh a bit more major like I think uh, you know, like maybe we've uh, realized that, hey, this API call uh, up until now it's it's been synchronous. We give a response immediately, but actually it turns out that uh, you know, our P99 latency here is super high. like we need this to be async. Uh this is a larger engineering lift on our customers end. >> Um but the key is always like yeah sure there's like a technical reality like what technically did we change and what do the engineering what does the engineering team need to do? Um and the and but just receiving that on its own is like a really hard blow and people are not motivated by hearing about by by hearing like what has technically changed. They need to know like okay what am I getting out of this like why is Ry putting me through this pain of you know fitting this thing onto my road map I don't really want to do it like what's the carrot at the end uh and the idea that like oh I'll do this and my integration continues working as is with like no net change uh is not a is not a suitable carrot this does not motivate people the idea that like oh I must do it or I'll break Um, >> yeah, just to just to keep things going, I guess I'll do the work. Like that's a pretty bad motivator. Um, >> yeah, >> I thought it it was really interesting as you were explaining this because uh you're obviously describing your user base is like they're they're obviously technical, right? they're calling an API. They're developers. They have to work through this. But >> even though internally you have technical reasons for making changes and you have to explain technically how an API is going to change, it's still very interesting to me that it's the reality is the end users here, they don't care about the technical reason why. So they care about technically what they have to do to adjust, but they don't care about the like truly behind the scenes. They're like >> like the reason that you had to do that that's not our problem. So >> uh I the reason I'm bringing this up is because I think like communication and software engineering is like a it's like an undervalued thing and >> the what you just explained I think was so important because if you are hyperfocused on just writing code and like uh you know stereotypical kind of programming mindset which I'm not blaming anyone for doing because I just think that a lot of us think that way and uh we have to work hard at kind of uh you know stepping back from that But the the sort of stereotypical programmer will say well this is the reason why like this is the technical reason that's what we have to say but you have to remember the like you always have to think about your audience in this case your audience is your end user right but when you're ever you're communicating ideas like you have to explain things in a way that people are going to understand and they're going to care about in this case you want to be able to persuade people it's like a you know like you said here's the carrot the motivator for it So um kind of dropping the internal technical reason why like again not our problem that you had to make a schema change internally that's not our problem but now you flip the whole thing around and you can focus on value you can say like these are things that you will care about like this will be a motivator for you. Yeah, totally. And you know, like this extends to all of our communication with uh with our sort of uh developers. Like if you were to look at the Ry change log, like you know, we don't just focus on value when we're talking about breaking changes. Like we also add this little bit of flavor text to things like new feature releases. Like so uh recently uh in in July like we added a web hook we fire for when uh Amazon orders um have their sort of uh delivery delayed right and you know there's a way of writing a change log here where we put a bullet point in and say hey we have this new web hook uh and you know full stop onto the next uh point >> web hook done next. Yeah >> done next. you know, you I can imagine the the conventional commit message, right? Like feed add order delivery delayed web hook for Amazon orders and you just automatically generate that change log, right? Um but you know, we we always want to go a step further and if you look at our change log, you will see that we have a couple of follow-on sentences explaining like what is the value of this web hook. Um it's not just developer like developers want this like quick summary of like okay why has this been added like is it relevant to to what I'm working on >> I don't want to dig through docs or like play with this thing. Um and also like non-technical people are looking at our change log as well like we interface with like you know product managers and business people as well. These are also stakeholders we serve. It's not just developers, >> right? >> And so we have like a little bit of flavor text explaining like, hey, um, uh, this web hook gets fired when the order will be delivered later than we estimated, right? Like should be pretty obvious from the naming of the web hook, but let's be very explicit here. >> Sure. >> And what can you use this for? Well, you can use it to better inform your shoppers, which is the term we use for someone buying a product from one of our developers uh, platforms. you can use it to better inform them and and keep them in the loop about uh you know fulfillment status because uh that sort of post-purchase uh postcheckout experience is very important. People want to know like where are their packages? Is it stuck? Is it on the way? They want this reassurance. >> They're excited to receive their thing, right? >> Um we've all been there. And so um you know this extends to everything we do. We we want to be uh constantly talking to people about our developers and and other stakeholders like what awesome things are we enabling you to do. Um, you know, and and we want people to sort of, you know, read our change log or or read communications from us in general and like come away with the sense that like, wow, these people at Ry are working so hard for me, >> right? >> Um, >> they're working to give us value, right? >> Yeah. And they really care about my success. And, you know, if it's something like a customer support request, like we want them I want them to come away with the sense that like I am Ry's most important customer. Like I've worked with some amazing vendors like Hypertune is one that I've worked with where I come away with this feeling that I'm their most important customer every time I I deal with them. They're a feature flagging solution. Um I've had uh less uh optimal interactions with vendors where I've come away thinking like, "Oh, these guys don't really care. I'm just another, you know, entry in their in their CRM." Um uh and you know like Ry is at a sort of stage where like um we can have this very like hightouch um sort of white glove approach to a lot of our developers and like culturally we're building uh an organization that like really cares about communication like thinking holistically about what we're doing. >> Um something unique about Rise like we don't hire product managers. Um, interesting. >> Yeah, we're we're an engineering le company and something that we screen for when we hire for developers is like, >> yeah, sure. We're a technical company. We're an API company. We move, you know, a lot of GMV, like tens of millions of of dollars and we we do, you know, hundreds of thousands of orders every month and it's, you know, growing at a sort of exponential rate. So there are hard scaling challenges and like system design um uh things to solve for like a lot of very interesting failure modes because one of the things we support is a Reichart can check out products from multiple stores in one go and okay what happens if uh checking out the product from store A succeeds but then product B uh their uh sorry store B's product you're purchasing went out of stock between the cart being created and checking out like >> I don't even want to think about that's So very hard engineering problems. >> Yeah. >> Uh a lot of depth here, but like we're not looking for like, you know, hardcore like nerdy sit down, write code all day, and this is all I care about style engineers. like we're screening for uh like a bend towards thinking about the product holistically and like how do we design things to to provide value to to developers because uh you can write sort of the most elegant code in the world or you can build like the most complicated you know the most complicated and and interesting system technically uh that you want uh you know you can do event sourcing and and all these uh cool things. Um, but if if you're not shipping something that's actually useful for the person on the other end of the product, uh, it's it's all a waste, right? Um, at the end of the day, like the technology is cool and and it's fun and it's interesting and it's why a lot of us like got into this field in the first place. Um, but our goal ultimately is like we need to produce something that is valuable for another human being. Um uh so yeah, this this permeates very deeply in our in our engineering team and and sort of the culture that we're trying to build. We're very concerned with things uh like uh how we communicate to uh to developers and and how do we think about uh the projects we're building, >> right? that that concept of like I I I feel like it's not said enough in general, but um like I think it for most people it comes just with like experience where like I'm working at a company. I understand a company needs to be shipping value to customers. That's how the customers end up paying us. That's how we're able to keep our jobs and grow the company. But I think for a lot of people, especially more junior people, and I don't mean to pick on junior people, I just I don't think a lot of them have yet had sort of this learned experience where >> especially again some bias here and some generalization, but like especially if you're if you've gone through school and you or boot camps and you focused on like computer science concepts and here's how you go write like this is like ideal code to go structure. You get into work and you're like, okay, I'm ready to go apply these things that I just spent all this time learning and then you see the code base and you go like, oh no, this isn't this isn't perfect. And then now your brain is like, okay, I'm going to make sure as I go forward I'm writing the most perfect code. And like this just becomes this thing we focus on. But >> I'm not saying go write bad code, but what I am saying is like at the end of the day, you have to be shipping value or else you don't have a business. Unfortunately. >> Yeah. Yeah. Absolutely. Nobody gets their paycheck and uh everybody everybody goes hungry. Yeah. I think like something else that's like kind of challenging for junior engineers actually is like it's like really hard to be a software engineer. Um like it's really hard. There's like so much depth to what we do and like there's so much uh content. like I'm pretty deep into this stuff now and like I'm still learning new things and like your first year or two like okay you're you're fresh out of university and and you're getting into it um and honestly like the things you work on in industry are not perfectly aligned with the things that you've learned uh at university like my alma mater did not teach how to use git right I learned that because I uh you know had some internships and like I'd worked on you know personal projects like for you know basically my whole life like since early high school >> but like I have hired junior engineers where they where they get in and like they're fresh out of school and maybe they didn't do internships or their internships weren't like at you know tech companies it was like some random business that needed someone to like build a set of scripts for them >> and they don't have these fundamentals like um you know how to use git or um uh they don't have a lot of like this sort of um they don't have like a lot of the muscle memory that that we take for granted as like senior plus engineers uh when when writing code. Uh and so it's like really hard as a junior because um you're simultaneously trying to you know develop that baseline technical competency so that it kind of you know largely uh is internalized and and is a background concern you're not thinking about so consciously. But then you also need to sort of um uh grow and and understand that like you know this thing that you're sort of banging your head against the wall uh against uh you know eight hours a day like learning these these technical skills like they're not the be all and end all and there are these soft skills and like more sort of uh holistic product oriented and and businessoriented thinking that you also need to learn. So like it's it's hard for juniors like there's a lot to cover in a very short period of time uh to to get to the intermediate level. So I have a lot of empathy for people >> uh entering our field especially people coming from like >> you know uh unorthodox backgrounds where like you know they didn't have that nice happy path like okay I have like all the schooling and I've got these internships and now I'm like reasonable side projects. >> Yeah. Um yeah, it's uh it's tricky. >> Yeah. And then you at least my experience uh because even with internships and stuff like the something that I don't think we talk about a lot is like the domain that you could be working in could be completely >> completely out of left field compared to anything you've thought of. Like I've had I've worked for bank machine companies like making ATM software. I've worked at a company that made in needleless injectors for farm animals to help immunize them. Like that's a totally random thing. Um, >> at no point in my life was I like I plan on helping medicate farm animals as a software engineer. Like it just it's not a thing that came up. >> So the amount of learning and like just sort of newness that you're exposed to is like it's pretty ridiculous as a as a new like software engineer. So >> a lot of empathy Um, and I I I I see one of the notes that you kind of left for uh for discussion. I I don't think we've touched on yet, but I think it's interesting. So, this idea of uh of individuals that have like a concept of like internal developer experience versus external. And I think we touched on it a little bit uh and maybe in terms of like what what things people might focus on, but maybe from your experience like how how has this like kind of shown up where uh people have maybe different framing or they might be focused on I don't want to say like the wrong things, but maybe they're not prioritizing things that you think are most effective. >> Yeah, I'm kind of building like uh increasing conviction on this. So like um I have had conversations with like people on my team or like outside of my team and and adjacent teams like my entire career where people have said like where folks are complaining that like oh you know this code isn't very good. It's hard to work with. It's spaghetti. Um, and we all kind of, you know, nod our heads and agree because I mean I have yet to work in a code base that's like totally pristine, right? There's always issues. >> Even when people rewrite it like after like the first week, it's already back to spaghetti. Like I don't I don't care who you are. That's what happens. Yeah, it's just yeah, it's the natural state of things and like you know like optimistically like I think you know part of that is just like you know if you're a successful company like your engineering standards should be raising over time right like you you're at a higher scale and now there are more concerns you need to deal with or you have more edge cases you need to consider because you you know there's this.5% of the market is now a substantial source of revenue and maybe it wasn't important a year ago but now it is so I think you know optimistically It's, you know, it's it's a good sign if you have technical debt. It's uh if I think uh you know, if you have no technical debt, you're probably not successful. If you have technical debt, you might be successful. So, >> at least the software has existed long enough and it's been sustained long enough that it could have technical debt, right? So, >> Exactly. Yeah. Um but something that I observed was like you know people would complain about uh the code they're working on and like you know we want to make it better and and and all these kind of things when we had to interface with these adjacent teams that I had had these sort of passionate discussions about developer experience with um they put a lot more concern into like their side of the uh uh imple of their side of the project, right? So like their internal implementation of the thing that like fires us a web hook or their internal implementation of the API endpoint felt higher quality than the interface that they were shipping to us like there was a lot of coupling to the database for instance because it was easier to do that rather than introduce like some abstraction. >> Okay. Um, and so, um, yeah, I've I've and I think like part of this is like, um, you know, like you ship your org chart, right? Like, um, and and people are are you're always going to have silos like to some extent. Uh, and people are motivated by, you know, their their performance review cycle and they just need to ship it and like they can say like, okay, I did my job and like I threw this this this uh API endpoint over at these guys and like they dropped the ball, >> right? So I I think there's some like um tribalism there, but like also I just think like you know if you're building an API for another team at your company like you are not generally going to be the person integrating with that API and so you don't feel the pain or the joy of integrating with that of using that API endpoint like you don't have that personal experience you just experience like building the thing >> right And so you're going to optimize um generally unless you're like very intentional here like you're going to optimize for the joy of building the thing and sometimes that means taking shortcuts which have downstream impacts. Um and so this is something that like uh you know we're we're kind of careful about at right because yes we care about our internal codebase quality because we have you know very complicated failure modes that that we need to be able to understand and reason about. >> Um but also like you know we don't want to be taking shortcuts when we're building an API endpoint or or building a feature that we're shipping to our uh developers. Um, and sort of the way I think about this, like I don't know if if this is a term that's sort of widely used, but like the way I describe is like we want to be writing in sort of like a caller oriented fashion. >> And I think this is like generally true in engineering. So even if even if you don't have this external sort of developer working with your API or you're not interfacing with another team, if you're just building a function to be used like internally to your team, you have one implementation of that function and you have at least one caller of it. Generally you have more. Uh in general it probably makes sense to optimize for the call site rather than the implementation because the call site is more uh frequently occurring in your codebase. >> There are more instances of those call sites generally like you said like at minimum it's like a one to one but more likely it's >> more right. Yeah. So, and and so this is the intuition that I'm I'm trying to to test for in in in engineers at RI like do we h do you have a systematic understanding of this and like an understanding that like this is true within our code base within the things like we're working on day-to-day but it's also true with our developers like we have one product by ID endpoint we have many many many developers uh who all have like unique integrations like calling this endpoint >> and so if we can you know make our internal implementation 10% more complicated and end up shipping like a 1% better API endpoint like whether that's like we can reduce latency or we can capture the semantics of the domain better or uh you know give us more affordances for for evolution down the line whatever it might be that trade-off probably makes sense it probably makes sense to take on that 10% extra uh uh complexity and in service of shipping like that 1% better uh endpoint. And honestly like the break even point here is probably much higher than 10 to one. Like we have more than 10 people using uh this this endpoint. >> Um and so this is kind of like the general sort of mindset that we're looking for. Um and and my experience is that like most engineers understand this uh implicitly even if they can't sort of give voice to it when they're talking about like a codebase they own end to end. >> But once you get to the boundary and once you don't have that personal lived experience of like integrating with the thing um that understanding kind of like gets a bit foggy. Um, something else we are are doing increasingly now is like for a long time we didn't use our own API. Um, so like our developer console for instance has like an order details page which like uses some private endpoints we built kind of like uh almost like backend for front end style. And so we're incrementally shifting these things away and like we're consuming our own API in our developer console so that we have that feedback loop of like, hey, this feels really bad. Like it's super hard building this page. Like did we did we mess up when we designed this thing? >> Yeah. Cuz if it's hard for you guys, like you can only imagine that like Yeah. the customers are going to be like I'm not touching that. >> Yeah. We built the thing. We're experts, right? Like if it's hard for us, then God only knows how someone else is supposed to do it. Yeah. Exactly. Okay. So, so this is yeah, we we we're looking for an understanding of like this caller oriented design concept because there's always there's always at least a 1:1 ratio between callers and and implementations and generally speaking there's it's it's actually like none. You have more than just a one:1 ratio. >> Yeah, that that makes a lot of sense. I I like that uh sort of the explanation around the priority given a ratio like that. Right. I thought something else that was interesting back to what you had said earlier about if you don't have product managers that are kind of acting as that user proxy to I don't want to say enforce that's too strong of a word but kind of propagate um that sort of understanding across teams like making sure that when you're hiring people on that they will embody that that they understand that because they kind of need to have that representation for themsel in their work. So um >> definitely makes sense. I think that's super cool. Um, so yeah, Sophia, I wanted to say thank you so much. Um, I wanted to double check uh I can ask uh for links and stuff from you after, but if people want to get in touch with you, uh if they want to check out what what you guys are doing, like where where's the best spot for people to head to? >> Yeah, sure. So, uh I I work at rye.com. Uh threeletter domain. It's very very cool. Uh and then uh outside of work, I I write a blog. um safiabits.com. Uh little inactive in the past month or two, but I'm getting back into it. There's a lot of content around, you know, API design, especially uh in GraphQL, uh you know, engineering leadership, um and uh AI, of course, everybody's writing about this now. >> That's right. No, that's awesome. And like I said, I'll I'll make sure I have links and stuff that I can I can post with the video. So, uh, I I want to say thanks again. This was super cool. I love hearing about this kind of thing because it's different perspective. I get to learn a lot. I I imagine that anyone who's listening and watching will get to learn a lot as well. So, thank you so much. >> Yeah. Thanks for having me. I really enjoyed it. >> Of course. Thanks.