Welcome to another episode of the Console DevTools podcast. I'm David Mitton, CEO of Console.dev, a free weekly email digest of the best tools and beta releases for experienced developers. And I'm Jean Yang, CEO of Akita Software, the fastest and easiest way to understand your APIs.

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. Sure. Thanks so much for having me. So I'm a senior developer advocate at GitHub. And 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. And 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. And my last year there, I guess I was working on Linux tooling and Azure. So that was a fun challenge.

And before I joined Microsoft, I used to be a tech journalist. So I have sort of an unusual path into engineering and 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. And now I'm at GitHub, which is fantastic.

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

This is a great question. And 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? Like, 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 sort of a rundown of the latest episodes.

news and open source news happening around the world. And 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. And I'm able to do that relatively quickly. And then my editor, he's fantastic, will edit it and we'll get it up Friday morning. So it's really fast turnaround time. So that's what I do on Thursdays. But like 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. And

And so that will be very different from what I'm doing today. And then there are some days when I'm just in meetings all day where I'm talking with product teams and 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 sort of content that I can. Interesting. And would you say that your journalism background has been an advantage? How has that affected things?

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. And I've always been into software development, especially web stuff. And I've always really liked open source. And one of the careers that I kind of thought about in 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. And for developer relations, that's perfect because

I'm always trying to kind of keep abreast of like, what is the latest thing or what does the community want to know about? Like I want to learn as much as possible. And so I think that that curiosity really helped me out. And 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. And this, to be clear, this isn't true for all DevRel. Some DevRel folks are absolute experts in a certain niche, but for a generalist like myself, it's,

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. So,

That, I think, 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. And 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. And so that definitely helps 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.

And would you say you've learned anything in particular about communicating to developers that you think should be highlighted? Yeah. I mean, so 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 business.

behind, right? Like be honest and be authentic because developers can smell BS a mile away. They see it, they don't like it. And 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.

Yeah, 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?

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 being 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 is 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, like 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 like,

things to people or like learning from others. That's a really great sign. Like if somebody has, is really, really good at creating, even if it's just like a small side project and just putting it up on GitHub and talking about, Hey, this was my journey and exploring X, Y, or Z. That's a person who's going to be really, really good in DevRel. Right. And 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? Latest technology. Yeah.

I saw this meme the other day and I felt personally attacked and it was showing, it was a graph that showed the process, like how many blogs you've posted versus the number of posts versus like, I guess how complicated the setup was. And like the thing that had like the most posts was just like standard WordPress site from 2004. And then it goes all the way down to, you know, welcome to Nginx, which where I felt like very, very seen and personally crafted, you know, static site generator migrated from Jekyll to Hugo. And I was like,

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, and 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, you know, has been like, okay, what website of my own can I rebuild for the fourth time?

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 and 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

with different technologies and telling people about them. No, you're absolutely right. I mean, for me, it was the perfect sort of dream job. I think the way people get into it, A, is you start out by just kind of doing those things that the dev roles do and sharing it with people, whether that's on Twitch or YouTube or TikTok or Twitter. Twitter is a great place for a lot of that stuff. LinkedIn even, right? Showing it off and even a personal blog, just continuing to kind of put this stuff out there really, really helps because you

You don't always know who's watching. And sometimes you might not even have any audience, but it will grow over time, especially as you're engaged with communities. That's another thing I would say too, is get engaged with the communities that you're interested in. And it doesn't have to be related to a specific company. Although if the company is 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. And I think that it

what we've seen over time, you know, 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 and is about working with product and with engineering teams and

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, and these might be unexpected things. And 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. And,

that gives the dev role an opportunity to then when they're talking with community say, "Hey, this is why this works this way." Maybe there's some changes that can happen but

you can be transparent and say, this is why this works this way. And a lot of times you do kind of become an unofficial, you know, point person for the company you're working for. And so having strong ties to the communities that you're part of goes a long way for that because, you know, 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. And if we know each other from those same spaces, it makes it a lot easier than trying to kind of reach out to, you know, the void of giant company or even smaller company out there. So it's acting kind of like a bridge really between the community and then the internal business.

functions of whatever the organization is. You nailed it. And that's even how I've described the function internally to people before, especially at Microsoft when we would have to kind of explain like what our function was. Or I would even say, you know, we're kind of 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 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, you know, convince somebody to look more into your product or help someone solve a problem. And that could be a big impact, but it might not be measured in that way. And so that's, I think one of the big challenges that a lot of, and it's, you know, 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 up.

And so, you know, you have to kind of 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 like a link that your dev role 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, you know, or projects have been created using something they're,

There are different strategies that you can do, but it is, that is kind of 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, okay, I've added this new feature to a product and I can tell from telemetry that it's been used really well, or I can tell from support requests that things have, you know, maybe increased a lot. So maybe there's a problem here. You don't have that same ability. So it's a challenge, but I think,

to go back to kind of 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. And so that's a really good way, I think, of kind of judging how well something is working and what's working and what's not is to look at, you know, the feedback and the sentiment you're getting from your users.

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? 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 and 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 like

I work with people on basically every different team at GitHub. And that's one of the things that's great about GitHub is that they have a really good understanding and I think 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? But we can also talk to people and 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 and they're telling me about this thing they're doing. I'm like,

That's so cool. And 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, right? And say, hey, look at this very cool feature. Look at this really cool thing that was built.

And so it can be difficult sometimes, I think, 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 sort of 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. Right.

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. And 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. You know, I haven't had this problem at GitHub, but I've certainly know people and I've had other experiences where, you know,

there can be a mismatch of expectations. And I've 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. Like that's not my job. 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?

Yeah, so this was what I was kind of doing my last year at Microsoft. I was really strongly focused on like the Linux tooling at Azure. And 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, is that there are a lot of various levels of stakeholders. And so one of the things that I worked with with a lot of those teams was kind of pointing out

you know, especially when some of the product teams, when they were speccing how certain things would work, it's like, okay, has this been tested on Linux more than just in an ancillary, like we've had it pass a unit test. Like, 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, you know, like the CLI tools would work as well, whether somebody was using, you know, Linux in a VM or Linux on the desktop or Linux on,

as part of Windows and making sure that we could make that experience as consistent and as good as possible. So 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. And 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.

So that would be really useful to be able to say, okay, this is the feedback I'm hearing. And this is also even like 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?

That makes sense. So I suppose you're kind of sitting in the different communities and 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 in what you've learned from fellow dev rels at smaller companies and startups and how the teams grow and how that changes over time?

Yeah, I mean, it's interesting. So when I joined Microsoft, I was one of the first, you know, dozen or so people on, I guess, what they had then reinstituted. They'd kind of doing the DevRel within Azure and the team wound up growing to a few hundred people. But I was there early on, which was interesting because Microsoft's

Microsoft's 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. And I think the real thing is that...

And this is true, I think, if you're starting the DevRel program at a big company or at a smaller one is you start from the beginning and you start kind of 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, you know, create examples of what people can do to try to encourage other people to do things with our work?

And then finding people who can build and grow from there, depending on what your capabilities are. The biggest challenge I think 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. And it can be kind of 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 most feedback on. It's not the thing that marketing, you know, 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 buying, you know, and being okay with that just because, you know,

There are only 24 hours in the day and there's only so much that you can do. I think that's the challenge. I think at bigger companies, the challenge, it's also, you know, getting people spread thin, but I think it can also be an area of kind of figuring out, okay, it's almost the inverse in some ways where it's like, okay, how can we be focused and what roles should people be in? And should we have specific people that are, are really taking ownership of a certain area? Yeah.

And that's hard for me, I will say. Again, I'm a generalist and I love being a generalist, but I'm kind of 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 kind of dabble with a lot of things. And I love that. And I love that I have that ability, but I have struggled before.

before, where I've kind of said, okay, well, I have to be, you know, 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.

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. And 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 your 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.

Yeah, I think it's a great question. And it's really interesting because I've watched so many of my friends go back and forth between product and dev role. And I think that they're complementary in a lot of ways. And again, I think that really it comes down to kind of expectations. Like I want to be very conscientious, like as a dev role 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. And 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, you know, help when people are trying to figure things out. You know, 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, is that PMs, you know, people in product, although they definitely talk to people, their users and their communities and are doing those feedback studies, a lot of times, like they're doing a lot of other things too. They're managing a lot of other,

other priorities. They're trying to figure out the engineering workloads. They're trying to finish their sprints. And 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. And then, you know, you try to work together about, okay, how can we integrate this or what is the solution for this? And I also think that me as DevRel, although I might see those edge cases, I

I don't always see the complete picture that product is doing. I don't always see the reason why this decision was made. And so, again, I think 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. And we hope to get to this at another time, but the priority is this.

or, you know, 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, you know, 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. And so I think that the line can be really blurry. And again, you see people go back and forth between the two roles a lot. And in some companies, they might be really similar. And I think when you start out, I think they start out really similar. But I think that people understand what their roles are. And for me personally,

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.

On the communication side, what would you say is your favorite medium? You do a lot of video and 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?

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 the two kind of 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, I think, 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. And 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 kind of the production nature of YouTube because I have more experience with that. But

But I love that. And I'll say, I love Twitter. I think Twitter is, you know, the problems that the Twitter is having notwithstanding, like it's a great place to reach a lot of people, but not only that, like it's a great place for me to hear feedback and just to find cool things. Like I see really great stuff that people are building on Twitter and that's always fantastic. I would also say like the,

to plug GitHub, but GitHub is a really great place because people put their projects up and there's great things happening in discussions and you can find really cool stuff. Like my GitHub stars, I always tell people like, don't follow me on GitHub to find my code. Cause that's, you don't care about that. Follow me for my stars because I find the most amazing and interesting projects. You know, I have like 2000 something stars and I was doing that long before I ever joined GitHub. That was even one of my, like my pitch, I think in my interview, I was like, look,

I'm a super fan because I find this stuff and I'm interested in it. And that's a great way, I think, to communicate and learn. Because I know for me, I learn a ton just by looking at somebody's small project, you know, that might not even be well documented all the stuff more

More documentation is always better. But I can look at it and go, oh, okay, this is how this works. And it 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 I really like and then looking and seeing their links. If they have a GitHub link and then seeing if their website is...

in their GitHub account and then like star that be like, okay, cool. Now I could look through and see how you did that thing that I liked. I love that. And you're always on Twitter as well. Jean, you're always tweeting loads of stuff. Yeah. I love Twitter. I mean, I just, I've always been on the internet. That's how I learned things. I really identify with what Christina said. That's how I met Christina Twitter. Yeah.

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's a recruiter everyone told me about. They said, I love this recruiter. I talk to them all the time. And then now...

And none of them actually seem to take jobs from this recruiter. And we talked to the company 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 feedback?

promoted? You know, all of the questions that are terrifying and people don't like talking about. It's a great question and it's a hard one. And

So I think that, again, this kind of goes back to the earlier question you had about like 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. So like for me, one of the things when I came in, frankly, was to grow the YouTube audience and to grow views and watch time.

And I had been successful at that at Microsoft. And 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. Like 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 was very, very useful there. And so I think it sort of depends on what you're wanting to do. Like, 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.

And that would be how you would be measured. But you're right. There is, and this is I think what's really important. I'm glad you brought this up. It is a job, right? Like I love my job and I love what I do. And a lot of the stuff that I do, I was doing years before I ever worked in developer relations. Like 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.

And that helps, but it is a job. And 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. You know, I think that similar to your recruiter friend, like you can't lose sight of that, right? You've got to realize that like, it would be great if we could all just do only what we wanted to do and just, you know, talk all day and get paid for it. That's not how that works. Right. So I'm

I'm thinking about, okay, what can I do that can kind of further the goals of GitHub? You know, get more people hopefully using our products, giving our feedback, getting interested in development. That's a big part of it too, you know? And so I think being clear when you get hired, what the goals are, and then also just like recognizing, yeah, this is a job. And 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.

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? Yeah. And the catch is, yeah, 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. And 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. Like,

And again, it wouldn't be helpful to anybody for me to do it any other way. But yeah, like I work for GitHub, so I'm going to post a lot about GitHub. That's the job. That's part of the appeal. Like I'm not going to ignore that part of it. And sometimes I think people do ignore that part of it. And 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.

And I think, I don't know about either of you, but I'm much more willing to accept if someone's kind of 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. Like I'm okay with that versus... Me too. I expect it. I expect it. But I'm also, I'm okay with that versus somebody who works at a place and then it's like nothing they ever write about or do like that seems work-related is associated with their job. Like that always feels weird to me. I don't...

I don't know. Same. And to me, it's similar to 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. Yes. I think you're exactly right. So before we wrap up, I have two lightning questions for you. All right. So the first one is maybe you have to look through some of your recent stars, but what interesting dev tools have you been playing around with recently? Yeah.

Okay, so there's so much cool stuff happening with ChatGPT. Like that is going to be, say, the first thing. So like the ChatGPT and Whisper APIs were released this week as we're recording this. And there's...

so much cool stuff happening with that. So that's the first thing I would say. This is a dev tool in a sense, but Hassan, who's a dev rel at Vercel, and he's amazing. He and some other people contributed to a project called Commit AI, which basically creates commit messages for you using OpenAI. And it's brilliant. And I love it. And 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? Yeah.

So baby steps. So that's the 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. Okay, great. And then tell us what your current tech setup is, the hardware, software that you're using just on a daily basis. Yeah, so I'm primarily a Mac user. I have...

two 2021 MacBook Pros. I have a 14-inch that I got myself, and then I have a 16-inch that GitHub provided for me. And so those are both M1 Max units. And 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. And so it's really powerful, and it's still really, really good. So that's kind of like 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, like so jealous. Yeah. Excellent. Well, unfortunately, that's all we've got time for. Thanks for joining us, Christina. Thank you so much for having me. This was awesome.

Thanks for listening to the Console DevTools podcast. Please let us know what you think on Twitter. I'm at David Mitton, and you can follow at console.dev. Don't forget to subscribe and rate us in your podcast player. And if you're playing around with or building any interesting DevTools, please get in touch. Our email's in the show notes. See you next time.