Year In Review

  |  Compiler Team  
Desarrollo profesional

Compiler • • Year in Review | Compiler

Year in Review | Compiler

About the episode

It’s been a year of growth at Compiler, and we want to celebrate and share with our guests and listeners some of our favorite moments from the show. Thank you for all of the support, we’ll see you in 2024!

Compiler team Red Hat original show

Suscribir

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcripción

All right. It's Brent here. We are closing out the year. It's December, and on Compiler, we've had a lot of really good times with you this year. We're going to rest up for a little bit, and we'll be back soon. But, to pass the time until then, and to ease everyone into these cool winter months if you're in the Northern Hemisphere, we wanted to share some of our favorite moments from this year. Take a little trip down memory lane. Some of the unexpected insights from our guests, engaging stories, laughs that we've had along the way. So, are you ready, Angela? I'm ready. Let's do this. All right. Let's go. This is Compiler, an original podcast from Red Hat. I'm Angela Andrews. And I'm Brent Simoneaux. We go beyond the buzzwords and jargon and simplify tech topics. Today, we're looking back at the best moments from this year. We have producers, Johan Philippine and Kim Huang, in the studio. Let's see what they have for us. Johan, do you want to go first? Sure. Because you had a lot of really great picks from the year and I want to hear what you have for us. Well, it was really difficult to pick because we've had such a great year. But I want to jump to our very first episode of 2023, which was The CTO and the Vision. Now, this one was one of my favorites of the whole year. I got to speak with our very own Chris Wright, our CTO here at Red Hat, and we were able to record a lot of candid guest tape. Yeah. That gave a different perspective on the job and really shed a lot of light on what it's like to be a CTO, a lot of which was unexpected for me. It also launched a really great series. As part of the C-suite, the CTO spends a lot of face time with customers and with partners, and those communication skills really come in handy to figure out what they need and what they're curious about. But he also, like you're saying, he kind of needs to manage expectations a little bit. It's true. So, it's not uncommon for me to have these conversations with customers that start out with a very open-ended question, like effectively, what's the world going to be like in five years? The honest answer to that is, in many ways, I just have no absolutely no idea. So, the fortune-teller aspect, boy, is it hard to tell the future. Now, you could recontextualize that. In five years, what will the enterprise look like? That's a lot easier to have an opinion around, because most of what the enterprise will look like in five years is what we're working on today. So that starts to build that bridge, and if we recalibrate the timelines, like when you say in five years, do you mean what new invention will exist, or how far should I be along the path of absorbing today's technology? Those are very different conversations, and in the latter, I'm much more of the cartographer, or helping them map out a path into the future, rather than just gazing into my crystal ball and explaining that I believe in 2027 we'll have autonomous flying vehicles. Well, we know that crystal ball isn't absolutely accurate, I mean, because if we're talking about looking into the future, we'd already be in flying cars by now. But that's an interesting take on it. Yeah. That is two different questions. I mean, where we are now has a huge impact on where we'll be in five years. It is the groundwork. But how far will we have been in these new emerging technologies? How much will we have progressed in these new burgeoning technologies? And, yeah. They are two different questions, and his answer is he has no idea. That's really the honest answer. Yeah. Because we can go back five years from now, and a lot of us, we knew what the technology could be, but we didn't have an idea about the possibilities, right? Mm-hmm. Yeah. So, in five years from now, we're dealing with a lot of merging technologies, in Red Hat and other companies and other sectors around the technology space, and we have an idea because we have so much burgeoning technology now, but we have no idea what it's going to look like in five years. Right. And that's the interesting part of it. How do you decide where to place your bets? Mm-hmm. So, less Nostradamus, more Magellan is what I'm picking up from it. Yeah, exactly. I hear that. Yes. I definitely hear that. Yeah. The other example that he gave in our conversation was back in the mid-2000s or whatever, no one really knew anything about the smartphone or what it was going to be or what it was going to do, and a lot of early adopters bought it just because it was the cool new thing, right? And then you couldn't have predicted the impact that it would have on our society and the rise of apps and social media and all the different things that arose out of this new invention, and how that changed the tech industry. And look at us now. Yeah. Look at us now. Now, even when he makes sure that customers understand his role more of a cartographer rather than a fortune teller, a lot of them, they hear him as a CTO and they still expect a little bit too much from him. All they expect me to know is everything that's in our portfolio, all the features, the roadmaps, the dates for deliverables, the commercial pricing models, et cetera, everything. If you take a look at our portfolio, there are white spaces where we might work with partners or just have no great solution. So there's everything that's in our portfolio, then it's everything that's not in our portfolio, and then it's all the emerging new ideas that aren't necessarily well-mapped to either of those. That's all. It's essentially everything, and it's a completely unrealistic expectation that any single person knows that much, because they also assume I'll know it down to a level of detail of lines of code, implementation details. And I've found that frustrating and even overwhelming at times. Wow. Wow. Okay. So, he doesn't know all those things? Oh my gosh. I just love how honest he was in that response, because I feel like a lot of people in the tech industry, they'll just put up this front of knowing everything. Everything. And trying to get that and use that in order to advance their own careers and everything, and Chris here just tells us how impossible that is, and how impossible that makes his job, and how it would, down the line, lead for disappointment for everyone. And, it's just so refreshing to be able to hear that. That's true. It really is. It's, for me, it's comforting, because then I don't feel the pressure to know everything about my job. The wild thing about this episode for me was that I had a kid last year, late last year. You did. And I was on parental leave when this episode came out, so I had no idea what the three of you were up to, and suddenly, on my phone, this new episode of Compiler comes out, right? With who? Chris? Wait, with who on it? With Chris, right. And I just got to listen to it and enjoy it, and I have learned so much from all three of you and Chris. It was just such a different experience than I usually have with this show, because I'm usually in here looking at scripts and recording with all of you, and talking through episode ideas and stuff. It was just, it was really nice to have an outside perspective on this one. Yeah. Nice. I want to introduce one of my picks now. We just talked about Chris Wright talking about being that single point person, that person who's like a living document, who knows everything, right? Being that single point person can be a lot. But for another person who is new to the company, who is new to the work in general, finding that point person is invaluable. On our first episode on legacy technology, Jessica Cherry told us about a guy named Paul and how important it is to pass on living history. Okay, so you get this box. You get this box. What do you do with it? How do you, what does Jessica— You try to log into it and see what's on it. What else are you supposed to do? Hopefully, they still have the credentials. Usually, they do. It's on a sticky note taped to the side of the server. Because again, no one knows what it does, so you have to log into it and see. You have to get the lay of the land. You have to understand exactly what is— How do you do that, though? You click around. Now, we can Google. We figure out, oh, what's this software called? Well, what does it do? Or, we look at the network traffic. Well, where's it going? Who's accessing it? Check the logs. What's happening on here? You have to get an idea of what other things are installed, if there's any services that depend on one another, how it all works, and you just try to make a map of what this thing is doing, and understand who its stakeholders are. Maybe you go talk to them. Maybe they have some idea, you know? You have to start somewhere, so the first thing you do is you log in. That can't be the only thing, though. Right, Johan? Yeah. I mean, if you're really, really lucky, you have a Paul. Paul is your single point of failure. Paul knows everything. If Paul gets run over by a bus, you have a problem. I'm going to call the name out as Paul, because I had a Paul, right? You become friends with Paul, because Paul knows everything, and that makes your job a lot easier to hang out and be like, dude, can I just write notes and hang out with you for like fifteen minutes, please? I have known a Paul. I have been a Paul. So— I have a Paul in my life right now, too. They're invaluable. Don't let anything happen to them, because, yeah, you wouldn't know what to do. If my Paul ever leaves, we're done for. We're just done for. Everybody should have a Paul. Mm-hmm. Yeah. Hopefully, the best case scenario, you have a Paul who will teach you about the black box and at some point down the line, you'll teach someone, and they'll teach the next person. It keeps the system alive and running and the business operating. But you're still kind of stuck with that hit by a bus problem. So what do you do when you don't have that unbroken chain of knowledge to pass on the sacred scrolls? Jessica has found that she can figure things out, much like Angela was just describing, though it'll probably take a bit more time and be much less pleasant. Sometimes I just wander around and look at stuff. It's good to have the general interest of "what's going on here?" That has always been a little bit of my life, in general, where I'm all like, I wonder what happens if I touch this. And my mom will tell you, this poor girl just will fall into a lake to see if it's wet, right? And I am that person, where I'm like poke, poke, oh no, I blew it up. And then have to, which my buddy nicknamed me Armageddon for this very reason. I will blow stuff up and be like, huh, I'll figure it out, hold on, I'll bring it back. And that kind of skill set is useful. So. Her nickname is Armageddon, okay. Yes. She's fun at parties, I'm sure. She is a very fun person. When we first started working on Legacies, Jessica Cherry was one of the people that someone else actually recommended. I talked to her about the show because she had so many interesting stories and insights, and so many things to share. And I got to talk to her, but I didn't actually get to do her interview because I think I was sick. Oh. And I've never in my life, or at least never in the history of this show, been so, so sad to have missed out on interviewing someone for the show. I really, really, Jessica Cherry, I mean, you could just hear it in her voice. Mm-hmm. She's just a very knowledgeable person, but she's also a person who's very practical, very down-to-earth, and very just a person who you want to talk to and you want to hang out with. I am so enamored of her, and I've never been so disappointed in my own immune system to not have been able to talk to her and actually do her interview. So, that's why I wanted to pick this. It was a lot of fun to talk to her for that amount of time. Oh. Oh, go ahead and rub it in for her. I'm just going to rub it in, just a little bit, you know. Geez. You should have said it sucked. It was a terrible interview. No. Don't make her feel bad already. Well, I wouldn't do a guest in like that. That's not. There's no evidence to say. I know. She was amazing. Yes. She was amazing. No evidence to say that. The one big thing is that, and this happens for most of our episodes, is we have these really great, really long, really insightful conversations with all of our guests. Yeah. Yup. And so little of it makes into each episode. Yeah. This is really just a little cherry on top of the interview. The Jessica Cherry? I see what you did there. Yeah, there you go. Brent got it. Brent's picking up what I'm putting down. There it is. I love it. This clip I think also really encapsulates Angela and I's relationship, which is basically Brent asking a really dumb question, "how do you know what's in the box?", and Angela being like— Google it? You log into the box, dummy. Oh my gosh. That's just the practical side of me. You have to look. You don't just know. You have to kind of look around. But if you've been in the Jessica Cherry shoes, or the Paul shoes, or the Angela shoes, you would know that already. It's something. I'm super risk-averse, too, so I'm like, if there's a box that I shouldn't be in, I'm not touching that box. I'm not going in the box. Oh, no. I'm going in. Oh my gosh. Coming up after the break: why titles matter when pitching and presenting at a tech conference, and the one word technologists use to both communicate needs and respect others' boundaries. Stay tuned. I want to introduce, this is one of my picks, I want to introduce Francisco Tisiot, or reintroduce Francisco Tisiot, to our listeners. He spoke with us for one of our summer series episodes on tech conferences, which— Loved this one. Yeah, me too. This is one of my favorites. Yeah. We really got a lot of positive responses about this episode, in particular. I'm going to kind of keep it a secret as to why I picked it until after. Okay. I'm going to let you all kind of listen to it, kind of relive it, let our listeners kind of hear it, and then I will come in and say exactly why I picked this clip. Okay. But let's listen in on Francisco talking about abstracts and also how to write them and what are some are things that are crucial to have in an abstract. So, the abstract's job is to convince people that they should absolutely listen to your talk. Not all the abstracts will be successful. You will get some of them accepted. You will get some of them rejected. But the main thing is that if you don't write any abstracts, there are no chances to go and speak in public. So, I started writing about how you can build what I think is a successful abstract, or something that is more likely to be accepted at conferences. So, let's talk about that for a bit. Both here and in his blog, he says that there's no foolproof formula for writing an abstract that is going to guarantee success, right? Even he has dealt with rejection in that regard. Oh, I'm sure. Yeah. Well, one, I can't wait to read the blog post, because I'm really interested in what he thinks about that, and the other thing is, rejection is a part of the game. Think about it. If a conference has 60 sessions and 700 submissions are submitted, that's a lot of rejection. But you really can't take it personally. I think having that mindset, it's almost like a numbers game. It's a lottery. You just have to do your best to put your best foot forward, and maybe you'll be at the top of the heap. But you're right, you have to deal with it. I think everyone who's ever presented has had to deal with some sort of rejection like that. Yes. Yeah, the abstract is a very strange genre. You have to do a lot of work in a very little space, and I think sometimes we want formulas. Sometimes we want, if I just do X, Y, and Z, then it will be a great abstract. That's what we want, but that's just not reality, because communication is so much more of an art than a science. That's true. I do want to get into the finer points. Okay. Because there are some things here, and most of them won't surprise anyone here, but they're all good things to remember. So, first off, the title, right? Please keep it simple and clear, right? People know what they're getting into when they read the title. A funny title does show off your personal style, but you should also kind of be careful to demonstrate what the attendee will learn from the session. You always want to kind of make that the emphasis. And also, obviously, it goes without saying, every event has their own guidelines. Please pay attention to those as well. If you think about how the audience is going to encounter that title. Yup. It's really important. So context matters here. Indeed. It's going to be on a conference website. Yup. It's going to be on the conference app, if they have one. It will be perhaps, if it's a smaller conference, in a booklet, and people are going to be scrolling and scrolling and scrolling. Yes. Through so many titles. It's almost like a sea of titles in some ways, so— It is. I think that's something to remember. It is. It's a title wave. Yeah. Did you say title wave? Oh my gosh. She sure did. Oh. Another really great thing to remember, and I'm glad you brought this up, Brent, is the digital aspect of it. Yeah. From a digital perspective, because there's so many different places and areas where the title of your abstract can appear— Yup. Yes. It may appear truncated. Oh, yeah. So, you have to kind of keep that in mind, kind of like a little UX that you're keeping in mind. Yeah. Where, if this person's looking at it on a mobile phone, is my title going to be fully read or is it going to be truncated or cut short? So that is something to keep in mind. Simple and clear. If you have a really long, lofty title, something may get lost in translation. Yeah. You just think about it. We're in the middle of conference season, and I'm looking at conferences, and I'm trying to figure out, well, where will I spend my time? And again, if it's not grabbing you, if it's not in your wheelhouse, if it's not clear, there's so many things that can come into play where, wow, this won't catch someone's attention. All of these things are true, and just because, for all of our listeners, just because your abstract is not accepted doesn't mean it's not great. It's just not that particular fit. And Johan mentioned this. We've been having little conversations about submitting abstracts, where it might not just be a fit for this particular conference, but it would fit amazing somewhere else. So you might have to take your show on the road. Who knows? Yeah. All that work you've put together in writing the abstract, putting the title together, and you've taken the work to also make the presentation, that doesn't necessarily need to go to waste, right? Exactly. So, does anybody want to hazard a guess as to why I picked this? Yes. I do know that you recently spoke at a conference. I did. I did. Oh. Yes, and the conference was wonderful. I learned a lot. My talk, when it came to be my talk, my talk was in the afternoon. Talk was great. I feel like I put it together really well. Abstract was pretty good. And this is the part where, if an audio editor could go through and do the boo-do-do-do-do where I'm saying, "Oh, the title needs to be optimized, it needs to be done really well to catch people's attention," you can go back to boo-do-do-do, current day, present day. What did you do, Kim, with your title? Uh oh. I did not put a lot of energy into my title. What? I didn't make it very clear, and I paid for it because the interest in my talk was not as much as I thought it would be. It was already at a time of the day when people are very tired and winding down, and then on top of that, it wasn't very clear as to what my talk was going to be about from the title itself. So, I paid for that. I worked on this episode and I said, in my voice, that titles are important, and I didn't follow my own advice. So, that is why I am picking this as one of my best moments, because it's something that I didn't follow it and it came back to haunt me. That's why I wanted to talk about it. Okay, listeners, don't be Kim. Don't be like me. Make sure that your title is put together. Have your friends read it, have other people read it. Don't be like me. Don't do what I did. Definitely prepare and do your best. Well, I think we've all learned a little bit from this episode. I mean, I know I did, so much so that I submitted to a conference. Oh. Just recently. Do you know the results yet? Yeah. No, not yet. Oh. I have plenty of time to find out if they've accepted it, but this episode, I put a link to it in my slide deck so other folks could know Francisco's great ideas and all of the great feedback that we gave about making a good abstract. So hopefully, it goes far and a lot of folks can learn from it. So, I'm happy no matter what. Did Angela's talk get accepted? Find out. Check us out on social media on Instagram, X, and LinkedIn. Check us in 2024. One thing I'd like to mention here that I don't know that we actually covered in the episode is that there can be a lot of time between. Oh, yeah. Oh my gosh. When you submit the abstract. 100%. It was a long time. And when it actually gets accepted. It can be months. Tell them, Johan. Yeah. Also, a lot can change in those months, too. We know that. Yes. Yes. Yeah. So, I know it can be difficult to wait that long and to have that anticipation of oh, did I get accepted or not, but sometimes that's just the nature of the game, right? Yeah. Because they have so many abstracts to get through and make their decisions, and weigh one thing against another. It can be a really long process. It's months. So, if you do submit— Buckle up. Know that it's going to be a long haul, at least for the very big conferences, I guess. Yeah. Yeah. This has happened to me before, where it's like, I'll forget that I submitted an abstract. And now you got to do the work. Or I'll remember and then I'm like, oh. Uh-huh. Oh, wow. Now I've got to put together a presentation now. Yeah. Oh my gosh. Yeah. But then, it's also happened to me where I'm like, I'm a different person six months later or whatever. How about that? And the thing that I was really excited about six months ago when I wrote this abstract, I've already moved on. I'm on to some other new topic or thing that I'm really excited about and I got to dig back in to what did I even write? The upside. So, I get what you're saying. We could have moved on, want to talk about and learn other new things. But, for someone submitting to a conference that maybe they want to talk about something that's sort of a stretch goal, well now you've given yourself this really nice cushion to kind of master said topic and practice it and pull it all together, and then if you get selected, then you can really fine-tune, and then when you get up there to present, think about all the months of work that you've put into this topic that you wanted to master. You're now the teacher. You're sharing your knowledge and information with other folks. So, it can be not a bad thing. Yeah, yeah. It's not on top of mind, but it's also, could be a blessing for someone who's putting themselves out there to talk about something else. Yeah. Absolutely. Well, Johan. I'm going to kick it to you because you have the final pick. So, for my final pick, I selected a clip from a guest who we actually had on twice this year. Okay. So, if you've been following along, you'll know that this is Jose Vicente Nunez in the episode, Adventures in Automation. Yup. Good. I really love this episode because it's got a really good mix of humor and helpful information, with guests whose expertise span the whole gamut of where our audience might be, or where they might be headed in their own learning experience, and it's just another one of those episodes where I went into it thinking that it was going to go a certain way, that the interviews were going to get at the certain type of response, and the end product was so very different than what I initially thought that it just changed the whole episode. And, I think it changed it in a much better way. And, this happens all the time, but— I love that. So, what does it mean to take your time, right? You talked about testing your scripts, adjusting them, and then testing them again and again until you're confident beyond a reasonable doubt that the update's going to roll out the way you want it to, right? That it's going to be smooth. That way, you're not going to break a large chunk of your hardware and you're going to keep your infrastructure running. And for that really expensive piece of hardware, that FPGA card that's like $20,000, sometimes it's okay to do things by hand. Now, another way to minimize things going wrong is to keep the scripts simple, and have them do one single job, and that's not always as easy as it seems because it can be tempting to add functionality to a script, and there can also be pressure from other teams to add functions, as well. Now, over the years and over his career, Jose has had to learn an important skill. Jose I learned how to say no. So it's like, can you add this feature to put this data into a database? No. Can you add this feature to launch another container? No. What we can do? We can do this. But you don't need to change the tool. Keep the tool simple, and anything that you want to put on top of that, we can do it. All right, let's all say it together. No. Jose No. No. No. Okay. No. It's a complete sentence. It gets your point across. And, it is okay to lead with no, because not every request that you get requires your attention, or not your immediate attention. So, is it okay to say no. Learn how to say no and be comfortable in it, because it may save you in the long run. Because you can always come back and say yes. It's hard to come back from saying yes to a no. So, think about that. Yeah. If you start with that simple script and you start adding things to it, it's harder to remove those features than it is to add them later on. Yeah. That's a great point. So we're talking about automation, and there's this famous automation instructor, and one of the words, this phrase he always says is, keep it simple. Complexity kills productivity. And, I believe that wholeheartedly. You want to do things in modular, small, little piecemeal things. You don't want to go messing up a whole lot at once, because it's really harder to undo something that is complex. And it's really harder for someone else to come behind you and understand what you did when it's so complex. So, yeah. I am all for putting the brakes on. Well, it sounds like there's a lot of benefit to simplicity here, right? For sure. I think that it's not because you don't want to. It's not like you're lazy and don't want to do more work, right? It's because it has all these really great effects. Yeah, and keeping it simple makes it easier for the thing to just work, and just to keep working, and you're minimizing the surface area for problems to occur, either now or later on. Saying no is really great for keeping it simple. And those simple scripts? Well, they can last a lot longer than you might imagine. Jose You will be surprised. I've seen pieces of code that are 20 years old and they're still kicking, Perl especially. Oh my god. These guys, I'm telling you. If there's a catastrophe, like an asteroid hits the Earth or something like that, you will see the roaches and the Perl scripts taking over. Probably those will be the only two things that will survive because they're so resilient. That was the perfect visual. Perl will never die. Neither will cockroaches. That has already been established. Yeah. How funny is that? That's great. I love talking to him. I love that clip. I had forgotten about the roaches. This was so funny. The Perl scripts. Oh, I love it. What a fun episode. Yes. I definitely love that episode. I wasn't surprised at all when Johan chose it. Oh, you picked a good one. This was one definitely that I'm glad you put it in the end of year, because it has all the things. It has all the elements of a great story, and it was funny, and our guest was so cool, and he has a slogan: no. You can't top that. Yes. Just say no. We should all be like Jose. This is another one of those where I'm intensely jealous of you, Johan and Kim, that you get to talk to these guests. All the people. A little behind the scenes. Angela and I, we don't do any of these interviews. That's right. We don't even hear any of the guest tape. What? Before we get into the studio, and Kim and Johan go have all these really fascinating conversations, and then Angela and I, we're hearing it for the first time with all of you listeners. Yes. So it's like, I'm realizing again and again, in listening to all these episodes, that you might have the best job ever, because you get to go just talk to these really smart, wonderful people. You got to interview this guy. Twice. Twice, yes. And now there's that. He was kind enough to come back, yeah. What was the original episode that he was in, Johan? It was for Re:Role, but I don't remember which one it was. It was the Sysadmin episode. It was the Sysadmin episode. That's right. Oh, that's right. Okay. Yeah. I remember that now. It's Sysadmin and The Script, I think. That's right. Yup. So that was the last of the picks from this year. What do we think? I don't know how you could pick just four, but you did a great job narrowing it down. Did you go back and listen to a lot of tape? That had to be hard. We had some really good episodes this year. Yeah. I mean, all of our guests, and if you've ever been a guest on Compiler and you're listening, first of all, thank you so much. Indeed. For giving us your time, your energy, sharing your stories, your insights with us. It really means a lot, not just for us being able to do this job that we love, but also, it teaches us. Johan and I learn a lot from these conversations that we then go forward into our own lives and our own working lives and our own relationships. We implement the things that we learn, and we're constantly talking to these, like Brent said, really smart people. And, it's just, it's irresistible to kind of follow their advice and their insights because they're just so strong and they're so grounded. Unless you're writing a title for a talk. Unless you're writing a title for a talk. Because then. I'm sorry. It was too easy. Yes, yes, yes. Lessons learned are powerful, even lessons learned through failure, right? So, but, yeah. It's just great. I did go through quite a few episodes to kind of pick the ones that I chose. I feel like Johan, I feel like you were, when I saw the ones that you picked, I was not surprised at all. I feel like you definitely, I could see that those two were your favorite picks from the year. Yeah. My process I guess was a little bit different. I didn't listen to all of the episodes we went through this year, but I did go through them one by one and kind of just remembered the really poignant moments that kind of stuck out to me, and I was like oh, yeah. These are the two that, on top of all the others, are the ones that I really want to revisit because they're the ones that kind of spoke to me the most. Yeah. I should start a Compiler journal, where next year, when we circle back and someone says, "oh, Angela, which episodes do you want to do our year in review?" "Well, let me just pull this up." Dear journal— Dear diary— Exactly. I just, I love Compiler, and you all do such a great job with these topics and these guests, and you make it what it is, and I know folks have a great time listening because I hear back from people that tell me just how much they enjoy this podcast. It's so much fun. Well, do we want to sign off for the holidays? Yes. Wherever you are in the world, I hope that you are well and that you are safe, and that you have a great time doing whatever it is that you love. Hopefully, not working. And, in the new year, you might not hear much from me for a while. I am moving to Europe, and I'm also going to be working on some other projects with this team, so there's more to come there. Yes. Thank you so much for listening. Thank you for an amazing 2023. Let us know what you thought about this episode. All of our episodes, we would love to hear it. You can hit us up on social media at Red Hat everywhere, using the #CompilerPodcast. Thank you so much, and here's to an amazing 2024. And, that does it for this episode of Compiler. Today's episode was produced by Kim Huang, Johan Philippine, and Caroline Creaghead. A big thank you to, well, to you. Thank you for supporting the show this year, and every year. Victoria Lawton is our unbroken chain of knowledge. Sometimes she blows things up, but she always brings them back. Our audio engineer is Christian Prohom. Special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta. Our audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Nick Burns, Aaron Williamson, Karen King, Jared Oates, Rachel Ertel, Devin Pope, Mike Compton, Ocean Matthews, Paige Johnson, Alex Traboulsi, and Mira Cyril. If you liked today's episode, please follow us. Rate the show, leave a review, share it with someone you know. It really does help us out. Until next time. Have a good one, everybody. Happy new year. We'll see you next year. Happy new year. Yup.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Publicaciones en el blog

Friday Five — August 15, 2025 | Red Hat

15 de agosto de 2025  |  Red Hat Corporate Communications

...

Publicaciones en el blog

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

14 de agosto de 2025  |  Brian Stevens

...

AI inference

Programas originales

Fail Better | Command Line Heroes

Desarrollo y distribución de aplicaciones.
Desarrollo profesional
Historia de la tecnología

Programas originales

Steve Wozniak | Command Line Heroes

Historia de la tecnología

Sobre el podcast

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.