Console

David Mytton [00:00:04]: Welcome to another episode of the Console DevTools Podcast. I'm David Mytton, CEO of Console.dev, a free weekly email digest to the best tools and beta releases for experienced developers.

Jean Yang [00:00:15]: And I'm Jean Yang, CEO of Akita Software, the fastest and easiest way to understand your APIs.

David Mytton [00:00:22]: In this episode, Jean and I speak with Christina Warren, senior developer advocate at GitHub. We start with whether there is a typical day in DevRel, discuss how to get started in DevRel, and the types of skills needed. Hear about how Christina sees her role as a bridge between the community, product engineering, and the developers using the product, and where video fits into it all. We're keeping this to 30 minutes, so let's get started.

We're here with Christina Warren. Let's start with a brief background. Tell us a little bit about what you're currently doing and how you got here.

Christina Warren [00:00:57]: Sure. Thanks so much for having me. So I'm a senior developer advocate at GitHub. So I work in developer relations, which I think we're going to be talking more about, basically, helping connect our community of developers of all stripes, connect them with some of our engineers. I work on a lot of video content, and I try to find the coolest things that are happening within our community and spread the word about that sort of thing.

I've been at GitHub for about a year. Before that, I was at Microsoft for five years in a similar role to what I am at GitHub, although there I was working in the Azure business group. My last year there, I guess, I was working on Linux tooling and Azure. So that was a fun challenge. Before I joined Microsoft, I used to be a tech journalist. So I have sort of an unusual path into engineering in that I don't come from a traditional computer science background, although I've been coding and tinkering for a really long time. But I moved from being a journalist into being an engineer. Now, I'm at GitHub, which is fantastic.

Jean Yang [00:02:00]: Christina, we're really excited to talk to you, especially because we both talked to many people who wonder what developer relations is as a job. So we were hoping you could talk a little bit about what the typical day looks like and if there even is a typical day.

Christina Warren [00:02:16]: That's a great question. I think that it depends on the person and the job because there might be some people who work in DevRel who do have a really typical day. I can say for me that I don't, right? So we are recording this on a Thursday, and I record a weekly video show that I do every week on our YouTube channel called The Download, which is a rundown of the latest news and open source news happening around the world.

So to prepare for that show on Thursdays, what I typically do is I've been collecting links throughout the week. But then I'm searching through Reddit, I'm on Hacker News, I'm on Twitter. I'm finding the stuff that I want to talk about. I'm writing a script. I'm preparing assets that I can get our editor because we have a really quick turnaround time. I'm putting all that together, and then I walk into the studio, and I record that. I'm able to do that relatively quickly. Then my editor, — he’s fantastic — will edit it, and we'll get it up Friday morning. So it's a really fast turnaround time. So that's what I do on Thursdays.

But next week, I'm going to be at the Southern California Linux Expo, SCALE, and I'll be working a booth, I’ll be going to events, I'll be attending sessions and talks. So that will be very different from what I'm doing today. Then there are some days when I'm just in meetings all day, where I'm talking with product teams. I'm coming up with strategies and trying to figure out what sort of content and what sort of stuff we want to make next.

So the role is different, depending on what you're doing. But, for me, a lot of it comes down to being really engaged and really aware of the community, our audience, and being up to date, as much as I can be, on everything that we offer, and honing my skills to make the best content that I can.

David Mytton [00:03:56]: Interesting. Would you say that your journalism background has been an advantage? How's that affected things?

Christina Warren [00:04:04]: Yeah, I think it has been and it's weird because it was funny; when I originally went into journalism, I graduated from college when the economy collapsed and so that curtailed my plans of going to law school. I've always been into software development, especially web stuff. I've always really liked open source. One of the careers that I thought about at the back of my mind, it was a little bit different than was, “Oh, well. Developer Relations might be something I could do.”

I wound up going into journalism instead and did that for a long time. But I think that the connecting thread there for me is that a lot of journalists – and I certainly was one of these – is really, really curious. I have an insatiable curiosity. I want to learn. I want to get to the bottom of something. For developer relations, that's perfect because I'm always trying to keep abreast of what is the latest thing or what does the community want to know about? I want to learn as much as possible. So I think that that curiosity really helped me out.

It was also really beneficial to being able to go into scenarios where you might not be an expert on everything in a certain area. To be clear, this isn't true for all DevRels. Some DevRel folks are absolute experts in a certain niche. But for a generalist like myself, the experience I had as a journalist is really useful because I know what it's like to take on an area that I might not have had a lot of previous experience with and how to get really deep on it really quickly. Or how to experiment and maybe mess up and just figure something out. That has been really beneficial.

The last thing I would say is a lot of the job is communicating. A lot of it is talking with people. That is also a lot of the job of journalism. A lot of it is communicating, whether it's through writing or talking on the phone, or meeting people in person. A lot of it is communication. So that definitely helped because that's not something that every person is necessarily comfortable with. But it is definitely something that I think is absolutely essential in DevRel.

David Mytton [00:06:02]: Would you say you've learned anything in particular about communicating to developers that you think should be highlighted?

Christina Warren [00:06:10]: Yeah. The biggest thing is — and I knew this myself because I considered myself a developer going into this — is don't lie to people. Don't blow smoke up anybody's behind, right? Be honest and be authentic because developers can smell BS a mile away. They see it. They don't like it. In fact, most people don't like it. But developers really don't like it. It does you no advantage by doing that. If you come across as being a salesperson, that is not going to work when you're communicating with developers.

Jean Yang [00:06:44]: Yes, that makes a lot of sense. Thank you, Christina. Going back to what is developer relations, I had a follow-up question, which is how do you know when hiring someone for developer relations or when you were interviewing for developer relations, how do people know if someone is good? What do you look for? What are the traits that make a good developer relations person?

Christina Warren [00:07:05]: So I would say, for me, the first thing that I look for, and I think that this helped me a lot as well getting hired for my jobs, is be excited about tech. Whatever focus area it is, being excited about it and being genuinely excited because, again, developers can tell the difference. We can tell if somebody's really hyping something because they're into it, or if they're hyping it because they're getting paid to, or because it seems like that's the latest trend. So being genuinely excited about something, no matter how esoteric it is, no matter how small it is. If I can see that someone is genuinely excited and wants to share that, that, to me, shows that this is somebody that could be really good at developer relations.

The other thing is — and again I think this helped me when I was getting hired — is people who are just naturally wanting to create content, whether it's blog posts, or small side projects, or even tweets on their own to share what they've learned. Again, it goes back to that excitement factor. But people who are willing to show things off and explaining things to people or learning from others. That's a really great sign. If somebody is really, really good at creating, even if it's just a small side project and just putting it up on GitHub and talking about, “Hey, this was my journey in exploring X, Y, or Z,” that's a person who's going to be really, really good in DevRel.

David Mytton [00:08:19]: Right. There's loads of opportunities to do that. I suppose Twitter is a good example. It’s very easy to do. But there's always an excuse to rebuild your own personal blog, right, in the latest technology?

Christina Warren [00:08:29]: I saw this meme the other day, and I felt personally attacked. It was showing. It's a graph that showed the process like how many blogs you've posted versus the number of posts versus, I guess, how complicated the setup was. The thing that had the most posts was just like, “Standard WordPress site from 2004". Then it goes all the way down to “Welcome to NGINX”, which is where I felt very, very seen and personally crafted static site generator or migrated from Jekyll to Hugo. I was looking at this image, and I was like, “Oh, my God. I'm literally all of these things.”

So you're exactly right, I mean. Honestly, for me, a lot of the things that I play around with and even test out on, and this was before I even joined GitHub, has been like, “Okay, what website of my own can I rebuild for the fourth time?”

Jean Yang [00:09:14]: Yeah, this makes a lot of sense. I feel like they're probably – I mean, I also have this personality type. I bet a lot of people listening out there are thinking, “Wait, that's what I do. How can I turn this into an actual job?” So I have a follow-up question to that, which is how do people convey that this is who they are? How does it get measured in a DevRel job? Because I bet this is a dream job for lots of people out there who just love playing with different technologies and telling people about them.

Christina Warren [00:09:45]: No, you're absolutely right. I mean, for me, it was the perfect dream job. I think the way that people get into it, A, is you start out by just doing those things that the DevRels do and sharing it with people, whether that's on Twitch or YouTube or TikTok or Twitter. Twitter's a great place for a lot of us. LinkedIn, even, right? Showing it off and even a personal blog. Just continuing to put the stuff out there really, really helps because you don't always know who's watching. Sometimes, you might not even have any audience but it will grow over time, especially as you engage with communities.

That's another thing I would say too is get engaged with the communities that you're interested in. It doesn't have to be related to a specific company, although if a company has a steward behind something that can be great. But getting engaged with those communities and being part of that is a really big part of developer relations. I think that what we've seen over time, anecdotally, what I've certainly seen is that a lot of people who have moved into corporate DevRel roles are people that were really well-known in their respective communities beforehand because that makes sense. Those are the sorts of people that you want to be acting as the face of your product or your company. Those are the people that you want to be showing people how to do things.

But the other side of DevRel is that a lot of it is about feedback. It’s about working with product and with engineering teams and letting them know, “Hey, this idea you have might be great. But this is actually a use case that we see, and we know this because we're in the community.” Or, “Hey, this really isn't working well, and this is why.” These might be unexpected things. It can also be an opportunity where the product teams and the engineering teams can come back and say, “We made this decision for this reason.” That gives the DevRel an opportunity to then, when they're talking with communities, to say, “Hey, this is why this works this way.” Maybe there's some changes that can happen. But you can be transparent to say, “This is why this works this way.”

A lot of times, you do become an unofficial point person for the company you're working for. So having strong ties to the communities that you're part of goes a long way for that because, “Okay, I know Christina. So Christina is somebody that I can count on if I have a question about something with GitHub or if I have a problem with my account.” I personally might not be the person who can fix it, but I can track someone down, right? If we know each other from those same spaces, it makes it a lot easier than trying to reach out to the void of a giant company or even a smaller company out there.

David Mytton [00:12:09]: So it's acting like a bridge really between the community and then the internal functions of whatever the organization is.

Christina Warren [00:12:16]: You nailed it. That’s even how I've described the function internally to people before, especially at Microsoft, when we would have to explain what our function was. Or I would even say we're the API between the community and the users and the company itself.

To answer your question about how do you measure success, that's hard because a lot of the things that you would typically measure are not one-to-one. Some things you can have a massive impact on over time that you wouldn't necessarily be able to measure on saying, “Oh, this decision was responsible for this result,” because it could be a talk that you gave convinced somebody to look more into your product or helped someone solve a problem. That could be a big impact, but it might not be measured in that way.

So that’s one of the big challenges that a lot of – I've talked to a lot of people in developer relations at a lot of different companies, and that's something – that's a challenge we face, which is how do we measure our impact. So you have to kind of – the same way any KPIs and OKRs are measured; you have to be a little bit creative with the numbers, and you also have to be a little bit creative with what goals you're setting. So you have to figure out, okay, well, is our goal maybe to get new users or signups for a certain service or to raise awareness about something? If that's the case, then we can measure, “Okay, if there was a link that your DevRel was using in their content, how many clicks has that had and how many conversions?” But you could also do things like, “What is sentiment on social networks? or, ”How many other pieces of content have been created or projects have been created using something?”

There are different strategies that you can do. But that is one of the struggles is that a lot of times the stuff that you can do that can have a really big impact is not easy to measure as easy it would be to be looking at it, “Okay, I've added this new feature to a product. I can tell from telemetry that it's been used really well.” Or, “I can tell from support requests that things have maybe increased a lot. So maybe there's a problem here.” You don't have that same ability. So it’s a challenge.

But, to go back to the theme I've been sharing here, one of the things we can do if we can't measure impact as granularly as we would like is we can look at feedback from the community and feedback from the users. Because I think when at its best, developer relations, as you said, is that bridge. So that's a really good way of judging how well something is working and what's working and what's not, is to look at the feedback and the sentiment that you're getting from your users.

Jean Yang [00:14:43]: That's really interesting, Christina. Yeah, that makes a lot of sense. A follow-up question related to that is where does DevRel typically sit in an organization, and are there conflicts with the rest of the organization because of how it's evaluated differently?

Christina Warren [00:15:00]: Yeah, there can be, for sure. So I think that developer relations should be part of product and engineering because I think that it is a really core part of that. That said, to be successful, DevRel needs to be cross-functional so some companies have it under marketing. For their purposes, that might make sense. I think that it makes sense for it to be part of product and engineering. But I think that it's cross-functional insofar as I work with people on basically every different team at GitHub.

That's one of the things that's great about GitHub is that they have a really good understanding and appreciation of the value that we can bring because we can help the product teams and the engineering teams create assets for their blog posts. We can help them with their message. We can highlight things because we are on the ground all the time. We can go, “Hey, hey. This thing happened and this is causing problems. Do we want to get ahead of this? And how can we make something better?”

We can also talk to people. A lot of times, what happens, a lot of some of the content and things that I highlight is I'm just talking to an engineer. They’re telling me about this thing they're doing. I'm like, “That's so cool.” I have the ability to maybe frame it in a way and share it with the public in a way that they might not have thought about and say, “Hey, look at this very cool feature. Look at this really cool thing that was built.” So it can be difficult sometimes for people who might not understand the value, but I think that at its best, it's something that works across different groups.

When you talk about conflicts, that does become an interesting thing. Because the way I see my job — and I can't say this for every person in DevRel — but the way I see my job is like my title is ‘developer advocate’, but I'm not advocating for GitHub. I'm advocating for GitHub’s users. I'm advocating for our community. That's really what I'm trying to do. Because I think that by advocating for them, that's how GitHub can be most successful.

But, of course, not everybody and not every company might not see it that way. They might see it as, “Oh, your only job is just to praise and talk about how great we are.” I don't see it that way. I think that to be really successful, you need to be transparent, you need to be honest, you need to be authentic. That includes when there are situations where you might screw up or when things might not be right because I think that that's what builds trust. But that can sometimes be difficult to explain.

I haven't had this problem with GitHub, but I certainly know people and I've had other experiences where there can be a mismatch of expectations. I always have to be really clear. The audience, like the people that I'm working for, I'm advocating for the user. I'm not here to convince someone that something that maybe is not working correctly or isn't well-structured is good. That’s not my job.

Jean Yang [00:17:32]: Are you allowed to talk about any stories of when you advocated for the user intention with product and engineering teams, and you helped the user win?

Christina Warren [00:17:42]: Yes. So this was what I was doing my last year at Microsoft. I was really strongly focused on the Linux tooling and Azure. That was an area that, frankly, didn't have a lot of attention. There are a lot of groups at Microsoft that are actually dedicated to Linux, which might be surprising for a number of different reasons, but there are a lot of Linux groups. But the thing is that there are a lot of various levels of stakeholders.

So one of the things that I worked with, with a lot of those teams was pointing out, especially when some of the product teams, when they were speccing how certain things would work, is like, “Okay, has this been tested on Linux more than just an ancillary— Like we've had it pass a unit test, but have you actually gone through the user experience? Has this actually been done and working with them to make sure that that experience of using the CLI tools would work as well, whether somebody was using Linux VM or Linux on the desktop, or Linux as part of Windows, and making sure that we can make that experience as consistent and as good as possible?”

That was something that I think was really great, and I hope that people were appreciative of that. I think they were to say, “Hey, we have somebody who's coming in with this perspective and is able to –” I'm not going to say argue because it wasn't really a fight, but really champion this perspective and this particular use case that might not have otherwise been top of mind because they're anticipating people using a portal or maybe using PowerShell scripts to automate things from a Windows machine. They're not anticipating people using a terminal emulator on a certain variant of Debian or something, and what the interferences might be like on a networking level.

That would be really useful to be able to say, “Okay, this is the feedback I'm hearing, and this is also even the way the CLI is designed. This is the feedback we have about challenges people are having, and this is what people expect, how people expect this to operate. What can we do to make sure that it operates as they expect?”

David Mytton [00:19:40]: That makes sense. So I suppose you're sitting in the different communities. You mentioned smaller companies there as well. I suppose you've spent quite a lot of your time in recent years at larger companies. What's your experience been and what’ve you learned from, I suppose, fellow DevRels at smaller companies and startups and how the teams grow and how that changes over time?

Christina Warren [00:20:04]: Yeah. I mean, it's interesting. So when I joined Microsoft, I was one of the first dozen or so people on, I guess, what they had then reinstituted. They were doing the DevRel within Azure, and the team wound growing to a few 100 people. But I was there early on, which was interesting because Microsoft is certainly, not a startup, not going to claim that at all.

But as we were building out, I think that our experience was not dissimilar to smaller companies figuring out DevRel, although many of them might have one or two people, rather than starting out hiring a dozen or so. I think the real thing is that – and this is true if you're starting the DevRel program at a big company or at a smaller one – is you start from the beginning. You start laying the groundwork of, okay, what are your goals? What are we wanting to accomplish? Are we trying to raise awareness? Are we wanting to be that bridge factor? Do we need to create examples of what people can do to try to encourage other people to do things with our work? Then finding people who can build and grow from there, depending on what your capabilities are.

The biggest challenge that smaller companies face, especially, is that DevRel is one of those positions that a lot of the people who are in it can fit into a lot of different categories. It can be a jack-of-all-trades sort of job, which is great. But the downside of that, especially if you have a small team, is that there's a couple of people or one person, there’s only so much they can do. So it becomes really important to prioritize what you're doing and to make sure that the activities that you're doing are going to be the most beneficial for everyone.

So, okay, I might personally really like this one area. But it's not the most popular thing in the community. It's not the thing that the engineers need the most feedback on. It's not the thing that marketing is wanting to push. So maybe I'm not able to focus on that right now, and I need to focus on this other thing and finding and being okay with that, just because there are only 24 hours in the day, and there's only so much you can do. I think that's the challenge.

I think at bigger companies, the challenge, it’s also getting people spread thin. But I think it can also be an area of figuring out, okay, it's almost the inverse in some ways, where it's like, “Okay, how can we be focused? And what role should people be in, and should we have specific people that are really taking ownership of a certain area?”

That's hard for me, I will say. Again, I'm a generalist, and I love being a generalist. But I'm one of those, I think there was a term, like a “T-shaped engineer” and I'm certainly that, where I have a lot of breadth but not necessarily a lot of depth. I have depth on certain things. But I like to dabble with a lot of things. I love that and I love that I have that ability. But I have struggled before, where I've said, “Okay. Well, I have to be more focused on this one specific area.” Even though I might personally love to do a bunch of different things, for my job to be most beneficial, I really need to be focused on this one specific area.

Jean Yang [00:23:04]: Christina, digging more into that, I would love to talk more about where DevRel ends and product begins or vice versa. Because, at my company, we don't have DevRel yet. That's something very top of mind for me. A lot of what you've talked about in terms of advocating for the user, one would think that product would do that as well. So I'm curious how DevRel works with product, what the roadmap conversations are like, and how much is reactive, where you and other developer advocates notice things and get those added in, versus you’re meeting at the top of the quarter or the beginning of the year and making sure that user requests are getting met in the roadmap, to begin with.

Christina Warren [00:23:47]: Yeah, I think it's a great question. It’s really interesting because I've watched so many of my friends go back and forth between product and DevRel. I think that they're complementary in a lot of ways. Again, I think that, really, it comes down to expectations. I want to be very conscientious as a DevRel person that, when I'm invited to product meetings, I'm a guest, and they consider me a partner and a stakeholder. But I'm not the product manager, right? I always want to be very clear on that, that I'm not dictating the roadmap. I'm not dictating what they should be highlighting. I can add input. I can maybe help when people are trying to figure things out, if you're having that quarterly meeting and say, “Hey, these are what our goals and priorities are.” I can maybe be a voice in that conversation, but I'm not making that decision at the end of the day.

If it gets to the point that you want to be making those decisions, then I think that it makes more sense to be in a product role. But I think the difference is that PMs, people in product, although they definitely talk to people, their users, and their communities and are doing those feedback studies, a lot of times, they're doing a lot of other things too. They're managing a lot of other priorities. They're trying to figure out the engineering workloads. They're trying to finish their sprints. So they can't always be cognizant of the things that might bubble up, the edge cases, right?

I think that's probably the biggest difference is that you don't always have the ability to see the deepest edge cases that DevRel can really help highlight. Then you try to work together about, okay, how can we integrate this, or what is the solution for this? I also think that me, as DevRel, although I might see those edge cases, I don't always see the complete picture that product is doing. I don't always see the reason why this decision was made. So again, that's why communication between the two groups is really important. Because if I can understand why this decision was made, I have a much better job of, A, explaining that to the audience and sometimes just being transparent. “The priority is this right now. We hope to get to this at another time, but the priority is this.” Or to say, “Oh, okay. This is something that you're wanting a lot of feedback on. What can I do in terms of maybe creating content or raising awareness in other ways? What can I do to help with that process?” So the product teams don't always see the edge cases. But I don't always see what the grand plan is.

So I think that the line can be really blurry. Again, you see people go back and forth between the two roles a lot. In some companies, they might be really similar. I think when you start out, I think they start out really similar. But I think that people understand what their roles are. For me, understanding that I go to product meetings, and I'm learning about things, and I can offer feedback, and I can raise flags that I might see and that's really important to do. But I'm not the one who's going to be making those decisions because that's not my job.

David Mytton [00:26:29]: On the communication side, what would you say is your favorite medium? You do a lot of video. YouTube has become very popular for developers, although, personally, I prefer reading things but many of my friends are always on YouTube. What do you like, YouTube versus Twitch versus TikTok? What's your take?

Christina Warren [00:26:46]: I personally love YouTube, but I'm like you, I do love to read things. I don't blog as much as I should. But I love to read things, mostly just because I can read a lot faster than I can listen. But I would also say that, to go back and forth, I will say a lot of times when I get started with a project, I love to read it first. But then if I'm running into a problem, I really do love to watch a video and see how someone got through it. That can help me because I'm a visual person in that regard as well.

I mean, this is what the fun is in DevRel. We have a pretty great TikTok account. I don't run that. Kadesha, who's one of our newer DevRel members of GitHub, she does a lot of stuff on that. A lot of our other team members contribute. I've seen so many people build really great platforms for themselves on TikTok. I still haven't. I enjoy TikTok, and I'm on it all the time. But I don't really create on TikTok or reels that much. But I'm more comfortable with the production nature of YouTube because I have more experience with that. But I love that.

I'll say I love Twitter. I think Twitter is – the problems that Twitter is having notwithstanding, it's a great place to reach a lot of people. But not only that, it's a great place for me to hear feedback and just to find cool things. I see really great stuff that people are building on Twitter, and that's always fantastic. I would also say, like to plug GitHub, GitHub is a really great place because people put their projects up, and there's great things happening in discussions. You can find really cool stuff.

My GitHub stars, I always tell people like, “Don't follow me on GitHub to find my code because you don't care about that. Follow me for my stars,” because I find the most amazing and interesting projects. I have 2,000-something stars, and I was doing that long before I ever joined GitHub. That was even one of my pitch in my interview. I was like, “Look, I'm a super fan because I find this stuff, and I'm interested in it.”

That’s a great way to communicate and learn because I know, for me, I learned a ton, just by looking at somebody's small project that might not even be well-documented. More documentation is always better. But I can look at it and go, “Oh, okay. This is how this works,” and gives me ideas. I could integrate this in my next website rebuild the next time I decide that I'm going to rebuild my website. Use this feature because I liked what this person did.

My favorite thing in the world is to be on someone's website and see something that I really like. Then looking and seeing in their links if they have a GitHub link and then seeing if their website is in their GitHub account and then star that and be like, “Okay, cool. Now, I could look through and see how you did that thing that I liked.” I love that.

David Mytton [00:29:15]: You're always on Twitter as well, Jean. You're always tweeting loads of stuff.

Jean Yang [00:29:19]: Yes. I love Twitter. I mean, I just – I have always been on the Internet. That's how I learn things. I really identify with what Christina said. That's how I met Christina, Twitter.

Related to that, though, Christina, there's doing this for fun, and then there's making DevRel a job. So what does success look like in DevRel? Because I have an adjacent example of there was a recruiter everyone told me about. They said, “I love this recruiter. I talk to them all the time.” Then none of them actually seem to take jobs from this recruiter. We talked to the company that the recruiter worked with, and they said, “Oh, they don't work with us anymore because they weren't closing any candidates.” So I can Imagine a situation where someone is really good at one part of the job. But the metrics are actually something else. So I'm curious, what do people evaluate DevRel people on? How do you get promoted? All of the questions that are terrifying, people don't like talking about.

Christina Warren [00:30:16]: It's a great question, and it's a hard one. So I think that, again, this goes back to the earlier question you had about how are you measuring impact or success. But from a personal level, yeah, I think this becomes where it's really important when you're hired to set those expectations with your company and say, “What are you wanting to get out of this?”

For me, one of the things when I came in, frankly, was to grow the YouTube audience and to grow views and watch time. I had been successful at that at Microsoft. We've been successful at that over the last year at GitHub. So that's one of the things that I'm sure that my bosses look at. But I certainly look at it. I knew when I came in, I was like, “I know video, and I know how to do this stuff well.” Again, my journalism background is very, very useful there. So I think it depends on what you're wanting to do because there could be some people where you're like, “Okay, we're wanting to maybe reduce support requests on a certain thing, or we're wanting to gain adoption of a certain feature.” That would be how you would be measured.

But you're right. There is – and this is what's really important. I'm glad you brought this up — It is a job, right? I love my job, and I love what I do. A lot of the stuff that I do I was doing years before I ever worked in developer relations. I was a journalist, and I was doing this stuff, and it had nothing to do with the stories I was writing about. It's just stuff I was interested in. That helps, but it is a job. That is an important thing to keep in mind.

I'm advocating for the community. That is my frame of reference. But I'm still working for a company. I think that similar to your recruiter friend, you can't lose sight of that, right? You’ve got to realize that it would be great if we could all just do only what we wanted to do and just talk all day and get paid for it. That's not how that works, right? So I'm thinking about, “Okay, what can I do that can further the goals of GitHub, get more people, hopefully, using our products, giving their feedback, getting interested in development.” That's a big part of it too.

I think being clear when you get hired what the goals are, and then also just recognizing, yes, this is a job. That means that sometimes, as I was mentioning earlier, you might – I really am obsessed with this thing, but this thing is not what everybody else is obsessed with. Cool. You can on your own time do that. But at work and whatnot, maybe I need to make more content around this other thing.

Jean Yang [00:32:36]: That's really helpful. Thank you. I bet this would also really help anyone who listens to what you say and thinks, “Oh, my gosh. I would love to have that job. But is it real? Where's the catch?”

Christina Warren [00:32:47]: Yes. The catch is, yes, it is a job, right? You're still working for a company. Like I said, I'm authentic and I have my own kind of values about the things that I will share or not share. I think the only reason I have an audience is because people know they can trust me that I'm not going to talk and get excited about something if I'm not excited about it. Again, it wouldn't be helpful to anybody for me to do it any other way.

But, yeah, I work for GitHub. So I'm going to post a lot about GitHub. That's the job. That's part of the appeal. I'm not going to ignore that part of it. Sometimes, I think people do ignore that part of it. They think that— It's this weird thing because developers can smell BS a mile away, and you want to be authentic, but you also have to be honest. I think, I don't know about either of you, but I'm much more willing to accept if someone's preconceived bias of being like, “I work here, and I really like this thing because it's cool.” But I know that they work there. I'm okay with that versus –

Jean Yang [00:33:43]: Me too. I expect it.

Christina Warren [00:33:44]: I expect it. But I'm also – I'm okay with that, versus somebody who works at a place and then it's nothing they ever write about or do that seems work-related is associated with their job. That always feels weird to me. I don't know.

Jean Yang [00:33:56]: Same. To me, it's similar too. If you're asking someone for a reference on someone, you know they have to, one, talk about the person, two, say something good. But what they're saying is often really telling.

Christina Warren [00:34:07]: Yes. I think you're exactly right.

David Mytton [00:34:10]: So before we wrap up, I have two lightning questions for you.

Christina Warren [00:34:14]: All right.

David Mytton [00:34:15]: So the first one is maybe you’ll have to look through some of your recent stars, but what interesting DevTools have you been playing around with recently?

Christina Warren [00:34:23]: Okay. So there's so much cool stuff happening with ChatGPT. That is going to be, say, the first thing. So the ChatGPT and Whisper APIs were released this week as we're recording this. There's so much cool stuff happening with that. So that's the first thing I would say.

This is DevTool in a sense, but Hassan, who's a DevRel at Vercel — and he's amazing — he and some other people introduced me to a project called Commit AI, which basically creates commit messages for you using Open AI. It’s brilliant, and I love it. That's the sort of thing. Okay, I know there's drama. People are like, “Oh, but commit messages should be why you changed something, not what you changed.” In a perfect world, you are right. But I don't do that, and I don't think 95% of the other people do that. My commit messages are usually like an expletive and I fix this thing. That's usually what it is. So if I could actually have something that could be helpfully descriptive and that I can do in my command line automatically, yeah! Maybe if I get that taken care of, maybe the next step can be now I can add some context about why, right? It’s baby steps. So that's one that I'll just say off the top of my head. I know that wasn't a lightning answer. But Open AI stuff is bananas right now. So that's what I'll say.

David Mytton [00:35:37]: Okay, great. Then tell us what your current tech setup is, the hardware, software that you're using, just on a daily basis.

Christina Warren [00:35:45]: Yeah, so I'm primarily a Mac user. I have two 2021 MacBook Pros of a 14-inch that I've got myself. Then I have a 16-inch that GitHub provided for me. So those are both M1 Macs units. Then I also have a 2020 iMac. It's an Intel iMac, but it has 128 gigs of RAM and a four-terabyte hard drive. So it's really powerful, and it's still really, really good. So that's my day-in, day-out computer.

I also have a gaming PC that I built during the pandemic, like a lot of people, that doesn't get a lot of use. But the useful thing there is that it does have an Nvidia GPU. So if I'm wanting to run different AI stuff like Stable Diffusion or running Whisper, I have that.

Jean Yang [00:36:26]: So jealous.

Christina Warren [00:36:27]: Yeah.

David Mytton [00:36:28]: Excellent. Well, unfortunately, that's all we've got time for. Thanks for joining us, Christina.

Christina Warren [00:36:33]: Thank you so much for having me. This was awesome.

David Mytton [00:36:36]: Thanks for listening to the Console DevTools Podcast. Please let us know what you think on Twitter. I'm @davidmytton and you can follow @consoledotdev. Don't forget to subscribe and rate us in your podcast player. If you're playing around with or building any interesting DevTools, please get in touch. Our email is in the show notes. See you next time.

[END]