CppCast - From Refactoring to (physical) Relocation

Episode Date: May 30, 2025

Kristen Shaker joins Timur and Phil. Kristen talks to us about her C++ on Sea keynote about the C++ interview process, her previous work at Google, and why she has made a slightly unusual career change. News libc++ removed the base template for std::char_traits "how to break or continue from a lambda loop?" - Vittoria Romeo Results from the 2025 Annual C++ Developer Survey "Lite" (pdf) Links C++ on Sea schedule (with Kristen and Timur's keynotes) BrontoSource "What Can We Learn From the Results of C++ Community Surveys?" - Anastasia Kazakova "Sorting Resumes" - Joel Spolsky (introducing the idea of filtering) "How to Build Your First C++ Automated Refactoring Tool" - Kristen's CppCon 2023 talk

Episode 399 of CppCast recorded 28th of May 2025. In this episode we talk about chart rates, how to break from a lambda inside a loop, and the results from the annual C++ Developer Survey. Then we are joined by Kristin Schaiker. Kristin talks to us about fixing the broken engineering interview process and about C++ refactoring tools. Welcome to episode 399 of Cppcast, the first podcast for C++ developers by C++ developers. I'm your host, Timo Dummler, joined by my co-host, Phil Nash. Phil, how are you doing today?

I'm all right, Timo. How are you doing? I'm good, thanks. I'm actually really, really good. Weather is good. Snow melting yet? The snow has melted actually about a month ago. So yeah, no, it's actually, this is like the week where we're like nature just kind of explodes. Because like, I guess the growing season up here in the north is quite short. So at some point in May, like,

you go from like, everything's kind of barren to like, boom, everything's green, like within, I don't know, a few days. Life will find a way. That just happened like a week or two ago. So now everything's green. It's pretty great. What about you, Phil? Any traveling coming up? That's usually like, what you're talking about at this point? Or is there anything else exciting going on in your life right now? Yeah, well, we're nearly done. So I did Swiftcraft last week. Oh, how did that go? like what you're talking about at this point? Or is there anything else exciting going on in your life right now? Yeah. Well, we're nearly done.

So I did Swiftcraft last week. Oh, how did that go? Yeah. Well, that actually went really well. We had Doug Greger opening, the opening keynote. So Doug, we had on last year on episode 387, last July, talking about Swift and he opened the Swift conference. So, so that was nice.

But we're only a few weeks away from C++ on C as well. So now I'm the froze of preparing that. We've actually got two keynote speakers here today. So the, the bus factor is quite high. And the conference organizer as well. Right. Well, yeah, exactly. Exactly.

And our third keynote speaker, Herb Sutter, is also going to be joining us for C++ London, just in a couple of weeks. So yeah, I'm in the middle of a lot of preparation at the moment. But apart from that, it's actually, it's quite nice to think that at the end of that, then I'm sort of pretty much done for the conference season. So yeah, I'm very excited about this. I have already thought about my keynote, but I have to admit, I have not yet started making slides. I don't know, Kristin, are you a bit further along? That makes me feel so much better. So like, okay, so like if, if, so I've known about this keynote for months.

And like, if like we have a graph and like the, the Y axis, the X axis is time that I've known about the talk. And the Y axis is like time I've spent working on the talk. It's like nothing, nothing, nothing, nothing, nothing, nothing, nothing, nothing, and then like a big increase. But like, in terms of time I've spent being anxious about the talk, it's just been up here the entire time. So I have like, I have a, I have most of my slides done. But I haven't like, I haven't fully codified the way I'm going to articulate all of my points, if that makes sense. I have the flow of the talk. Yeah, I think we're in a similar point. I kind of also I know what I want to say and

in what order and stuff, but like I haven't quite fleshed it out yet. And I'm also a bit nervous because I think this is kind of the most ambitious talk I've, I have done at a conference or one of the most ambitious for sure. And it could go horribly wrong. So I'm like, ah, let's see. Why do you think it's the most ambitious talk you've ever given? Because I'm going to be talking about all the undefined behavior in C++ and how to get rid of all of it. And also about how to talk to, like, people and like make people agree on things. So like something that's not just code, which, you know, it's kind of my comfort zone. So I'm kind of stepping out of my comfort zone and I'm talking about people and how they interact, which is

And cats. And cats. Yes. Yes. I need to think about how to, yes, there were some cats in there too. Yeah. But this is all good inside baseball, but you shouldn't tell the conference organizer this. All right. Good. So let's move on. At the top of every episode, we would like to read a piece of feedback. This time we received an email from Dominic regarding the last episode we recorded with Jonathan Wakely. So Dominic writes, the Libs Tc++ episode was really helpful for me. I've been struggling recently to figure out

why some libraries that were compiled in a Yocto environment were failing to link on an Ubuntu 22.04 machine, and it turned out it was because Yocto was using a later glibc. Jonathan's explanation clarified to me the reasoning for compiling on the oldest supported target. I really wish there were some linker flag to specify a maximum symbol version, like with macOS minimum deployment target. I really wish there were some linker flag to specify a maximum symbol version like

with macOS minimum deployment target. A suggestion for a future episode, build systems and meta build systems. I've been learning CMake and package conf versus package config and everything seems so convoluted and full of magic variables and properties. I'd love to know your thoughts on what you think is the easiest build system to work with. Thanks for making such an awesome podcast. Well, Dominique, thank you for the feedback. So what do you think is the easiest build system to work with? I don't actually know, to be honest. Like every build system I ever worked with was extremely painful.

So I really like Bazel. Yeah, I hear good things about Bazel. Oh, yeah. I really, really like it. So there was actually, I'm just looking at our own website. Like there was a Bazel episode a few years ago, uh, back when Rob and Jason was still running the show. I should probably go back and listen to that.

We also had a Bazel talk at my local C++ Helsinki meetup. That was also quite interesting, but I have never used it myself. It seemed to me that it was like very good if you have like kind of cross language stuff going on. But if you're just doing C++, it's kind of not quite yet towards that. I used it pretty exclusively for C++. I like although like admittedly, like I was using it in a mono repo. So it's like I, I don't know how it would fare in more segmented repository environments. But I thought it was really intuitive and easy to use.

And I liked it a lot. So yeah, we'll think about something along those lines. We haven't done an episode on build systems, I guess, in a little while. Yeah, it's about time. So thanks again, Dominic for this feedback. And to everybody who's listening, we'd like to hear your thoughts about the show. You can always email us at feedback at cppcast.com. And joining us today is Kristen Shaker. Hello again, Kristen.

Hi, I'm sorry, I probably wasn't supposed to say hi in the beginning. No, no, no, you were. That's all good. We don't have a clearly defined entry point for the guest. It's kind of every time is a little bit different. OK, OK. So we're cool. So Kristin was previously a staff software engineer on Google C++ core libraries team, where she was responsible for making the C++ portion of Google's code base

extensible, maintainable, and understandable by a state of the art refactoring tool's targeted guidance and documentation on complex C++ topics. Kristen is a founding member of the New York C++ Meetup Group and serves as chair of the board of the Boost Foundation. She holds a Bachelor of Science in engineering in computer science from the University of Michigan. Kristen is currently a real estate relocation specialist dedicated to helping software engineers

seamlessly transition into life in New York City. Kristin, again, welcome to the show. I think I'm saying this too often. We should rework this document. Yeah, I also have another random update. So I'm now an early advisor for a startup that is building end to end solutions to incrementally update old code bases and keep them clean into the future. It was founded by a couple of my colleagues, ex colleagues at Google.

It's called Bronto source. So that's cool. It's up and coming. You should definitely check it out. They're leveraging a lot of the things that we learned, maintaining the Google code base for other code bases, large code bases specifically written in C++, obviously that have a lot of legacy code. We might talk a bit more about that when we get into the discussion. But I did have one quick question for you from your bio, because there's one thing that we're

not going to be discussing. And we just happened to have been talking about it before the show, but we didn't get a chance to fully discuss it. So I'll take the opportunity now. So I was asking you what your role was now with the New York C++ Meetup group. And what you started saying actually was quite interesting. So what was your role there now? Yeah. So, okay. My role in the New York C++ meetup was very on-brand for me in general. So in the beginning, I just helped organize the actual human beings that were responsible for organizing the meetup, getting people together who had mentioned that they were interested in founding a meetup, posting at my apartment and being like, how are we actually going to make this happen?

Dan Katz and Nick DiMarco were the real spearheads behind the actual organization of the events. But I still go to all the meetups because all my friends go. So now my role, I guess, is an enthusiastic attendee. Oh, and I did give a talk there once. Okay, nice. But what is interesting, you're involved in the property side of it right from the start. So that's going to segue nicely into some of our discussion. That's funny. Yeah.

All right. So we will talk about all of this more later. But first, we have a couple of news articles to talk about. So, Kristen, feel free to comment on any of these if you like. We've got three news items today. The first one is something that I found on Reddit the other day. One of those rare cases where a standard library implementation removes a feature. And so libc++, which is the Clang standard library, removed the base template for std char traits, which is the

traits thing that you need to specialize if you want to use things like std string with your own character type instead of char and char 80 and whatever the standard offers. And so I stumbled upon this actually in the Xcode release notes, because Apple was documenting. Yeah, we don't support this anymore. But then it turned out it's actually an upstream change from libc++. So it's gonna affect not just Apple people, but like everybody who uses libc++.

So yeah, if you're using std chart traits in your library or in your program with any like character type, other than, you know, char w, char t, char 8t, char 16t, char 32t, I think that's all of them. So if you like specialized chart rates on like a custom character type, then then that's just going to stop working. Like, and so they did this. Um, so actually I think it's actually going to stop working because it broke

so many people that they kind of backtrack now. And I think now they're going to bring it back and say, it's just deprecated instead of just not there anymore. So you get a warning instead, which you can turn off, I guess. But yeah, anyway, they did this because for some types, that base template, you know, would always be incorrect in like non-obvious ways, which would cause unexpected and very difficult to detect undefined behavior, which these days people are not very fond of. difficult to detect undefined behavior, which these days people are not very fond of. So they kind of remove the whole feature to make sure that you don't run into that particular type of undefined behavior.

And that is actually conforming. This is why they could do it, because the standard, the C++ standard does not mandate that the base template is actually there. So they can remove it and just provide the specializations for char and charit and so on and so forth. And still like say that they're conforming with the standard, but it is obviously a breaking change.

And yeah, I actually do remember that like at a, you know, big music tech company that I shall not name where I used to work many years ago. Like we did literally have this, we had like our own string type, which was in actually inheriting from the string, which something you shouldn't be doing, but like there were reasons why that made sense at the time. And then that's the string was specialized also on a custom. Cha type, which is not any of the standard ones that you would use for char. And there were like reasons for it, but like, they

probably have long ago, we written all of this stuff. But like, yeah, I get that, like, there's other people like doing these things, and that's just going to not work, or like, at least be deprecated. And so now the question is, is that a good thing? Or is that a bad thing? Like, what do you think? This is definitely a Hyrum's law at play. Something that was never actually specified, but people rely on it anyway. And now, of course, they're broken because of the change, but yeah, the problem was not the change itself. It was the fact that it was introduced with no warning, I think. So going back and marking is duplicated is the right approach. And when I first

saw this, I was thinking, well, you well, it all seems a bit esoteric. Who's this really going to affect? And I remember all those people that are using string as a container type rather than something to represent text. And I imagine all of those are currently broken with this change. Yeah. And as I said, like I used to work in a fairly big code base that actually did use the string specialization on a custom character type as the string class for like the entire company.

Do you think the customization was justifiable? I mean, this was like, I was like not a senior developer at the time. So it was not my decision, but I wouldn't do it this way today. That's that's what it that way. I generally support changes that cause people to second guess non idiomatic uses of standard library features. But if you are doing something weird, why are you doing the weird thing? Do you really need to do the weird thing?

Or like, is there an idiomatic way to do the thing that you want to do? And if so, you should do it. And I think like, yeah. an idiomatic way to do the thing that you want to do? And if so, you should do it. And I think like, yeah. So here's the thing. Like, yes, you're right. And this is what I would tell everybody today as well. But like some of this code was written like in the nineties when like the standard library was like, like either not there on your platform or like the implementation was like really crap. So people just rolled their own

stuff and then kind of they're stuck with it. So I'm pretty sure actually that company rewrote their string thing, like at some point, but like, yeah, I don't know. I don't know what other reasons people have to... My other hot take is that we should be continuously upgrading legacy code bases so that we are not in positions like this one. If only there were some tools that could do that. If only there were some tools that would help people do this sort of thing in their large legacy code bases. Maybe we'll get to that. We will get to that.

Let's just quickly cover two more news items because I think they're interesting. I'm going to try and not dwell too long on it. I stumbled upon a new blog post by Vittorio Romeo. And Vittorio is great. He writes good stuff. So I started reading it. And yeah, it's kind of a neat trick. So it's about the problem of, so it's called how to break or continue from a Lambda loop. And well, essentially the problem is, what do you do if you have a custom data type? Like you have your own, like, I don't know, node-based, tree-based, whatever weird, like not quite like a vector or whatever data structure.

And then you want to let the user loop over all elements without exposing like how the data structure is actually structured, how this loop would actually look under the hood, whether you're looping over nodes or something else. You don't want to expose that stuff, but you still want to give the user a way to loop over all the elements.

And I thought all my C++ developer life until now that the way to do this is to implement an iterator. And it is, and now that the way to do this is to implement an iterator. And it is, and that is the way to do it. But Victoria points out that sometimes that's not what you want to do because that's a lot of boilerplate, which anybody who's actually ever implemented a standard conforming iterator knows that it is a lot of boilerplate. Sometimes you don't want to write that. And so there's at least two more options. There's one which is you can do it with a coroutine, basically have a generator like thing that just yields like a reference to the next element, which is very elegant. But apparently, and I also didn't know this, the code gen for that

is like really bad. Like, it's not going to be fast. Well, that's relative. I mean, that's relative. And it depends on your code and you have to, and blah, blah, blah, of course. And I somehow thought that that would be fine today. Coroutines were pretty lightweight. Once you allocated the coroutine frame, it would be pretty lightweight. But apparently, it kind of depends, and often the co-gen is kind of not great.

So then Vittorio says, well, there is another solution, which is you just implement a, you implement that loop kind of internally, that loops over all the elements and whichever way you have to do this for your data structure. And then you expose that in a function that says, for all elements, and then that takes a lambda. And then internally, you're going to do the loop

and then invoke the lambda on every element. And this way, you don't expose the loop, but you give the user a way to pass a lambda, and that lambda the loop and invoke the lambda on every element. And this way you don't expose the loop, but you give the user a way to like pass a lambda and that lambda is going to be invoked on every element. Right. So that's super lightweight, very cool solution. But the problem is like, you can't then, you know, the user can't then break from that lambda, like, like it wouldn't work because like they don't see the loop.

So they can't like break and break. So how do you implement break if all you're given is like a lambda and then on the other side you're writing this loop and that invokes a lambda. And so basically it's a blog post about various ways to do that and also how it affects code gen. It's kind of a neat trick. I thought that was interesting. Yeah. And Vittorio is not wrong in anything he said. And I think it's worth reading the article. But I think you have to start from a position of, you know, I'm working on code where I really cannot afford any possible overhead at all. In which case, yeah, the solution is coming up with probably about optimal. But if you can afford just a little

bit of overhead, the co-routines approach, if you can use just a little bit of overhead, the coroutines approach, if you can use particularly C++23 generators, is so much simpler, easier to follow, easier to understand and reason about. But I'd always start with that and then optimize as necessary over the top of that. Interesting. And if I really did need to optimize server, I would probably consider writing the iterators. Right. Because I think that'll also make the usage code more uniform.

I think you would need proper benchmarks comparing all three approaches. Yep. Maybe somebody wants to put that benchmark together and send it to us. Some homework. Yeah, that would be cool. So the last news item for today is I mentioned last time that the annual C++ developer survey light for this year was open. Actually turned then out that by the time we aired the episode, it was no longer open. So apologies for that. And now not only is it no longer open, but also the results are out. And so you can, you know, they're freely

available as a PDF. You can download them from isoCPP.org. We will put the link into the show notes. And I was just kind of scrolling through that this morning and it's like really interesting. Like what I haven't done this morning is to compare it with like last year's survey, but this is kind of where it gets really interesting or comparing it with like one of the other two big CSS surveys that we have. Yeah. I like the JetBrains one and the meeting CSS one. But I was just kind of scrolling through like where we are now according to the survey, like, and there's really, really interesting things where I thought, oh man, like, we're kind of living in a little bubble here. Like most CSS developers are not doing, you know, what I'm doing at these or, you

know, what some of the people I'm talking to very often are doing. So, so just to give you a few examples. So the most, I mean, that's probably isn't surprising. Um, there was a question like what platform you develop on and the most popular platform to develop for, but C++ is Windows desktop. And apparently like two thirds of all C++ developers develop for Windows desktop, which is a lot. Right? I was like, Whoa, okay. Yeah, interesting. So Linux desktop is the second place and Linux

server then embedded, and Mac is already quite distant, like 23%. And then even more distant are like the mobile platforms like Android is 12% and iOS is 7%. And then game consoles are at the end. So in terms of just like, how many developers develop for this platform? Yeah, that's kind of where we are. The other thing is what kind of project you're working on. And the most popular kind of project that people said they are working on when they write C++ is hardware and internet of things.

And that I thought was also like interesting because we kind of live in a little bubble. You write like libraries or we work on like, no load, like I used to work a lot on like low latency stuff and like, I talked to a lot of people who do low latency stuff. Right. to work a lot on low latency stuff. And I talk to a lot of people who do low latency stuff. And apparently, the most popular thing for which you use C++ is hardware-related stuff, which I have actually never worked on, except a little bit at one company. But yeah, it's interesting.

So 84.2% of all C++ developers use CMake. I'm pretty sure this number is going up. So CMake is more and more becoming just kind of the industry standard. 43.2% of C++ devs are now on C++ 20. So that's good. 26% are on C++ 23 already. So that's also good.

That was an interesting one. So this year, there were lots of more questions about AI and turns out the vast majority of C++ devs, they rarely or never use AI tools. Still. So what was that? So much interesting stuff there. The most popular second language for C++ developers is Python. That's not too surprising.

Followed by C and JavaScript. IDEs, I think the same picture as we have seen for a few years already for quite a while. Market Lead is Visual Studio, then closely followed by Emacs, then closely followed by Visual Studio Code and C-Line. Then there is a bit of a gap, and then Vim, and then a bit of a gap and then them and then a bit of a gap and then everything else. GCC is the most popular compiler still, but MSVC is not far behind. Clang is a little

bit behind. So it's actually interesting because Clang is by far the compiler that I look at the most, especially because it has all of this tooling around it. But it's actually out of the three major ones is like the third, it's like in third place in terms of how many people use it. So I thought that was interesting. Yeah. So there was one question that has disappeared, which are the most annoying pain points in C++? Which used to be like package management, build system, build times. And then, you know, memory safety was somewhere in ninth place, I think, last year.

This year instead, there were a few questions just about memory safety. How much you care about it? Yeah. 41.6% of C++ developers think it's important. 36.2% think it's essential. 20% about 20% don't care. Yeah. So lots of numbers.

I think that's interesting. What do you think? Definitely very interesting. The one thing which I think is really to keep in mind to frame all these numbers is that they do their survey, is she then validates it against the other surveys and then tries to, you can't completely remove any of these sort of biases, but tries to sort of get a more balanced picture. So in particular, if you look at the, how many years of programming experience do you have overall? More than 40% of people said they have more than 20 years experience. I don't think that really reflects the overall demographics. So bearing in mind, it's skewing towards slightly older, more experienced people

who tend to visit quite a low-level focus site like ISOCP.org. Then you can interpret the other statistics with that framing. Still means that we are living in a bubble. If that may be a bubble within a bubble. Right. No, it's a good point. Actually, I think Anastasia even had a talk about like how you compare these surveys and where the biases come from and stuff. I don't know if that was, I saw it, I think at a local meetup somewhere.

I'm not sure if that's on YouTube, but maybe we can put a link. Yeah, I think I've actually done that a few times. I'll dig up a version and put a link. All right. So that concludes our news items. So we come to the next part of this wonderful episode, which is we're going to talk to Kristin Schaiker. Hello again for the fifth time. Welcome to the show. We are very welcoming here. Yeah, I see that. I like it. Hold on, I'm just trying to get it. It is so good to have you on the show. Finally, I think I have kind of approached you a while ago. Hey, don't you want to be on CBPcast? I think I was not persistent enough, but like finally we managed to get you. So thanks again for your time and being here.

Yeah, for some reason you wanted me on the show. I mean, I'm very flattered. again for your time. And for some reason you wanted me on the show. I mean, I'm very flattered. All right. So we talked already about CpnC and the fact that you're giving a keynote there. And we discussed all of this at the very beginning. But do you want to just tell us or our listeners, in fact, a little bit more about what it's actually about? Yeah, sure. So at least I found that this is a pretty ubiquitous experience, but I will talk specifically about my experience in framing this talk. But I believe that one of the most frustrating aspects

of being a software engineer today is going through the interview process. I think the system is fundamentally flawed in a very insidious way, but not in an irrevocable way. I do think there are ways to fix it. I think it's currently set up such that there's one skill set that has sort of become the entire signal by which we assess engineering excellence. Even if it's a useful signal, it's still only one signal.

And if it's not a useful signal, then we're in even more precarious position, right? Like, and you know, of course, like I'm talking about like the sort of like leak code hacker rank coding challenges that we generally encounter, like both as part of like the initial screening process or it was like a take home test. Like it's sort of like the precondition by which you can make it to subsequent stages in the interview process. And often it is a fundamental aspect of all of the subsequent stages of an interviewing process.

The talk discusses what the fact that this has become so prevalent as part of the interview process means for the engineers that are interviewing. It also discusses what that means for the companies that are hiring. Like how does it affect our ability to recruit top talent? And then it kind of discusses, you know, is there a path forward from here? The spoiler alert is I think there is, otherwise, like it would be kind of a depressing talk. It discusses kind of like what are the useful signals that we can collect? Like what will be a better mapping from interview to job performance? And, you know, how do we collect those signals? And I've wanted to rant about this topic for so long. And so when Phil offered me the opportunity to give a keynote, I did feel like I had some level of moral obligation to discuss it.

Because like, I can rant about it all I want, but if I rant about it on a stage, maybe somebody might listen to me. I don't know. That's kind of the high level overview. Is that like a helpful summary? Yeah. Yeah. Thanks for that.

I personally blame Joel Spolsky for this problem. I don't know if you know the article he did back in his heyday as a blogger. He wrote an article on hiring. The big problem they have is they have so many applicants that you need some sort of easy filter to get rid of most of them straight away. One of the filters he talked about was requiring that they have a degree. It doesn't mean you actually need the degree to do the work, but it's a filter because to get a degree degree you've got to go through some sort of process to get there that is going to remove some people from the application pool. So I think this idea of having an easy upfront filter then really caught

on, not necessarily because of Joel Spolsky, but I think that was the thinking at the time that you would need to make the job easier for the hiring people. So let's do something that we can easily automate, maybe get recruiters or somebody else to actually administer on our behalf before we actually waste our engineers' time interviewing people. So if we took that out of the equation, then how do we cope with the number of applicants? That's a really good question and definitely something that I have thought about and will probably now add to the talk. Maybe we should discuss this offline.

I mean, obviously there are aspects of this that are open questions. I do think that part of this is kind of, I don't know how much of the talk I should divulge in the in the podcast. Like, I have thoughts on this. Is that enough? We don't have time to cover all of it. Okay, I have thoughts on this. Yeah, I have a thought.

Go for it. I have a way to fix it. All right. What's the way to fix it? Ah, well, you want to leave that as a big review? I want to leave it as a review. I want to leave it as a review. Come to the conference.

You will find out. No, I will sell you a ticket so you can find out the answer to this question. I'm very, very curious. I really want to see your talk. Uh, because like I've been kind of on both sides of this. Like I, I obviously have, you know, done, uh, job interviews, like in order to get a job as a developer and then, you know, whenever it was like, Oh, but now you have to like implement Merch sort on a whiteboard. I'm like, come on, man, like, really? And like, I just don't get that. And I'm not good at that either. Right. On the other hand, like I have seen the other side of this where like at multiple companies where I worked, like I was hiring people and I was responsible for hiring somebody who can do the

job. And I've been to these situations where like you give them like a really simple, like they have a brilliant CV, like they're like at a master of computer science here, everything. And then you ask them, can you like write a loop that that does search and replace on a string or something like this? And they just have no idea. And it's kind of like, yeah, well, if you can't even write a very basic loop that, I don't know, removes elements from a vector if they're odd numbers or something, then, you know.

So how do you? Yeah, I don't know. I have no idea, like how to approach this problem. So I will go to your talk and I will learn about it. So so thanks. Yep, I'm definitely looking forward to it. Yeah. So so you're not actually Kristen, you're not actually

working in C++ anymore, are you? No, I am not. So do you want to tell us what you're actually doing now? Yeah, yeah. So this is going to be like, I mean, it sounds shocking when people, when I tell this to people that don't know me, and I tell them like, Hey, I was a staff software engineer at Google, I worked there for eight years, like, yada, yada, yada. And then I tell them what I'm doing now.

They're like, wow, that's crazy. Why would you do that? And when I tell that to people that know me who have like, kind of like, you know, developed with me, like in New York city, they're like, oh, that makes so much sense. Um, so that, that might give it some context. Um, so I, I'm like, I'm a real estate agent in New York city. So I, I'm a relocation specialist.

I like somewhat specialize in helping software engineers transition to life here. But I do just generally help people buy, sell, or rent in New York City. You can learn more about it. There's a little thing where it says, feel free to promote your business. I'm going to do that. You can check out my website. It's just www.shaker.nyc. I'm also on Instagram and TikTok, so you can find me there. But that's what I'm doing now. Well, that's cool. So I guess there's lots of, you know, software engineering jobs in York. So if you're listening to this and you want to relocate to New York for your next C++ job, then, you know, go to Chris's website and then she's going to sort you out with a place to stay. And use code CPPCAST and we'll get a bit of a kickback. All right. So Kristen, so how's that going for you?

Oh, it's great. I love it. Like a home is one of the most important things in somebody's life. So it's really nice having this sort of very direct and measurable impact on somebody's lived experience. So I love that aspect of it. I just like love relationship building. I think that is part of like where a lot of my success in the software engineering field came from in the first place. But I basically just get to do that on hyperdrive. In real estate, it's just constant relationship nurturing and building and meeting new people. It's also really exciting because there's a lot of opportunities in this space for somebody to come in with a technical approach. And so understanding and discovering all of those aspects is really exciting.

I've got a ton of random ideas for ways that things can be improved. And so I'm hoping that in the next handful of years, I'll get to explore that a little bit. And yeah, it's a lot of fun. And I'm really enjoying it. And I put some people in some great spots. It's I really like it. That sounds great. It sounds like you're having a good time. How did you decide on making that? It's obviously like quite a big career change. Like what led to that change? Like how did you make that decision? Yeah, it's actually kind of apropos to the talk, I guess. So after I made staff, I was kind of sort of expecting to be happy and like fulfilled. You know, it's like a big sort of moment in the career progression of somebody in the software field. Yeah. But it really didn't end up making a difference in terms of my day-to-day satisfaction.

Like there was a momentary blip where I was like, okay, good, like I've accomplished this thing. But in terms of like feeling every day, like I was living the life I really wanted to, I don't think, I wasn't there. And I thought about potentially like trying out a new job, maybe a new field, maybe a smaller company, like those sort of things. Like one does not typically just pack up and say the last 10 years of my life, I'm going to sort of like, just be a no-op over here and I'm going to do something completely

different. But when I thought about whether or not it was more intimidating to start something completely from scratch in an industry that I knew nothing about or prepare for software engineering interviews, I figured it's easier to just become a real estate agent. I figured, easier to just become a real estate agent. Ha, okay. That's very interesting. Now I'm looking even more forward to your talk. Yeah. The barrier to entry is just so high.

You can't try anything out in the field. You can't be like, hey, let me... I wasn't enjoying this. Let me kind of see what it's like over here, unless you are very locked in on it. And I was already at the point where I was sort of wavering, you know, like, do I want to do this? Like, do I want to continue to do this? Like, there are aspects that I like about it, there are aspects that I don't like. But like, when you think about the opportunity cost of spending all of the time preparing, it's very high.

So if you're not steadfast and like, yes, this is what I want to do for the next 20 years, then sometimes it just makes more sense to try something else. Yeah. I can relate to that story in a way, although it's a slightly different path, but I sort of moved out of software development, first of all, into developer advocacy, which seemed like a good change for a while, but then I realized that wasn't quite doing it for me either. Then I left my full-time job last year and I'm a conference organizer now. Of course, it's software development conferences and I actually still write a lot of code to support that. But it has been a bit of a sideways move that I can relate to

just being more in control of what you're actually doing, I think. Yeah. Yeah. I like, I like building things that are sort of like on my timeline and also like, like everything that I create, like it builds upon itself. Whereas like at a large company, sometimes you just feel like you're moving the blocks laterally as opposed to stacking the blocks on top of each other. So I'm really enjoying that aspect of it as well. So you still writing any code? Okay, so yes, but Python. Don't hate me. I'm doing the same thing. So during the beginning when Phil asked you a question about your bio,

you mentioned some project was a Brontosaurus or something. Can we talk about that a little bit more? It caught my attention, but I didn't quite get what that was about. I should probably have asked Matt if it was okay to discuss this on the podcast. And you should also talk to Matt and Andy, because they're going to be much more articulate on this topic than I could ever be because they're like in the weeds of it. But they took a lot of the lessons that were learned at Google refactoring large code bases. And they have built refactoring tools that can be sort of ubiquitously applied to any legacy code base.

And obviously that's for C++ refactoring. And it's really cool. You should definitely have Matt or Andy on the show. I'm just sort of like an early stage advisor. I'm not like full time at the company. They are the ones in the weeds. But there's like definitely exciting stuff happening. Yeah, I'm just looking at the website. So it's Bronto source actually. Bronto source. Yes. Not not Soros, but source Bronto source.

I'm looking at the website automatic COS or such reflecting at scale. Yeah, that that looks actually really interesting. Yeah. First time I hear about this, but it does look very interesting. I will I shall look at this more closely. Yeah. And if anybody has a legacy code base that they would like to not be a legacy code base, they should definitely reach out to Matt or Andy. That name also I've heard this name somewhere before Matthew color condes like a bell like he's given talks at a lot of the conferences. Okay, okay. Well, great. Thanks. So that's that's really

interesting. So so that's you can stick the website in the show notes, right? That's a thing people do on podcasts. Yes, yes, yes. So so it's it's for refactoring super sauce, but it is written in Python. No, no, no, no, no, no, no, no. When I write Python, it's to do data analysis for real estate related things. It's to provide people with a more in-depth data visual or viewpoint of what they're looking at to purchase or to sell. This is not something I'm actively like working on writing. I do think like a lot of it's written in Rust.

It's like C++ and then also some Rust. Nice. That's interesting. So when you are working on your Python code, do you use property based testing? I don't, I don't know what that means, but I feel like it's a joke. I think it's another Phil dad joke, isn't it? Let me try and figure it out. Oh, property.

Yes, of course. Yeah. But it's probably, I'm just still very bad at parsing Phil's jokes. I'm sorry, please don't take it personally. Is it like a testing paradigm? Is it like testing? It is. Yeah.

Yeah. Yes, we're testing properties rather than specific values. Sorry. So we're not being a very thankful audience here. So I'm sorry. Yeah, we're not funny. So Kristen, do you actually do anything, any C++ at all, even just in your free time?

Or do you still keep up a little bit with where this community is going, or you're just out? No, I mean, I... I mean, you're here and you're giving a talk at a C++ conference, so I guess... I do write talks for C++ conferences when they are requested of me, I guess. I am still chair of the Boost Foundation. I still go to the New York City C++ meetups. And you have to understand my entire social group is predicated on C++ pretty

much entirely, right? So like, it kind of permeates throughout most of my life. Like it's a very strange experience. You'll be like on a date and somebody will be like, oh, I saw you in the CppCon talk video and I'm like, interesting. Okay. So yeah, I mean, I'm like very involved in the community, I think still. I also like, you know, help it. I have like a technical recruiter that I sometimes like, will work with when he's like placing people like, if they're looking for like C++ roles. And yeah, all of my friends are in the in the C++ community. are in the in the C++ community.

So you mentioned the Meetup, the New York Meetup and the Boost Foundation board. So we already talked about the Meetup. I'm curious, what does it mean to be the chair of the Boost Foundation board? What does that involve? And what are you, what are you doing there? And what's, what's going on there now? I mostly just run meetings. I do like generally set, try to set like a leadership direction. But like at the end of the day, like, I'm just trying to pull out action items from like

general discussions when we, when we get together as a group. There are a lot of really, really smart people that like make up the board that do more of the actual work that I do. But like again, if I can contribute, I'm happy. Back to cat herding again. It's some cat herding. Cat herding, yeah. So you obviously, as you said, spend a lot of time in your previous career at Google working on refactoring tools. Yeah. Actually, I think C++ is probably the hardest language to do this in. I have not worked on refactoring tools specifically. Well, actually I have.

I've worked on the C line front end. I've done this probably on not anywhere near as of a scale as you have at Google. But I have a little bit of an idea how hard it is to do in C++ because that's such a messed up language. So how did you like get into that? Like, what were you doing there? Like, what's the story there? I'm just, I'm just really curious. Um, I think actually, Matt was giving a, he was teaching a class on C++

11. And he was just describing his job. And I was like, that sounds cool. Like, can I work with you? And then he like finagled a position on his team team and that's kind of how I got involved with it originally. I went to the University of Michigan where the entire curriculum is in C++, so I had somewhat of a background. I erroneously thought that I knew the language, which I did not actually know, which was immediately apparent when I joined the team. It is hard because C++ is a context dependent grammar. So like, you can't do things like regular expressions. Like that just like won't work. I gave a talk actually on how to write these tools at CWBCon.

Like maybe, was it last year or the year before? It's how to write your first automated C++ refactoring tool. And it's just like a high level overview of how you can write a Clang tidy. I think we touched on this earlier, but like Clang has like a really, the Clang LLVM compiler has like a really rich set of tools built around it to do like syntax tree analysis

and also like editing. And I think that might be part of why like we use it so heavily like at Google or used it. I used it. I still say we, but yeah, I mean, it's, it's sort of like an opaque, like the, the frameworks are sort of opaque, but like once you understand them, they're really powerful.

So you can go watch the talk. It's super cool. Um, not my talk specifically, but like the stuff that you can do with the libraries are super cool. I will put a link to your talk in the, in the show notes for that. So I know you've been out of C++ for a while now, but is there anything in the world of C++ that you are still keeping an eye on that you find particularly interesting or exciting?

Just like our usual wrap up question. Oh, I mean, I think all of the talk around the security and the memory safety stuff is relatively interesting. I'm curious to see how it actually pans out. Like do the improvements in that are proposed for C++ 26 land in a time efficient enough manner to like make a difference? Is there gonna be a shift to a more memory safe language like Rust or, is Rust only

exciting right now because it's not bogged down by the legacy issues that would be associated with any language that's been around for like a certain number of years? Right? Um, I think those are all interesting questions, right? Like, Yeah, I love how you take this like high level view. Like, I think that is really, really interesting. As you say, how it pans out, I have no idea. Like, I remember, like a couple years ago, we reached this point where, you know, there were all

of these government agencies saying, I mean, I guess they're still saying that, like, you know, we should like every company should like have a roadmap, how to move away from CNC for stuff, because it's not memory safe. And like, we all need to like introduce regulation to like stop people from like writing more C and C++ code and stuff like that. And then everybody was like panicking, oh my god, oh my god, C++ is going to be obsolete soon. We need to do something. We need to do something. And then there was like a flurry of like proposals and ideas and things. And now it's kind of like a couple of years later, it's like, oh, damn,

like, we can't this is this, there's not no easy fix for this. Like, there's not really anything we can do about it, like on a technical level, right? Because C++ is what it is, like, you know, we could do this here, this there, like, we can improve things, you know, we got a few things in C++ 26 now. Like, and I'm going to talk about all of that myself, also, at this conference, CUPnC. But in the grand scheme of things, if you're dereferencing a pointer, you can't locally prove that that's not a dangling pointer.

That's just impossible. If you want to do that, you have to either use a sanitizer, and then your code is going to be 10 times slower, or you're going to just ban pointers and instead do something like Rust does with the borrower checker. Those are pretty much your two only options, right? And so now I think people kind of have realized that.

And now it's kind of like, OK, what do we do now? And I'm kind of zooming in on this. And I think, Kristin, you were kind of zooming in on this. And I think Kristen, you were kind of zooming out a bit. I think that's actually the better approach. It's kind of like, no, okay, let them figure out and just see, see where the chips fall in a few years. And I think that's like a really interesting question. And I don't know, but I really want to know. So my, my guess is that there will be like a proliferation of like the static and now like, like, how do I put this like, there will be platforms or binaries or

some sort of like proliferation of tools by which you can validate c++ safety in a way that's like not like that doesn't require like completely transitioning to a new language. I don't know it like it like kind require like completely transitioning to a new language. Um, I don't know. It's like, it's like kind of like the stuff that they're doing at Bronto source where they're, they're building things to do like analysis and migrations. And like, I imagine that like that tooling will become more relevant because like, I

do think it will be cheaper from a company's perspective to update their old C++ than to do something in a new language. But I don't know. I literally have no idea. But interesting to watch from the sidelines. Yeah, it doesn't matter. It doesn't matter what happens. I sell houses.

On that subject, is there anything else you want to tell us about before we wrap up? I think you already mentioned how you can, how we can find your real estate site. Yeah, I mean, yeah, I mean, yeah, of course. Like, this is probably the only opportunity any of you listening to this podcast will have to hire a real estate agent that used to be a staff software engineer at Google. So you can even take that opportunity. You can leverage it to your full advantage.

Um, but yeah, just thanks for having me on. I'm glad I hope this is helpful. And then it's not too much of a pain to edit. Um, well, the people listening won't know about all the editing. So unless we tell them now. Okay, well, thank you very much for coming on and giving us a unique perspective on the world of Shea++ and beyond. If there's anywhere that people can reach you, if they do want to find out more on the

technical side, we're now to reach you for the release date. My email is just christen at shakernyc.com. So you can email me about whatever you want. I might not respond to certain emails. Yeah, we pick up those sort of emails as well. Yeah. Okay. Well, I think it's been a great conversation.

Again, thank you for coming on and we'll see you next time. All right. Thank you. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff that you're interested in, or if you have a suggestion for a topic we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com.

We'd also appreciate it if you can follow cppcast at cppcast.com on X or at macedon at cppcast.com on macedon and give us a review on iTunes. You can find all of that info and the show notes on the podcast website at cppcast.com. The theme music for this episode was provided by podcastthemes.com.