The Stack Overflow Podcast

The polyglot who leads Stack Overflow's Platform team

Episode Summary

We chat with Rennie Clayton, Senior Director of Platform Engineering here at Stack Overflow, who grew up moving between multiple countries and learned programming by following along with his mother's college coursework.

Episode Notes

Rennie grew up in Kenya, Honduras, Somalia, and Oklahoma; his parents volunteered for the Peace Corps before working for the US Government overseas. 

Audio tape drives are real!  Check out this Retrocomputing question about how the Commodore 64 audio interface worked. 

If you  want  to remember something better, a 2014 study says you should write it out by hand. 

Rennie worked at Blackberry, and Ben remembered his colleagues at the Verge fondly hoping for their comeback. In fact, here's Ben hoping for their comeback!

We did a podcast on moving from engineer to manager, which Rennie said was one of the hardest things to do. 

Rennie gave a shoutout to the book he's reading now, The Elegant Puzzle by Will Larson. 

Rennie works on our Platform team, which works on all of our reusable stuff, including our design system, Stacks

This week's Lifeboat badge goes to Vinzzz for explaining how to Create an array of random numbers in Swift.

Episode Transcription

Rennie Clayton I would sit and work in this kind of nursing station and hear all these different languages being spoken around me. And I would kind of casually interchange like different words from different languages in the same sentence kind of thing, just because that's what I was hearing, right? So those were the words that were being spoken around me. So it really didn't feel all that unusual for me honestly to switch from one technology stack to another. I got PHP over here, I got C sharp over here, and there's some syntax differences. But under the hood, they really didn't change. And once I got past that kind of fear of the learning curve kind of thing and I recognized that the structure was mostly similar, then it really wasn't a big deal anymore.

[intro music]

Ben Popper I'm sure you've heard us talk on the show about all of the momentum around cloud training and certifications. Well, today, I'm here to tell you, you can visit and save 30% on Global Knowledge's AWS training courses. Their certified AWS instructors will teach you the skills to design, deploy, operate and secure your infrastructure and applications. Get this limited time offer at

BP Hello everybody. Welcome to the Stack Overflow Podcast a place to talk about all things software and technology. I am Ben Popper, the director of content here at Stack Overflow, joined as I often am by Ryan Donovan and Ceora Ford. Hi, y'all. 

Ceora Ford Hey!

Ryan Donovan Morning, Ben.

BP Ceora, your hair is orange and is making me very happy. [Ceora laughs] I thought it was a Halloween decision, but it's just a good style decision.

CF Oh, thank you. I'm glad. I was a little nervous at first. I kept--every time I look at myself in the mirror. I'm like, who is this?

BP Well, just be grateful you can make care decisions. You know, it's not something we all get to do. 

RD That's right. 

BP So today we have a great guest, Rennie Clayton, who is the Senior Director of platform engineering at Stack Overflow. Rennie, welcome to the show. 

RC Thanks for having me on. 

BP So usually what we do--and if you don't want to date yourself, that's okay--is we ask folks, how'd you get started with computers and software and all these little bits and bytes that we talk about on the

RC Yeah, that's a bit of a long story. I'll try to make it a terribly short, I grew up overseas. And I grew up in places where there was no infrastructure. There's nothing interesting to do from from an entertainment standpoint. My parents were Peace Corps volunteers. They later moved into work for a State Department and various three letter agency in the military and that kind of thing. I was born in Kenya, I was born in Nairobi, lived in a tiny like mud hut, basically on the shores of Lake Victoria over in a little place called Kisumu and literally lived out in the sticks and really didn't have much of anything that was out there, aside from what you could make or kind of like barter with with local communities and whatnot. And then later on, we lived in Honduras for a couple of years, which is down in Central America. And then I lived in Somalia. So I lived in Mogadishu on the coast till I was about, I would say, like 10 or 12. And my mother happened to be a computer science major from university. And so as she was going through her schooling, she was going through her courses, I just kind of like set along next to her and tried my best to follow along and read through textbooks and whatnot. But that was my earliest Introduction to Computer Technology was basically like sitting along going through these courses and going through the coursework with my mom as a little tike.

CF Oh that's so cute.

BP Very cool. Were you able to--were talking about this recently. But was it all in paper and all written down? Did you have a machine you could try to run the code on?

RC We had--I am going to date myself just slightly here--we had a 286 for those of y'all who remember the old--

BP Sure, yeah.

RC I am a little bit older than I look. But yeah, we had a 286 machine and then eventually, Mom and Dad popped for the old you know, the old 486 machine as massive step up. It was great.

BP Why is it 88--I remember my first like computer that was super excited. I was like, I think it was a Dell 386 It had like a DX or an SX or something. But why the 86? What's the 86 for?

RC You know, honestly, I don't really remember.

RD It's the chipset architectures, the x86.

BP x86 and they up it by 100 each year.

RC Yeah. And that's now the legacy holdover into into like, a 32 bit architecture and all that kind of stuff, right. But I remember that 486 was great because it had that math coprocessor. So it was like it can really it can really zip.

RD And you got that good super VGA graphics.

RC Absolutely. It was a big step up from the amber screens of the day, right?

RD Oh, yeah. 

BP Yeah, it have a disk drive or a CD ROM player?

RC No, it didn't have a three and a half inch floppy though, like it was--but no CD ROM drive, that came later.

RD Yeah, I'm the old man of the group. So I was talking the other day about starting on a Commodore 64 with a audio tape drive.

RC I had an Atari 1600 that had an audio tape drive on it. I remember like being like my mind was blown because he had computer based programs that were on the audio, they were on the tapes, but it would actually also play audio tapes, which I was just--I don't know why.

BP It was a useful functionality back then. Yeah, go get some pop music and write a program. 

RC Absolutely. But not at the same time. 

BP So you came to the US when you're around like 12, you said, and then yeah, where did you go from there in terms of computer science and programming? Were you working in high school? Did you do that in university?

RC Yeah, would continue to do a lot of that through high school, you know, kind of bounced around a little bit. As far as university is concerned, I never actually finished any any formal degrees. You know, I just kind of figured out that it really wasn't for me in terms of the like, the social and cultural scene and being in university. I think I would go back and I would do University today, right now, and I would have a blast. But that was not for like, you know, there was not for like, 16 year old me because I graduated a couple of years early from high school. So when I started my senior year, it was the shame of not being old enough to have a driver's license. And yeah, that was that was a little bit tough, right? Because I lived out in the middle Oklahoma, out in the middle of nowhere. And the only way to get around anywhere in Oklahoma is to you know, get your butt in the car and go drive around. So I did that didn't finish any of my university stuff. But I stuck with the programming side of things. One of my first jobs is kind of like a fresh, you know, wet face recruit kind of thing was to go to work for, for into it. I did a lot of phone support. I worked in the IT organization. I did a little bit of QA and did a lot of you know, grunt work, skip work, if you will. Basically like cleaning up IT projects and supporting customers supporting internal folks to get through, you know, the usual smorgasbord of TurboTax and QuickBooks and Quicken for those of you that are familiar with it. I spent a few years working for Disney and eBay along the way and eventually landed here.

BP Yeah, before eBay and Disney importantly, worked at a company called Ciber, C I B E R. 

RC Yes!

BP Very, very, very good. I like that a lot. 

RC I know, right? It's very on the nose. 

BP Yeah, that's really on the nose. Those are dot com days, those are early dot com days. At Ciber, or you know, Disney or eBay in those early days, what kind of languages and tools and technologies were you working with?

RC Really kind of span the gamut. That was early days and working in the web for me. So like, I basically started off doing HTML and JavaScript integration was kind of like integrating into a front end pieces for PHP websites back in those days, a little bit of classic ASP, not But you know, like VB script, like, we're going back a little ways, what else? A lot of C sharp along the way, probably the majority of my career was done in C Sharp, but you know, peppered in there, you got C++, he got a little bit of Java every now and again, things of that nature. But yeah, the vast majority of it was C++ or C sharp.

CF So it seems like you did most of your learning on the job, then, as opposed to like being in a university situation. That's really cool. I'm wondering, too. One thing I always, that I've done a lot in my career is, you know, when you switch jobs, sometimes it also means you're switching languages that you work with. And it sounds like you've done a lot of the same thing. So how did you manage that? Because I always wonder, like, how can I be as efficient as possible and learning a new language so that I'll be good enough at it to be able to like do my job well?

BP That's a great question. Because we get like--changing tech stacks is imitating to people I think.

RC Yeah, and I did a lot of that--to your point, Ceora. Like it was, it was like, just one to the next to the next. And honestly, I had to figure out a way, you know, not not to get too kind of nerdy about it. Right. But you had to figure out a way to abstract it, basically. Yeah, like, if you go down to basic concepts, regardless of what technology set you're talking about, whether it's Microsoft or whether it's open source, or what have you like Python, it really doesn't matter. They all fundamentally kind of work the same way under the hood. And a lot of it it just kind of comes down to do you understand the semantics? Do you understand the vocabulary basically, that you need to use to communicate with people and to communicate with the systems in that space? But the rest of it honestly is like, it's very kind of like, can you logically map out workflows in your head? And can you keep all of these things kind of relatively straight and secure? Right? I do feel like I had some kind of some kind of advantages, right? Because growing up overseas, I was a polyglot like I was speaking French and Swahili and Danish and all kinds of other Spanish all kinds of other things, right? Just as a normal part of my everyday life. So my mom was to tell the story. Like when I was two years old, I would come to come to work with her she worked in a in a nursing kind of center, like a first aid kind of center right? And it was her, it was a French woman and it was a Danish woman. So I would sit and work in this in this kind of nursing station and hear all these different languages being spoken around me. And I would kind of casually interchange like different words from different languages in the same sentence, because that's what I was hearing, right? Those were the words that were being spoken around me. So it really didn't feel all that unusual for me honestly to switch from one like technology stack to another, I got PHP over here, I got C sharp over here, and there's some syntax differences. But under the hood, they really didn't change. And once I got past that kind of like fear of the learning curve kind of thing and I recognized that the structure was mostly similar, then it really wasn't a big deal anymore.

CF We talked about this before with another guest. I think there's a huge connection between people who learned how to play instruments when they were younger, and people who get into software as they're older. I think there's like a connection there. And I also think there's a connection between people who speak multiple languages, and people who do software, because it's the same thing of like, transforming your thoughts into basically another language, whether that's music notes, or another spoken language, or a computer language. So that's really cool. You just confirmed my theory. Like, I feel like I need to write like a whole paper on this because that's really cool.

BP It's science now, we got it.

RD Do you play an instrument?

RC I don't. I tried my little heart out when I was a kid. Like I played saxophone. I was terrible at this. I couldn't, I just couldn't do it. Couldn't get past it.

BP But you could explain to me the circle of fifths, yeah?

RC Yeah. [Rennie laughs]

RD You just have that other layer of abstraction.

RC That's it. But yeah, you have to, like constantly translate in your own head. Right? It's interesting.

CF Yeah. And I think that that gives you like you said, like an extra edge, I guess you could say, when you're learning a computer language. I also like what you said about mapping things out. One thing I do sometimes, which may be a tip for people listening, who are in that phase, where you're like, maybe transitioning to a new tech stack, sometimes I literally will do that. I'll literally write down like the logic of whatever I'm supposed to be programming. Because at the end of the day, that's like the most important part. You can like, fill in the blanks with everything else. But sometimes literally just sitting down with a pen and paper. I feel like someone mentioned that they were like, writing out like programming. 

BP Yeah Cassidy said when she went to school in Spain, she had like to take computer science and take the test by hand. She was like writing out in infinite loops and stuff like that.

CF But it helps you to learn it really well. It does work. I mean, it's very tedious. But writing out that logic does like do something for the brain I feel like.

RD I mean, I think there are studies saying you remember things better if you write them out by hand.

RC Yeah, like my usual approach with that is like, I'll put in a big block of like, pseudocode comments at the top of like, whatever function I'm writing, and if I can understand it, if it's logical, if it makes sense, then I then I go in, I fill in the gaps on. Okay, how do this how do we turn this into code? Right?

BP So Rennie, I see, after that you did a lot of work at Blackberry. I worked for many years at The Verge. And so we were first and foremost, a smartphone review website, I spent a lot of time with people who had a lot of love with Blackberry. I missed it very much and read it for it's come back many times, maybe it's still gonna make a comeback? I don't know. But tell us a little about your time at Blackberry. And it seems like that was sort of the time when you went from being an engineer and a solutions architect to you know, a manager, director and CTO. So talk us through a little bit of that.

RC Yeah, absolutely. So BlackBerry was actually the acquiring company in that case, so I actually have a very short span of time that I was that I was part of that part of BlackBerry as a proper term, right. But that was that was a company called Adhoc that BlackBerry had acquired. That was a nine year stint startup, right. So I was one of the early employees, I can't even remember what my employee number was, like 12, or 14, or something like when I when I joined, it was like a tiny little office stuck in San Mateo, out on the shore in San Francisco. And I was there for nine years. And there was a really wide range of things that I did there. And it's very interesting, because I went from being, you know, a senior engineer hands on code, individual contributor, through being a manager and then switched back to being an architect at one point. I was the director of user experience of all things for a couple of years there, and then switched kind of back into like a Deputy CTO kind of role and worked for a Vive Seagull who was my boss at the time. Great, great mentor to learn from frankly, and I learned so much during that whole startup stint that it was, it was a phenomenal experience. I really enjoyed that. But the variety helped me, right, it doesn't help everybody. But the variety helped me to have you know, kind of that that very broad perspective on what people go through what they worry about, and kind of what the what the experiential elements are like, what what causes you friction and all these roles, right? So I just kind of discovered along the way that I had more of a passion for helping people through their problems in a professional sense. I got more energy from dealing with the people that I got from, you know, being hands on code all the time. I think that that's kind of a like there's a progression sometimes that people go through around what it is that they get energy from and what kind of tires them out. And I was lucky enough to pay attention to that. So that was kind of like the journey in a nutshell, if you will.

CF That part of career development is so important. Kind of like having a level of self awareness where you're like keeping track of what do I like and what don't I like so that you can make those transitions well, and like kind of, you know, make career decisions that fit you well. I think that's really cool. And I think a lot of people kind of like, oh, I don't think I can ever be a manager. I'm one of those people, I'm going to be totally honest. But I do think that it's interesting to hear about people who think that is like, really, really fulfilling work, because then it makes me think, oh, maybe I'm selling myself short. Maybe I should give it a try eventually, one day, just to see what it's like.

RC Oh, don't get me wrong, I was terrified by the prospect of like, oh my goodness, I'm gonna be, you know, who am I to tell these people what to do to do, and, you know, what happens if I irretrievably screw them up and the company in the process and everything else, right. And I think it was like, it was just kind of a matter of like, trusting the fact that I was already mentoring people, I was already, you know, kind of providing this, like a level of guidance and a level of even emotional support, right, because a lot of what you go through as a manager is not you don't help people, you know, as a director with your technical problems. That's not the wheelhouse, right, it's to make sure that you're organizing things appropriately from an organizational standpoint, giving them the tools that they need, and like you're, you're out there crashing down and breaking down roadblocks for people, right. Like, that's the mentality that you kind of try to approach things from. It doesn't always work that way. But that's how you try to approach it right?

CF Any tips for new or even not so new managers out there who are listening?

RC It's a very different thing from a career standpoint to manage people than it is to write code. That is, I tell people this all the time who are considering this, going into management is the most difficult career transition that you can make. Because it's no longer just about managing yourself and your own work and getting your own things done. It's now about multiplying yourself and making sure that everybody around you that's on your team has all the resources that they need. It can be a thankless job, right? Even if you're doing it well, and people don't, you know, people don't really recognize managers in that way, right. Sometimes they do, don't get me wrong. But a good manager that's managing, you know, a high performing team is often relatively invisible from the perspective of, you know, making sure that the team is getting everything that they need, and that the team is getting the visibility that they need, right? I kind of see that as part of my role is to kind of step back into the background. So if you like the spotlight, you know, maybe not the right kind of place for you to be. But if you like enabling the team, if you like making sure that everybody has everything that they need, and that's what you get your energy from, to me, that's the most important consideration, right? I had no idea that I wanted to be a manager. But I just kind of pay attention to this, like this idea of like, I would get super jazzed and super energized, when I would help somebody through a problem, they would recognize what the solutions were to those problems. And I had like some, you know, some small, you know, happenstance kind of, you know, experience to be able to help them with that. But like, I would come away at the end of the day with more energy than I walked into it with. So I was like, I should probably pay attention to that.

RD That's interesting. We talked to Sarah Drasner, a while back in the podcast, who was writing a book basically, for that, how to transition from, you know, engineering contributor to a manager. And one of the things we all talked about was like, there's no real pathway for that.

RC There's no training, either. 

RD Yeah. So how did you make that that transition? Was it natural from just helping and mentoring people? Or did you have to go out and find some resources?

RC Oh, no, I had to go out and find resources. And I think if I'm being, you know, kind of honest, and self reflective, I think I was probably a terrible manager at first. I was way too focused on execution, I wanted to get things done, you know, go, go go. And that's like, that's the mindset that you can do, you can have as an individual contributor, right is to really like put the pressure on getting things done, because you are the only person that's really directly impacted by that pressure. Right? So I think that I was like super hard charger, let's get things done, you know, rush, rush, rush, push, push, push kind of things, a manager, and I had to learn how to dial that down, you know, from an 11. Right, and really kind of figure out how to how to get people to get there on their own. As it were, right. But yeah, I had to go out and I had to advocate for myself, I had to ask for frontline leadership and management training. I had to go and find books. I'm a, you know, pretty voracious reader of books. And that was that was honestly part of like the autodidact part of educating myself as a as an engineer as well. But I had to take the same approach with, you know, with leadership stuff. And actually on my desk here, somewhere I've got, we'll plug a book here. It's by Will Larson. It's the Elegant Puzzle book, which you all have probably seen, maybe even read, but just some really great stuff in there. Just keep educating yourself and keep kind of going through it. But I was really struck by the fact that there really is no educational path like there's no, there's no support mechanism in a formal sense for the vast majority of companies to make that transition. It just doesn't exist.

BP I mean, now they're all these sort of like LinkedIn learning and I feel like it business schools, I've seen people, you know, offering courses and being a project manager and things of that nature. I wonder if internally at a company would start to make sense to pair that kind of transition with some of this online education, or at least some kind of coaching. You know, from somebody who's had that kind of experience. Rennie, I want to ask a little bit about your current role. What brought you to Stack Overflow? And what does your day to day look like here?

RC Yeah, I'm very mission oriented. As you can probably tell from my parents, and my upbringing. I fell in love with this idea of paying it forward, because I can't even begin to tell you, I'm sure this is a very common story of how many times my bacon has been pulled out of the fire by finding some solution to a problem on Stack Overflow, I wanted to have the opportunity to be able to pay that forward, kind of in a broader sense. I'm not a frontman, I don't like being the center of attention. And I've always found it very difficult to engage, like, in a personal sense, with some of the, like, the communities around Stack Overflow, for example. So I didn't really see myself in the kind of like, John Skeet, you know, answering all the questions kind of, you know, kind of role. But that coming to work for Stack Overflow and be part of this from, you know, like starting standing up and forming this, this platform engineering organization, has been that opportunity to figure out okay, how can I how can I scale myself out? And how can I pay this forward for other engineers and help them out along the way? That was kind of my focus.

BP Well, being scared to contribute on Stack Overflow, you're not alone, you're in good company.

RC So I've heard.

BP And so yeah, I guess like here at Stack Overflow when you use a platform, what does that mean? Are we talking about public platform?

RC So that's for us is all the common operating systems and services. So it's background type stuff, big, heavy lifting back end services. So it's not what we call Public Platform internally, which is to say,, but it's all of the building blocks, you know, what we really kind of talked about internally is, this is really about a it's engineering grease, right? So it's it's common systems and common services that enable the rest of the engineering organization from a product development standpoint, to accelerate the work that they do, right? So we're talking about anything that smacks of reuse, and reusability, whether it's a library or a service. So it's a pretty wide portfolio, actually, for platform engineering, that actually includes our design systems. So stacks, Everything that's like HTML and front end and presentation, JavaScript tier stuff, that's reusable component libraries, platform engineering handles that. We also provide all the databases, we provide all of the site reliability engineering, to make sure that all the infrastructure that we have is up and running. And that's kind of two ends of the spectrum. And then in the middle of all that we also basically build, operate and manage internal services for things like if we need caching as a service, if we need identity as a service, it's going to be used across the entire product ecosystem. Search as a service that will that will top bar that you conduct your search. And that is a shared piece of technology infrastructure. And our product teams don't have to think about reinventing that wheel. So if they want to use it, they go and they say, okay, we're going to use that search service, we're going to plug it in here, we're going to just go ahead and start to consume that right after we after we feed data into that search algorithm. So it's everything that's reusable. From that perspective.

RD I'm curious, like you have a lot of things that are depended on by a lot of areas. How hard is it to change things in the platform?

RC Well, in current state is extremely difficult, right? As I'm sure you all have gone through in prior podcasts, right? A lot of our architecture, and a lot of our systems are very vertical, right? So try to stay away a little bit from from the M word, the monolith, right. But there is, there are definitely characteristics of that in place in today's world. So a lot of what we're going through right now--because the platform engineering organization is is relatively new at Stack Overflow. It's only been around for about a year, year and a half. And our focus has been on essentially strangling out the Component Services from that monolith. Some of them are more kind of tangled up in the weeds than others. But you know, that's that's been part of our strategy with that is to basically identify piece by piece, what are those components services, what are the kind of like the big broadly reusable bits and pieces of our existing infrastructure and take that, we're going to carve it out one by one, and we're going to establish standalone services, because that's our first step. And then what you do is, is you establish a set of interfaces between all those services, right? So if somebody wants to come and consume search, this is your API. This is your library. You don't have to know anything about the way that it's implemented on the back end. So if we want to make changes to that, we can do that as long as we still honor the interface that sits in front of that, right? So that's one strategy for that. And then if we need to add functionality if we need to, you know, replace things with change that interface, that's a little bit more of a longer kind of roadmap kind of question, right? So if we need to, if we need to make a breaking change, right, then we need to, you know, kind of telegraph that in advance, make sure that the you know that all the communication is happening around that. But again, it's all internal. So it's not like, it's not like we have dependencies on the outside world here that we're there, we're trying to maintain. It's a much smaller audience.

CF That sounds like a lot of big decisions that need to be made. [Ceora & Ben laugh]

BP Sounds stressful, right? 

RD How much of this is coming through because of the switch to the cloud? Because I know, we were, you know, running on two machines for a long time.

RC Yes, the great debate, right? Do we do we do it on a fewer number of, you know, smaller number machines? Or do we, you know, do we spread that out? I think a good chunk of that is the cloud. But in equal measure, honestly, it's the growth of the organization, right? If you want to have multiple teams that work on specific functional areas in parallel and have kind of like the minimum set of like cross functional dependencies, right? You want Team A to be able to work without necessarily being blocked by Team B, you need to have systems, you need to have architectures and you didn't have processes in place that allow them to do that. And that just doesn't exist in what we have built up from a data center architecture perspective, right? So a big part of this, honestly, is just enabling the teams to be able to operate in parallel that way, without really having those cross team dependencies or try to minimize the cross team dependencies.

RD You almost make it sound like microservices are less of an architectural decision and more of an organizational decision. 

RC I think sometimes they go hand in hand, to be honest with you. But yeah, that's probably not very far off the mark, honestly. Now, I don't think that we're gonna go necessarily into microservice hell, but you know, we certainly want to navigate towards the services end of things, right?


BP Well, everybody, thank you so much for listening. As we do at the end of every episode, I'm going to shout out the winner of a lifeboat badge. Somebody who came on Stack Overflow, found a question with a score of negative three or less and gave it an answer. That answer got a score of 20 or more, and the questioner has a score of three or more. So saved from the dustbin of history. Thanks to vinzzz with three Z's: 'create an array of random numbers in Swift'. That was awarded three hours ago. So if you need a little help, doing random numbers in Swift, we got you covered. You can check it out in the show notes. I am Ben Popper. I'm the director of content here at Stack Overflow. You can always find me on Twitter @BenPopper. Email us with suggestions or questions and if you like the show, please do leave a rating and review. It really helps.

RD I'm Ryan Donovan, content marketer here at Stack Overflow. I edit the blog and the newsletter. I am secretly on Twitter @RThorDonovan. If you have a great idea for a blog, please email us at

CF I'm Ceora Ford. I'm a developer advocate at Apollo GraphQL. You can mostly find me on Twitter because I spend way too much time there. My username is @ceeoreo_.

RC And I'm Rennie Clayton. I'm the Senior Director of platform engineering at Stack Overflow. Unlike all the fine other folks here. I do not have a Twitter handle and I'm not really publicly facing, so.

BP They'll find you on GitHub. 

RC That's right. [Rennie laughs]

BP Alright, everybody. Well, thanks again for coming on. And everybody, thanks for listening. We'll talk to you soon.

[outro music]