Re:Role | The Developer Advocate And The Exchange

  |  Compiler Team  
Desarrollo profesional

Compiler • • The Developer Advocate And The Exchange | Compiler: Re:Role

The Developer Advocate And The Exchange | Compiler: Re:Role

About the episode

There are a lot of ways to get the word out about your product. But the tech industry needs something more. Building a community where users and developers can talk to you, ask questions, and provide suggestions—that doesn’t happen on its own. Developer advocates do the hard work of nurturing communities, doing a lot of showing and telling. And when that community starts talking to each other, and brings new people in on their own? That’s the dream.

The company, its business activities and its employees depicted in this podcast are fictional and are not intended to represent or depict any current or former business organization or any individuals living or dead. Any resemblance to any individual or organization is purely coincidental.

Compiler team Red Hat original show

Suscribir

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transcripción

So our startup is looking like a real company. The product is out. The team is delivering regular updates and adding new features, and there's a team in place to help users when they have questions or problems. Demand is going up, and with a larger user base come the demands to expand features even farther. But it also means that they want their own financial institutions to connect to the app as well. And though we've released an API for others to connect to, pick up from smaller institutions has been slow. Our CEO is worried. "What's the hold up? These APIs follow pretty standard conventions, and we've done our due diligence making sure that they're secure as they can be. Why aren't these banks connecting to our app?" Marketing clues us in. "We don't have a lot of resources to help onboard new partners. Marketing doesn't have the technical background to write this kind of content, and our developers are too busy working on the actual app to devote time to user guides and to travel to conferences to give workshops. And tech support have their hands full too." As our startup heads towards its exit, it's time to hire a dedicated team of developer advocates to build relationships with the developer community and teach them how to implement our software. This is Compiler, an original podcast from Red Hat. I'm Johan Philippine. I'm Angela Andrews. And I'm Kim Huang. We're following a fictional startup as they grow their business. As things move along, our hypothetical team realizes it needs to fill new roles. We're calling the series Re:Role. Any resemblance to any existing organizations is purely coincidental and unintentional. Today's episode: Developer Advocates. If you'd like to listen from the start of the series, check out our episode on the CTO. Producer Johan Philippine is here with our story. So, what is a developer advocate? They're also known as developer relations engineers, and you may have heard the term developer evangelist, but that term is falling out of practice. Kim and I spoke to Lo Etheridge, a developer relations specialist at Sanity.io. They gave us a great definition of their job. I tend to think about it in terms of: what is an advocate in general? So an advocate in general is someone who works with someone else in a collaborative fashion to sort of present and represent their wants and needs. And so that includes, if you're doing sort of advocacy in an ethical way, is very much collaborative, and also you are working to uplift the agency of that person or that group. So a developer advocate does the exact same thing, but it's in on behalf of developers. Developer advocates are people who act as a bridge between a company and the community of developers who use or would like to use that company's software. They represent the community of developers to the company, making sure that those developers are heard within the company and that any requests that they have or any issues they're facing, that those get addressed internally and then get pushed back out. But they also act as a bridge the other way around. They represent the company to the community developers, making sure that the company's messages are getting out, that the resources, the trainings and the workshops, that kind of thing, that they're running smoothly and that the community are able to access those resources. Okay. So this is a really interesting role. I think it's a vital role. I know we have them here at Red Hat, and I find that our community is such a huge part of who we are and being able to have that advocate for them to make sure that the developers' thoughts and needs are getting communicated to the community and the community's thoughts and needs are communicated back to the developers and there's this great symbiotic relationship because as we know, all documentation is not good documentation. So it's nice to have that person who puts these things together, puts those ideas and issues in the right hands, and then presents information really well to the community. So a very important role, and I know quite a few developer advocates out there, so I'm always in awe of them and what they do for their products, and it's really inspiring. So let's go a little bit into what that kind of work looks like. We'll get back to Lo later in the episode. For this we're going to bring back Alvin Bryan, who you may remember from our episode on web developers. He's a developer advocate at Contentful, and he's got an insider look at growing a developer relations team. It starts when a company is looking to grow their product usage. Let's go, let's grow the product. Let's hire a DevRel. But the problem with being the first DevRel is that you're in charge of everything and on two fronts on the front of you have to set up everything when it comes to metrics and how you measure things and the frameworks in reporting success to leadership. We have this thing called the three Cs of DevRel, which are code, content and community. And if you're the first DevRel, these three things are your job and they can easily be three jobs. Wow. Yeah. Oh, my gosh. Imagine being the first. It's a big responsibility. It really is. But an important one though so... What are these three Cs that he's talking about, Johan? So those three Cs are content, code, and community. Okay. Let Alvin dive into that first one, content. Everyone in my team has an area of focus. For me, it's more around content. Content as in written content. So that will be blog posts, editing other blog posts, writing starter guides. So this is your product plus technology X. So think about your product plus Python, how to choose your product in JavaScript, in our case, how to use Contentful and Svelte, how to use Contentful and React. Content. Things to read, to watch, to listen, to help you get started. Oh. Angela, I'm sure you've run into this kind of content all the time and hopefully it's useful. Usually it is, but I've come across some that really isn't. So it depends. I love that phrase because it always depends. Nothing is ever black and white in the world of tech. Oh, yeah. Not at all. So we're talking about the second C. Yeah, what is that? Let's get onto the second C, code. I would argue that I'm on the code side because I work on starter guides and tutorials and everything, but for some companies, and this is usually called developer experience more than developer advocacy, but it depends. But in some companies, some people will be working as DevRel, but they'll be working on SDKs, for example. Some of that sounds like the content he was just talking about, but there's a little bit more to it. Putting together something like a software developer's kit or SDK or a demo for people to try out or to show on a stage, that takes technical knowledge and lets people learn the software by doing much more so than reading a blog post or a tutorial of some sort. Not to say that one is better than the other one. I mean, these things kind of go hand in hand, but it's always useful to have both of them and especially to have something you can dig your hands into and demonstrate how something works. Okay. Then there's the third C, community On companies. You could have someone on rotation entering customer queries on Discord, Slack, Discourse, whatever. So that could be part of DevRel too. It depends. This is why some companies have very different ways of thinking about these things. So the kinds of things he's talking about here are really crucial in building and nurturing a community of developers, and that's a really big part of the DevRel umbrella. We're going to hear much more about that from Lo because it's not easy to do it all, let alone to do it right. Before we move on, Alvin had one last piece of advice for companies who might be thinking about the cost involved of hiring a DevRel team. He says that you're much better off treating it as a cost rather than trying to account for any kind of return on investment because those returns are not immediate. It's very hard to say, "Oh, how much dollars did that save to, I don't know, maintain that rail track every six month versus every year?" It's very hard to know how much that cost because it's not how much that saved or that cost or whether that cost was worth it because it's not necessarily a very tangible, immediate impact. And DevRel worked a lot like that. He gives us an example of building relationships that don't have payoffs that are easy to follow and to track and to account for. If I go to a conference or a meetup, let's say on a smaller scale, I go to a meetup, there were about 30 people there, and the 30 people, 3 of them didn't know about Contentful at all. So I talk to them, blah, blah, blah. We had a conversation. One of them goes back to work, tries it, and then thinks, "Oh, it's cool." But they're working on another project right now. 6 weeks later, they try it again for a real project this time. But because it's a small project and they're trying it for the first time, they sign up for the free tier, there's a high chance they forgot about me or just cannot directly attribute that sign up. And again... And this is still the free tier, I've still made no money to the company at this point. But that's what it's all about, right? Yeah. Exactly. Isn't it about putting yourself and putting your product out there for the world to see? Because if you don't know it exists, how are you ever going to decide if this is the right tool for your job? So he is so right that sometimes those payoffs come much later, but you have to make that investment. I mean, think about us. We've used free tier trials for so many products, and if those products sing to us and they're great, we're going to put that money down. So we want to shout out whoever introduced us to this product or who put a bug in our ear. That's how communities are built. Now this person is a part of a community of users, and if they found value in this product, maybe they'll become a customer. When Alvin says, "It's not trackable, it's not measurable." It kind of reminds me of something that I've read where sometimes the biggest impact is maybe it's not necessarily something happening like sales or adoption of your application, but sometimes it's the absence of a negative thing happening. I'm thinking of, and this is another one of those, Kim talks about gaming again on the podcast, but I'm thinking about the launch of the PlayStation 3, which is regarded to be incredibly fractious and disastrous event because of going back to a thing that Alvin talks about, the SDK, the software development kits. Well, back in the day, I know it's hard to believe now, HD gaming was this new thing, and you had all these new consoles coming out, including the PS3, and those development kits went out to the developers that were making the games. But because they didn't have those development resources and that content to kind of teach them how to use the SDKs, that meant that their development processes were longer and it kind of missed the launch of the actual console. So you go to Astoria and you're looking at... You're going to buy a video game console. One of them has only 10 games and the other one has 50. Well, which one are you going to buy? It's kind of a no-brainer, and that's exactly what happened with the PlayStation 3. It really is a cautionary tale in modern day gaming about what happens when you don't have those resources that Alvin is talking about available to developers. That's a great example. I love that. For sure. Thanks for making it very clear for us. Yeah. So the developer relations teams, they're all about helping companies expand their user base or expand the number of partners that they have, working with them, building relationships with the developer community and making sure that resources are available to learn about and to try the software or to use it in interesting ways that people might not have thought of before. And Angela, like you said earlier, having a person to talk to when something isn't clear at conferences or meetups or community events to get to know the team to answer questions and act as an advocate for the community to the company, that's a really big deal because the developers then feel heard and they feel like they can actually invest their time and their resources into this product, which would become a little bit better to use, a little bit easier to use, and a little bit more for them. It's also very useful to have an advocate for the company to the community to kind of help smooth anything over to really explain the company's point of view and to relay any news that might not be out in a press release or in a blog or something. The developer advocate can be out there assuring the developer community, "Oh. Yeah. This thing is in the works. That's coming, but we haven't quite ready to announce it yet." Or something along those lines. Now, wait, there's more, developer advocates this is what I think most people think about when they hear the term developer advocate. Our next guest is going to talk to us a little bit about what an internal developer advocate role is all about. Oh. Now, do we all know what open source program offices are? No. Maybe. If I'm being honest with myself? Yeah, no, you have to tell me. I know we have one here at Red Hat. Yes. Okay. And our guest, Damani Corbin, is leading the strategy for Boeing's open source program office or OSPO. And these offices, they vary by company to company, but essentially for Red Hat, they're about advocating for open source of everywhere, that's what we do. For Boeing it kind of flips it around, and Damani is going to tell us a little bit about how his role is different from the one we were just talking about, but also very similar. Boeing has made some significant investments in technology, and if there's a way for me to advocate on, and even communicate on some of the best practices that are adopted internally, some of the technologies that exist internally, some of the good work that's happening internally, if I can be an advocate for that across the board, it raises the investment, it increases the adoption of the investment that we already made. So a lot of people want to go and grab the newest tool, but you aren't actually getting most of the existing tool that you already have. So you want the new bike, but you didn't actually take the training wheels off of your old bike. So that's the reason why you can't do the pop a wheelie like you want to, because the training wheels are still on. So how about if I teach you how to take off the training wheels so that you can start doing some tricks on the old bike? And a lot of that is kind of what we're doing here. Hey, there's a new and shiny thing, and don't get me wrong, there are a lot of programs and teams that do need the new and shiny thing, but you just can't jump from the old bike to the new bike without maybe looking at some of the things that you can do to improve your experience with your existing bike. I love that. Okay. So he's keeping people focused. He's keeping them on task. Use what you have, understand what you have first before you move on to the next new hotness. Yeah, I like it because it gives teams and organizations a sense of agency in what they're doing. They don't have to look at the new shiny thing, or maybe it would be better for them to look at the things and the tools that they already have in their possession or within their organizations, and that gives them a sense of agency and not kind of an urgency, which is the opposite of agency. You feel like things are going out of your control versus having control and having agency over what you do. Yeah. And he's taking that educational element of developer advocacy, and rather than putting them out to a community at large, he's kind of finding what's relevant to his company and then funneling those into his own internal community of developers, teaching people how to use the tools that they're using, or in some cases pointing out, "Hey, this is the other tools as well, that in some cases..." Like he said, "... might be the more useful tool to use." Now he's a resource for other developers and teams to learn and make the most of the open source software that they're using. Here's how he approaches that job. So our OSPO here at Boeing, I have three additional things. Well, my three things that I come out the gate with to say, "Here's the value that we're doing with our OSPO." Number one is, how do we help developers consume open source? Two, how do we enable developers or remove some barriers for developers to contribute back to the community? How can we be better stewards in this ecosystem? And three, how can we allow or enable intersourcing? So there's a lot of great things happening in pockets within inside of the organization. How can we shift some things around to enable some reuse inside of the organization? Again, it's flipping that direction of information between community and organization. Right? Yeah. But Boeing is a really large company. Yes, it is. Huge number of developers in there, and Damani's role as an ambassador from the open source community to the developers at Boeing has the potential to really pay dividends. In terms of the lessons learned. When I talk about focusing on incremental value, when we talk about an organization the size of Boeing, small change for a lot of developers is a lot of change. So those are the things I want to focus on. The little things that I can do to make developers a little bit more productive throughout their days and see how that's going to compound across the organization. When we think about adoption of any type of technology, if you can increase adoption a little bit, that's significant either savings or significant value add across the organization. Wow, we need to put that on a T-shirt. He's so right about that change is never easy in any organization, and he just captured it so clearly for us. I want to bring it back to our startup from the opening of our episodes. They're thinking of hiring a developer advocate. Does that person need to have a more external approach, thinking like Alvin and Lo, what they do or would it benefit them to also have a more internal perspective, more of an introspective kind of approach to developer advocacy like what Damani is talking about? What do you think, Johan? It depends on what they're trying to do and on the size of the organization. I think for our startup, which is still fairly small, and they're trying to really get users and more partners to use their technology, I think the approach with Alvin and really making sure that the company's getting their message out there, getting their tools out there, and making sure that people know how to use their tools and interact with them. That's probably their biggest concern at the moment. Right. But maybe this type of person can hook up with, I don't know, a solutions architect, and then have that kind of introspective approach. Because I feel like, going back to the Solutions Architect episode, they're kind of the person, if I'm not mistaken, embedded into a customer, or they could be a person who their prerogative is, "How do we solve problems for customers?" But if a developer advocate is looking at the developer as a, I don't know, their customer, maybe they can adopt some of those traits from the approach that a solutions architect would take to tackle some issues even within the startup and tackle some... I love the training wheels on the bike analogy that Damani made. Maybe that mentality is also part of the job. Maybe that's also needed. Absolutely. Part of the job of being a developer advocate is being that two-way bridge, I guess. Yeah, I agree. Where not only are you pushing things out, but you're bringing things back in that you're hearing from the community. I think, Kim, what you're saying here is rather than just bringing back feedback about how the app could be better, they could also be bringing back other things that they're learning from maybe the industry at large to build their applications and make it a better application in general, rather than just taking the feedback and the concerns that the developers are throwing at them. Yeah. It even would connect with the Product Manager episode. This is just all legitimately just coming to me on the spot, how all of these different jobs, they do different things, but they have similar characteristics, especially when it comes to feedback and trying to be agile and trying to anticipate or address the needs of customers, or in this case, developers. And they all have to work together in order to make the company as successful as it can be. Right? Yeah. If no one is sharing that information, if no one is taking the next step to turn that feedback into a bug report, a ticket, or... Yeah, exactly, then it doesn't get done and that the company kind of stagnates. But if they all work together, then they're off to the races. Now, these communities and the kind of feedback that you get from developers, that doesn't happen on its own. Right? Right. We're going to hear from Lo again about describing the kind of work that they do to nurture and moderate communities, because as we know, the internet can be a really unpleasant place if no one does the work to make it inclusive. Let's check in with Lo from the top of the episode. Before entering the tech industry, Lo started in social work and running community based programs. They told us about what they do to build an online community. So really, I am fostering relationships between developers in our community and the company. And what that means, and why it's important, is because building those relationships with developers, one; makes your product very close to what the developers want and need. But also you are building trust and loyalty through authenticity. So that means the relationships that I form in the community are genuine. I'm my authentic self when I'm speaking to developers in the community, and we have real conversations about the technical work that is going on and what people are doing, and in turn, because you have sort of built up that trust and relationship with the developers, you can then... Are able, and developers are much more likely to give you real feedback about your product and how it functions, which as a developer advocate, you can then take back to your product team, to the engineering team, "This X, Y, Z feature didn't really work and function the way that we perhaps internally thought it would." That's interesting. I mean, developer advocates really are relationship builders. Without that trust, without that loyalty, you're coming back submitting bug tickets, you're asking the questions and having that two-way communication, and that over time, that communication and that relationship, it grows. It's this two-way street that keeps working, it keeps the customers happy, it keeps the community happy, it gives developers the fodder. They need to be successful to make improvements. And this is what makes a company successful and developer advocates work for their stakeholders within and without. So again, we're finding out that this role is so important and relationships are just a really big part of it. We see that here. Yeah. And it's a really crucial component because the product is going to be a lot better if you get honest feedback. Now, it's one thing to get internal feedback on your code, but no matter how big your company is, your potential user base is likely to be much bigger and much more varied than your employees. And that means you're going to get more cases and opportunities for things to not go as planned. Those won't get fixed unless you hear about it. But again, as we mentioned earlier, that increased exposure to a wider audience doesn't come without risks. One of the things that led me to this career transition and where I'm at now, I've sort of always been into the internet, the computers, and I've been participatory in a lot of open source communities, a lot of development communities, and there is this level, or can be in a lot of those spaces of toxicity, but the ramifications of that and the consequences of that is exclusion. And so with my sort of social work brain, I started realizing, "Oh, this is exactly what happens in public spaces. In public communities." There are folks who are already in that space creating an environment that is not habitable for anyone that doesn't fit within the homogenous group that is already in that space. So I decided one of the things, and one of the skills that I do have is sort of counteracting those type of things. And what about if we start to nurture and transform digital communities into spaces where everybody feels welcome to ask a question, to get help, to present their work and ask for feedback and know that that feedback is going to be constructive. It is not going to be personal. I mean, we've all seen how toxic some environments can be online, and the ones who are trying to set the stage properly, they have their code of conduct and they try to enforce their rules. But if you're that person new to an already existing community and you raise your hand and someone shoots you down, that's very demeaning. It's up to the community as a whole to keep things safe and open and welcoming because without that... Bad news travels fast. So you really have to have that in mind, and I think when they put on their social work brain, it kind of showed that that's what they're thinking. This is a social experiment and being part of a social construct, you're really liable to get these types of elements, and as long as you're aware of it and you do your best to nip it in the bud and keep things safe and open for folks, people keep coming back. I mean, we've all been a part of those really good communities that you know they're talking the talk and walk in the walk, and we've seen the other side as well. So that kind of environment that's inclusive, that's open for people to ask questions or put forward solutions that may not work without getting immediately shut down. That kind of environment rarely springs up on its own, and trying to impose rules just from top down doesn't always work. But with that said, I think it comes with this sort of idea or place where you have to know that there needs to be some kind of education to the entire group to make that happen and to create that kind of space. You can't just go into a space and say, "This is what we're going to do." Because you can't make an assumption that people know how to create an inclusive environment. I love that. I did not think we would get into a conversation about transformative justice in technology, but here we are. I love it. Yeah. Part of the work that Lo is doing is introducing the idea of restorative justice to online communities. They told us that in their communities, they advocate for a process that leans away from punishment and instead tries to get the people involved to meet and talk about the event. That's where there's an opportunity for education. Does the person who caused harm understand that the harm that they've caused? Do they understand the impact their actions had? When you ban someone- That's interesting. Yeah, I like that take on that. And you don't get that opportunity for growth for the person who caused the harm to then be able to come back and participate in the community without being harmful to others. It's hard work, but it's worth it because not putting in that effort is a huge loss. One of the clearer losses is brain power and folks who have different experiences being able to solve problems differently and suggest new ideas. So in effect, you are missing out on a ton of creativity when folks come to your space and see poor behavior or toxic behavior and immediately say, "Oh, no. That's not for me. I'm out." You are missing out on what those folks could have contributed to your community and could have helped your community grow and expand. It's not quantifiable, but you have potential for great loss when these types of things happen. Yet another thing that's not quantifiable, but has such a huge impact. We're hearing that over and over again in this role. But yeah, they hit the nail on the head with that one. You never know what you're losing when people just are turned away from a community and you don't want that to happen because everybody has something to contribute. If you show up, you're supposed to be there. Yeah. And if you don't have developer advocates or DevRel team put in place right and there isn't necessarily someone in charge of moderating that community. Then it is just this huge potential for a problematic community to spring up and then just kind of stagnate over time. Lo related their work in community building in open source with the overall promise of the internet. Sort of the forefathers of the internet. They talked a lot about what the internet is for and who the internet is for, and they have always said, "The internet is for everyone." However, it won't be for everyone if we don't ensure access, if we don't ensure privacy, if we don't ensure the sort of financial piece of it. Is it attainable for folks? And without sort of people coming into the digital space gatekeeping those sort of things, what they originally intended won't happen, and so that's sort of how I think of it. So I like to think that I am working on, living up to what the internet was intended to be, which was a community space where everybody could come and everybody could contribute and have a space and collaborate with each other now all over the world. Well said. Right. I think that's a really important aspect of what developer advocates and developer relations teams can really do for not just companies, but for the online communities at large. I mean, this episode we've been talking about how developer advocates help companies and communities kind of grow and use products better and teach each other and learn from each other, and kind of act as bridges for communication. But I really love the way that Lo encapsulated how this work, although it fits and it has it's space within in companies and within open source, it also serves as this other... It serves this other purpose of making the internet as a whole more pleasant and a better place, and a more inclusive place for everyone to take part in. Exactly. Great communities make the internet much better. I'm a part of some really great ones. I want to parrot that. That's literally what this is all about: bringing people together. And when it's welcome and open and safe, the magic happens. The magic really does happen. Absolutely. I think that it's interesting that as we are coming on to the end of the episode and the end of our series, we are ending on a note of, I don't want to say uncertainty, but kind of a little bit of what is on the horizon? We're kind of coming to a point where our startup and also the position of developer relations or developer advocacy kind of has a choose your own adventure type of feel to it. I feel that the sky is the limit kind of when you're dealing with these three Cs, the community building that Lo is talking about, the code and the content that Alvin mentions Damani's approach and introspectiveness about looking within for solution building or looking within for finding ways to collaborate and how to build new things. I feel that this part of the show is... for me, it's very transformative, I think. Because I went into this not knowing what a developer advocate was. A lot of these other positions we've covered on this series, I don't know anything about what they were entailed. I just knew them from seeing them on job descriptions on the internet, but the way that these pieces interact and the way that they interconnect with each other, it builds something that kind of has a potential that isn't quantifiable, if that makes sense. Yeah. The startup becomes more than just the sum of its parts, the sum of the different positions that are put together, and when everyone works together, towards a common goal. Then it's just a magical thing to watch. We are kind of at a crossroads, right, Johan? Yes. Like where are we at with our company, with our startup? The startup is doing well. They're headed for an exit, like we mentioned at the top of the episode, and to get there, they were really deliberate about building their team. They were able to make the app support it and grow its use, and it's turning out to be a big success. They're ready for what comes at them and whatever the next steps are, they're in a good position to plan to expand their teams even more. I wish our little startup well. Wow. This episode just spoke to me, and I hope it spoke to you as well. We want you to share your thoughts with us about it. Tweet us at Red Hat using the hashtag #CompilerPodcast. Even on Instagram. We want to hear what you think about one, our series Re:Role in all of the roles that you may find in a startup, but specifically, we want to hear what you think about the developer advocate roles. I know that there's a lot of you out there, although your names and titles may be different, but you're doing the good work and we want to hear from you. So yeah, hit us up. And that does it for this episode of Compiler Re:Role and for our series. Today's episode was produced by Johan Philippine, Caroline Creaghead, and me, Kim Huang. A big, big thank you to our guests, Lo Etheridge, Alvin Bryant and Damani Corbin. Thank you. Victoria Lawton is our bridge over troubled waters. 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, Brent Simoneaux, Nick Burns, Aaron Williamson, Karen King, Jared Oats, Rachel Ertel, Devin Pope, Matias Foundez, Mike Compton, Ocean Matthews, and Alex Traboulsi. If you like today's episode, please follow the show, rate the show, leave a review if you think that'd be nice, and share it with someone. It really, really helps the show. Thank you so much for listening. Until next time. All right, everyone.

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

Red Hat Enterprise Linux 10: Ein Betriebssystem denkt neu – und zwar von Grund auf

12 de agosto de 2025  |  Matthias Kranz

...

Publicaciones en el blog

Red Hat Named a Leader in 2025 Gartner® Magic Quadrant™ for Container Management for the Third Consecutive Year

11 de agosto de 2025  |  Sara Buffington

...

Containers

Programas originales

Fail Better | Command Line Heroes

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

Programas originales

Command Line Heroes: Cuarta temporada: Una cosa más con Steve Wozniak

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.