Developer Relations and Beyond with Jamie Barton! 🚀
===================================================

by kirupa | Interviews with Creative People: https://www.kirupa.com/podcast/index.htm

Jamie Barton (https://twitter.com/notrab) shows developer relations in its best light: not as posting for attention, but as the steady work of teaching, documenting, listening, and helping developers succeed. His path from Flash communities to GraphQL education and DevRel leadership makes the role feel concrete, technical, and much broader than the usual stereotypes.

Watch the interview: https://www.youtube.com/watch?v=6GehrPUhGRI
A conversation with Jamie Barton | 58m

ABOUT THIS CONVERSATION

Jamie Barton has one of those backgrounds that makes developer relations immediately easier to understand. He spent years as a working developer, learned in public through web communities, and kept a strong teaching streak running alongside the technical work. In this interview, that mix comes through clearly. DevRel is not presented as a vague layer on top of engineering. It is a job built on translation, empathy, and enough technical depth to know where people actually get stuck.

The strongest sections are about content and documentation. Jamie talks about building websites, forums, and tutorials early on, then later seeing firsthand how much better a product feels when the docs are rewritten with real examples, clear structure, and a human touch. That experience makes his point land: adoption is rarely about promotion alone. Developers need material that helps them move, debug, and trust what they are trying. When the docs are flat or over-automated, people feel that immediately.

He also clears up a lot of confusion around the role itself. Social presence can help, but it is not the job. The job is cross-functional, fast-moving, and often invisible from the outside because it includes feedback loops, product insight, event work, support, content strategy, and internal advocacy all at once. Jamie's advice for newcomers is practical too: spend time building things, learn how developers think, keep your content focused, and do not mistake buzz or tooling fashion for usefulness. That balance of technical credibility and clear communication is what makes the conversation so good.

WHAT YOU'LL HEAR ABOUT

- Developer relations works best when it starts from real developer empathy, not surface-level promotion.
- Clear examples and well-shaped documentation can change product adoption more than people expect.
- A DevRel role often includes product feedback, education, support, and community work at the same time.
- A strong social presence can help a career, but it is not a substitute for useful work.
- Hands-on engineering experience makes it easier to spot the problems that frustrate real users.
- Short, direct teaching often lands better than content padded with buzzwords or filler.

JUMP TO A TOPIC

- 0:00 - Meet Jamie Barton: Jamie introduces his GraphQL and DevRel work and explains the broad shape of his career so far. (https://www.youtube.com/watch?v=6GehrPUhGRI&t=0s)
- 6:00 - Flash communities and early inspiration: He looks back at the forums, tools, and maker culture that first pushed him toward teaching in public. (https://www.youtube.com/watch?v=6GehrPUhGRI&t=360s)
- 12:00 - Why he started creating content: Jamie traces the jump from building his own sites to writing tutorials and helping other people learn. (https://www.youtube.com/watch?v=6GehrPUhGRI&t=720s)
- 24:00 - Documentation that actually helps: The conversation turns to rewriting docs, adding examples, and seeing how developer experience affects adoption. (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1440s)
- 30:00 - What DevRel really includes: Jamie breaks down the many responsibilities hidden behind the developer relations label. (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1800s)
- 36:00 - Does social media matter?: He gives a measured take on audience-building, reputation, and the work people do not see behind the scenes. (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2160s)
- 42:00 - How to get into DevRel: Jamie shares practical advice for people who want to move into the field without skipping the technical foundation. (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2520s)
- 48:00 - Teaching style, niches, and AI: The discussion shifts to concise educational content, finding a niche, and new opportunities opened by AI tools. (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2880s)
- 54:00 - Practical choices over trend-chasing: The episode closes on tool selection, product fit, and why usefulness should beat fashion in technical work. (https://www.youtube.com/watch?v=6GehrPUhGRI&t=3240s)

TO LEARN MORE

- Jamie's Twitter: https://twitter.com/notrab
- Jamie's graphql.wtf: https://graphql.wtf

TRANSCRIPT

The automatically generated captions have been organized by speaker, lightly edited for clarity, and broken into paragraphs for readability. Names and wording may still contain errors.

0:00 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=0s)

This time. Okay, just an overlay. Cool, Jamie, great to chat with you. So before we go too deep, can you please introduce yourself?

0:09 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=9s)

Yeah, hey, thanks for having me. It's great to be here. I'm Jamie. I'm in DevRel at Graphbase, and I create educational content on GraphQL. I've been around the tech scene for a while, been a developer for a long time, and then made the move into developer relations maybe seven or eight years ago, so I've been around a while.

0:28 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=28s)

Cool. Yeah, I feel like I've known you for a very long time as well through your online content, and I'll put the link in the description below. I think last year we had a recording where we talked about GraphQL and what it is and what makes it really exciting, so we may touch on that a little bit later. But before we get too far into the GraphQL and technical side of it, I kind of want to learn more about how you got started in tech.

0:55 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=55s)

I think I was around 11, maybe 10 or 11 years old, when I got my first PC. My grandfather bought it for me, and from that day I was fascinated with the web. I didn't even have internet access at home then. My 56K modem was in the machine, but I had no connection. I persuaded my mom to buy a CD with an ISP installation program. We installed the drivers, and I got hooked on installing, configuring, and playing around with things. When I finally got the internet, I was completely hooked.

I created my first website on my machine, I think with FrontPage, and used something called Netscape Web Builder, or something like that. I think it was part of the Netscape Navigator software. I could talk about it forever, but that was the point when I fell in love with the whole thing.

2:04 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=124s)

We should actually talk about that forever. I think it might be referring to Netscape Composer.

2:09 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=129s)

Probably is, yes. My memory doesn't go back so well, but I remember they had this tool where you could log in. I think you could log in. I can't remember exactly, maybe it was attached to your ISP login, because back then logging in and authentication were all very new. But I was creating websites for the school at the time, and my friends were like, oh, that's cool, can I have one? So I ended up building websites for friends. I don't do as much now, but I was very into magic tricks and card magic, so I put together a website called Jamie's Magic, I think it was JamiesMagic3. Cjb.

Net, one of my first sites. The CJB thing was just something where you could get a subdomain that pointed to an FTP location, and I would use FTP from my ISP to host my website. I was doing this for friends in school and just loved playing with this stuff and figuring it out. And this was back when you had to create borders and border radiuses with images.

3:19 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=199s)

That's right, the spacer GIFs and the little PNGs with the corner radius. What would normally be a typical border would actually be a table with a three-by-three grid, or nine cells basically, that would make the corners. It makes me laugh, but that's what we had to do. That's how I got started in many ways as well. It was the free editors that came with the browser. For me it was Composer, and then FrontPage Express because FrontPage was getting really popular and people were really big on it. Then my parents got me a copy of FrontPage 98 because what we couldn't do with FrontPage Express or Composer back then was iframes.

I had no idea that all you had to do was go into HTML, type in the iframe, and the editor would show you what needed to be done. I was like, where's the insert iframe button? And the funny thing is, because I've been maintaining my blog since that time, 1998 onward, I still use FTP even today, and I used the FrontPage include page component to do the server-side-includes equivalent. My Media Temple web host at the time was like, you're the only person right now who's using this. They deprecated the server extensions on Unix machines quite a while ago. Can you please do something differently?

Then I did a massive bulk replace with Apache server-side includes, which is what I still use today. I use Dreamweaver because FrontPage was discontinued, Expression Web, which was its replacement, was discontinued, and so Dreamweaver is the only one that has survived until now. For me it's the closest to a WYSIWYG experience. So when you describe all of this, I'm like, that might have been what was done decades ago, but unfortunately it's what I deal with even today because of the legacy and all of that.

5:19 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=319s)

That's really cool and, to be honest, I didn't even realize Dreamweaver was still going. So that's really cool.

5:25 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=325s)

Yeah, I mean, the day when they say Dreamweaver is also discontinued and I really have to figure out a more modern solution, it's going to be WordPress or some CMS or something. But it'll definitely be a massive copy-paste bulk replace across so many thousands of pages from 20 or 30 years, which unfortunately aren't all consistent, so I can't just do a one-off find and replace because there are some weird patterns in there, abandoned things brought back again, and so on. I'm just hoping that day doesn't happen anytime soon.

5:58 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=358s)

So when I started out, I got into Flash and picked up Flash, and obviously your website was a huge resource back in the day for Flash stuff. I loved visiting just to learn. And then I picked up, I guess, from what you and a few others in the community were doing around sharing educational content. That's probably a big reason why I do what I do now with creating my own content. But I got drawn into the Swish and SwishMax community, and that was huge. I still remember there were forums for Swish tutorials, Swish Talk I think it was renamed as, and there was the official SwishMax one.

I had somebody online that I used to follow called Rob Wells, and he was just awesome at creating Flash stuff. We would spend hours playing around with keyframe animations in Swish, and I was forever dipping in and out of Flash to pick up a little more of the ActionScript side of things. Then I was trying to relay that back to Swish because I was more familiar with that. But yeah, as much as the web has moved on, those days were really fun. I don't care what anyone says, that was an awesome time to be alive.

7:20 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=440s)

Oh, I agree with you. In many ways, I never felt the web had moved on since then. It went backwards in so many ways, and people have forgotten how nice it was back then to have a visual tool that could do the visual things visually and let you add code for the interactivity you needed. You could go from an idea to a design to something that works in your browser very quickly, whereas today it's more like, which framework do I choose, and what's the build-tool setup I need just to get Hello World up and running?

We always used to say that the thing that made the web better than traditional languages like C++, Java, and so on is that you get Hello World up and running in the fastest time. You open your editor and you're ready to go. I think we lost a lot of that, and unfortunately you and I, and probably a few hundred other people, are still around who can remember how nice that was.

Today the norm is more like, yeah, I spend a few hours with my build-tool setup and I figure out what web host I want, and then people look at the other IDEs and think, yeah, no, I'm just going to write code for everything. I want to do online visual things by writing code. That sounds so backward to me. But hopefully the rise of Webflow and Framer and some of these low-code tools we're using right now are getting a little bit of that magic back, where people who are not technical don't have to be.

And of course we've seen so many things recently about AI tools where people with limited coding experience or no coding experience can create Snake or create very elaborate applications that even seasoned developers would have difficulty figuring out how they did. It would take me a while.

8:58 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=538s)

It would take me a while to get started creating something from scratch again. These days it's very easy for developers to reach for a component library or CSS library, and I know there are all these micro-arguments around which you should use and why. But I agree with you, way back then there was just a simple way to do things, and FTP, for good or bad, was just a way to take your files, drop them somewhere, and it worked. I understand and appreciate all the benefits now of all the CI/CD processes. Things are a little more complicated, so we do need to check that if I just override this index.

Php file, it's not going to break. That is super important in today's world. But it was so much easier back then, like you say, to just get Hello World. Over the last few years I've spent a huge amount of time in the content management system space, and I've always enjoyed writing code from scratch. I'll look at an example online and maybe it gives me the tutorial, and I've always just written it out again. I haven't copied and pasted, and it kind of makes me a little bit slower, you could say, but it's a good way to learn and memorize some of the semantics of stuff.

I've been telling people that everything's composable and you need to bring things in and use this service for that and another service for this, and that's awesome at really large scale. But for a lot of people who are just getting started, that is very, very overwhelming. So I agree, things like OpenAI and a lot of AI tools are going to make onboarding or intro to development easier, I hope, because it's mind-blowing that you can create games and you can just create stuff with AI now. It's another tool for developers.

Instead of being afraid of it, if you embrace it and use it in the correct way, I think people can do some remarkable things with it. So I'm really excited about the future of AI in general. It's only now beginning to pick up momentum. People are understanding what it can do, and with some of the recent updates it can do a lot more. You can feed it your own stuff so everything can be contextualized, which is going to be even more powerful. So this is only going to get better.

11:39 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=699s)

Yes, and by the time we finish a recording and get it live, probably a whole new set of things will have come out that completely move the needle even further in terms of what is possible. So you went from being in the Flash community for quite some time to creating content. Tell me more about that. What motivated you to do it? What was the first kind of content you remember writing, how did you market it, and what were all the steps that took you from having an idea you wanted to share with others to actually getting it out the door?

12:13 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=733s)

Yeah, a lot of things. So, I remember creating my own website and then I wanted to teach someone else how to do that, so I had my own. I created my own Forum back then and back then it was using Invision Power Board and I was always an Invision fan. I was never the VB guy. The vBulletin- for anyone watching this. No, phpBB either. I enjoyed that. That was like a little dirty secret I had. It was like I enjoyed playing with that, but I didn't go into production with it.

It, I loved it and I started out with PHP and did PHP for a very long time, but I preferred just the look of Envision. And I still speak to on Twitter today, Matt Mecham, the creator of that, on, on, on on Twitter and he writes a lot of stuff around communities now and it's amazing to see that Invision Power Board is still going and they've Diversified into so many different things. But I started out installing that and creating a lot of kind of creating mods for it or at least themes to begin with.

And then I was just kind of posting: oh, I made this theme and this is how I made my theme and I just kind of created a forum where I would invite others and the people that I'd met online. I, we all kind of had forums that we hung out on and we were just kind of sharing links to that and it kind of, from there, I was just posting it in kind of the tutorial section on my Forum, like: this is how to create a button in Flash. This is how to change the background on Hover.

You know, simple things like we take for granted today, but you know, back then this was all very new and everyone was experimenting on ways to do things. So that's, that's how I got started. And then from there, people were then asking- not just me, but you know in General on the internet, how do I create my own Forum? So then I ended up having, my very first web hosting company, which was spot Web Solutions, and that was something I created.

I think I was around 14, 15 years old, and I was hosting websites for people, and I was lucky enough at the time- maybe it's a few years later actually- that my school gave grants for people from their own businesses. So we had to pitch to the to the school. This is the idea, this is what we wanted to do, and there was a few of us kind of interested in this so we ended up getting funding.

It wasn't a huge amount, it was like 200- and we would use that money to then buy a server, a dedicated server, and then we would sell that hosting, would split it up, and I think it was like five pound per month or ten dollars, you know, whatever it was back then- for 50 meg of space, 50 megabytes of space, which is that's right, which is which is cool to remember, but yeah, it kind of start from that. And then I enjoyed the like forums so much, like I spent most of my like it.

You know, I spent most of my teens, I think, working and building stuff for forums and running my own communities, being moderators in other communities and just kind of creating and sharing as much content as I could. To the point where I met someone called ali who ran a switch forum and he had actually created the kind of one of the initial versions of his own Forum software, and I thought this was a great opportunity to learn PHP a lot more than what I've been, what I've been doing at the time.

So we built, rebuilt the it's called light boards back then, and we rebuilt it from scratch and it used text files as the database. So everything was chmod 777 and you could do whatever you wanted and the PHP server, you know, read from those text files and then, you know, wrote them as well, for any changes, which was which was really cool. You know, nobody was really doing it and it was a bit risky, but it was actually, it was actually okay, it was super fast, it was really fast. I can't remember. I really can't remember.

I think we just I think we had folders for like different content types and their IDs, but we also appended to a giant document all of the data. So I think that's what we did. I can't remember, but we did have a search feature, but I can't remember the specifics now.

16:54 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1014s)

No, that's really impressive, because one of the pains of dealing with most of the forums back then was that it was usually in MySQL, and then you had to figure out how to back it up regularly. If it got corrupted, which happened all the time, and people signed up for large attachments, somebody would glitch something somewhere and you'd be like, great, I have no idea what I'm going to do now. Let me restore my backup and lose some data. The text-file solution is very elegant.

17:16 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1036s)

Yeah, we thought so too. It was so fast, and that was because the PHP file just lived next to the text file. Back then people weren't really too concerned about latency. People had 56K modems, so it's not like everything was blazing fast. No one really knew if something took one second or two seconds. Those were fun times.

17:47 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1067s)

Yeah, so what was the first article you wrote?

17:53 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1073s)

I think so. The, I think way back when I first, when I first started, it was definitely around The Flash, like creating Flash buttons and, you know, create. I think it was creating a form that would. Then I- I can't remember it exactly, but it was, it was- I remember figuring this out and it was the six weeks holidays here in the UK and we had six weeks off school and I remember building, rebuilding my website, and we had a form and that form- I can't remember where it went, where the data went. When you submitted it may have went into a text file.

I really can't remember, but I remember figuring that out and then wanting to share that with others. It was a form that was inside a Flash that you would fill out all these text boxes and you know all the state kind of lived in Flash and then when you submitted that, it would then, you know, do an animation and it would then show you the results in there and then it would post the results somewhere and I think I posted it to a PHP endpoint back then.

I can't remember, I think it was a PHP endpoint, but I remember just writing about this and it'll be on the Wayback Machine somewhere on my Forum, but that's kind of where I spent a bunch of my time, was just kind of sharing stuff on there,. And then I think I think fast forward a few years into kind of my recent time in DevRel.

I was working as a software engineer and had recently discovered GraphQL and React, and I think one of the first I think I use next year, like nextgs, is a JavaScript framework for React, a React framework rather in JavaScript, and I remember using that and creating a video on YouTube and it was super awkward because I think I mispronounced zeitel, I think I said zeit at the time, it was a word that I wasn't familiar with and I just created a video talking about it and I think that video ended up getting, you know, 36 000 views. It was the very early days of next.

I don't think it even hit 1.0 at this point, and I was just playing around with it and decided to create a video and that's kind of from that I got a lot of good and like a lot of good and constructive feedback that I wanted to just improve, and it was kind of from there I started to create more content. So, yeah, it's been. It's been a wild ride.

20:29 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1229s)

So what made you shift full-time into going into content creation, developer relations and the various jumps from there?

20:38 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1238s)

Yeah, I've been working as a software engineer. I kind of been freelancing pretty much I think, since 15, 16 years old. I was creating projects on the side and I was doing freelance work to kind of just get extra money. And I remember where I joined Apple as a Genius and I was working on the Genius Bar and I was repairing Macs as kind of my full-time job.

And I'm spending every moment I could outside of work and on breaks and lunches and holidays, learning more about Ruby on Rails and I kind of moved and progressed into Ruby on Rails ecosystem and I got my first, big client job using Ruby on Rails and then from that I went and worked full time for about five years as a Ruby on Rails developer and then from there I moved more into the front end stuff and at that time- like I say, this was even before- like next, yes, was a thing.

The web was just kind of- you know, I think dig 2.0 had just been released- in times of kind of changing on the web and APIs were kind of just beginning to become a trend. People were using these APIs to power their front ends and now people are kind of decoupling their services. And then it was at that point where I thought, okay, there's a huge disconnect now, because you know everything we spoke about when we first started chatting today.

We talked about how easy it was, and then now it's become more difficult because people have to think, okay, how do I connect this with that then what should I use for this and that? And it just got, I think, confusing. So I got an opportunity to join a, an e-commerce API, and I turned them down, like maybe two years before I did actually end up joining.

And when I did join, I was kind of going in as this full stack developer slash, customer success slash, developer success slash, whatever else, right, like I was just wanted to work with them and, you know, I was kind of interested in the React and front-end stuff.

So you know, long story short, I joined them and their documentation and content wasn't at the level of like stripe and I was hugely fond of the stripe experience from a developer point of view and I knew it then, if we were going to succeed in a startup, that we needed to create content that resonated with developers, and what we had at the time just wasn't like people were signing up and falling out of the funnel and weren't getting any further because it was just difficult.

Nothing made sense, everything was just- you know, there's too much jargon, and yeah, I kind of just from that point said: you know what, I'm gonna spend a lot of time in documentation and content here to try and make this a lot better. And then we actually seen some really good results of that.

Like we improved and actually I think I actually rebuilt the documentation on the first few weeks of joining the company and wrote everything from scratch and provided illustrations and then created code examples and people will again beginning to appreciate the new documentation and how easy it was to pick up this framework or this API at the time. It then so happened we deprecated the library that had just been redocumenting and released a version two and a lot of this documentation was then automated and a lot of that automated documentation from the code- it kind of went back to how it was before, so kind of lost that Personal Touch.

So I ended up having to redo that again and we've seen some really good results and it was kind of from that moment, I knew there was something in the like the developer success, documentation, content creation that I really enjoyed and I think you know you'll know this yourself- back when you know creating content all those years ago, in 1998 and before to now. It stays with you. It's something that you enjoy doing and helping others and sharing that with others, and that that's just something that clicked again.

I'd been a software engineer for a few years and I somewhat enjoyed writing and showing others how to do things more than I did writing code, like full time. So that's kind of sorry that's. I just kind of waffled on for too long about that, but that is kind of my story then why I ended up in where I'm at.

25:27 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1527s)

Yeah, no, waffling is actually a great answer because one of the things I love about developer relations is that I'm a product manager in my full-time job, and the number of people I speak to the most in my one-on-ones and on my calendar are people in developer relations. When it comes time to build a developer-facing product, which is what I work on in the Firebase area, the people who know the most about what developers want, need, and might want over the next couple of years are often people in developer relations. I've always found them to be the best resource to use outside of actually talking to customers yourself.

But even if you talk to customers yourself, are you the right person, are you asking the right questions, and are you subject-matter-expert enough to really parse the answers they're giving? Developer relations often has that completely figured out, and I've been very interested to learn more about how you got into it because I've been following your content for quite some time and I greatly enjoy it.

26:27 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1587s)

Yeah, and developer relations is. It's a huge topic and the things that DevRels. Do you know that list is so long and so varied and it's you know there's so many pieces to it. That keeps everyone fresh and there's always something new to do and it's not the same thing every day, but I think you know developer people who succeed in developer relations really understand their product, understand how to deliver that product to new users and how to kind of- you know, help people along a journey and they enjoy helping people along the journey.

You know, it was 11 pm last night and I'm not advocating that people work crazy hours, it's just for me, that's how my schedule works these days. But it was like 11 pm and someone was in Discord asking a question and I thought, well, I know the answer, I'm just going to help this person, and it's that kind of thing that I see from a lot of people in the developer relations community that are, you know, doing amazing things.

It's because they spend the time to help people, and I, and I think as much as that is not scalable in some new startups, that is a great way to kind of build relationships with people, and people have taken that time with me in the past when I've been learning new APIs and Frameworks and that stayed with me forever that that it doesn't matter what that person does if they move from one company to another.

I respect, respect that person enough to appreciate what they have to say when they say something and I really enjoy it and I really respect anyone who works in DevRel because it's a it's a tough job. That's kind of the advocacy side where I, you know, there's a few people I speak to occasionally that are traveling all of the time and they're speaking at conferences or they're at booths- and I've done this before. Standing at booths all day on end is a very tiring thing and having the same conversation on repeat is very tiring.

But that you can get so much out of that that you can't get just kind of sat at a desk watching or read and reports and videos. Like that one-to-one interaction is amazing, you know. And then the kind of relation side of it- you touched on it before- actually speaking to people and understanding their challenges, feeding that back to product in a way that you can really make a difference for not just you and that specific user but you know users that are, you get to discover you. I think that is a huge part of the of the role as well. And then there's a lot more.

29:07 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1747s)

Yeah, oftentimes you hear that developer relations, the team members there, are like customer zero for any product that's being built, because they are both early adopters of whatever technology your team or companies building and they can provide feedback that channels and tell you what you mentioned, what the broader Community would want as the right set of developer ergonomics- for lack of a better word- based on competitive, what competitors are doing, based on what the trends are in the market.

You know, do you use Tailwind in terms of libraries and like what you know, some like you know quirks and like what YouTube and so on, things like that, and I think that voice of like reason between balancing technical needs and the customer needs and even the business needs, oftentimes it's a very unique skill that you have.

29:51 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1791s)

Yeah, every day is different, and it's fun because of that.

29:58 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1798s)

Yeah, what is a common misconception about developer relations that the industry has?

30:04 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1804s)

I think a lot of the time. So I remember when I first became or moved into DevRel space- and I think the role is developer success- no one really understood what developer success or Dev relations did and I think you know six, seven years ago I didn't, but I think today there's still maybe some misconception. I think it's a lot better today because people appreciate the results and the work that DevRels do,. But I remember way back when, you know, no one really knew what they did.

They thought they just kind of tweeted all day and you know, and created stuff on on Twitter and posted blogs, and I think you know that's certainly a huge part of the role and I think you know there's many different under the kind of developer relations umbrella. There is a lot of different avenues that you can work in. Right like, the advocacy side is more about kind of sharing and speaking and, you know, presenting your product and you know, and not just at conferences but through video content and, you know, workshops and whatever that stuff. I think a lot of businesses don't understand the actual value that that brings.

They just say it as: oh, they're an influencer or whatever. I think if somebody is in DevRel and they are technical, they can make that content very, very helpful. For you know them, converting users and signing up for your product. At the end of the day, like that's what it comes down to. We want people to pay for our stuff, and the easier that people find your product, the more likely they are to pay for it. Right, like it's as simple as that. And I think the biggest misconception is people just sit and tweet all day or all scroll Twitter and you know have you know.

You know you know raging about which framework you should use, like you mentioned with Tailwind. That's something that's every, every week right now, but I think that's a misconception, but also, on the flip side, I think what isn't is the actual results of everything that DevRels do. Yes, you can go and meet people and talk to people, but I guarantee that- and I don't mean this in a negative way, but there's a lot of Engineers who will put their hand up and, I have friends who have been like this- they'll put their hand up and say: I'm an engineer.

I don't really like speaking to people, and I think that's something that is great for DevRel, like being able to speak to somebody and have a technical understanding and experience is just, it's just really a you know someone. If you've got someone on your team that can do that, you know it's. It's massively underappreciated,.

33:01 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=1981s)

Right, because what organizations and companies are ultimately doing is building something that's targeted at developers and helping them be successful. Everything else that we do organizationally, all the layers of management and bureaucracy, is really around that endpoint of: can someone who is window shopping for a solution to their technical problem find us?

And when they do find us, can they say this is going to meet my needs and then have the right resources to either hire someone to solve the problem for them or, if they're what we typically call an independent or bottom-up kind of developer, be the one who pulls up a chair with the documentation and figures it out themselves? I've worked with developer relations mostly across large companies, but their approach to these products has been very different. One company I worked for was very B2B focused.

The decision on what solution you used was made by a CTO or a sales team years ago as part of a massive contract, and then developer relations was really about, you've already made the decision to use the product, now let's talk about how you can make it work. That's a very different dynamic, tone, and style of approach compared to the type of solution where it's easy to switch from what you're building right now to another product from someone else. Everyone recognizes that, so the approachability and tone are very different.

Watching these things firsthand has been a huge learning experience in the range of operations and the style you have to follow depending on the type of business you're in.

34:43 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2083s)

Yeah, yeah, there's a lot of developer people who work in developer relations that have hundreds of thousands of followers on Twitter and are creating amazing content. And then there are other developers who are a bit quieter on Twitter. They don't have, you know, they don't- they don't have as many spicy takes, but they're actually they're working on a lot of the work you see behind the scenes. So that could be documentation and workshops and, you know, presenting demos to customers and sales demos and things like that.

That's kind of another piece that a lot of DevRels have kind of been asked to get involved with, because, certainly over the last few months, we've seen huge layoffs. I think there's even more pressure on, I think, everyone now to get involved with wherever you can, and I've always been someone to just kind of, you know, muck in and get involved and do what I can to help, and I know a lot of others that work in DevRel do that as well.

You know, so it's not just about having all of these followers and, you know, being popular on Twitter and having all these spicy takes, but there's a lot of other work that people do not see and, you know, a lot of time and hard work, preparation and making sure that what you're doing is a good bet or not. You know, there's so much. There's so much that we get involved with.

36:05 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2165s)

Absolutely. So speaking of Twitter, speaking of social media, how important is it to have a strong social presence to be effective as a developer relations individual?

36:16 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2176s)

I don't think it is that important. I think there are two things here. The first is, selfishly for you as a person in DevRel, having a good Twitter following and having something that is your own that you can share with others helps you massively in the space. You become recognized, and that can lead to opportunities, whether it's new jobs, projects, partners, or starting a new business. On the other side, the second point is that if you understand something, that is often all it takes.

There are a lot of people I know who don't have thousands of followers, and I don't have a huge following compared to some of the other people who work in DevRel. But having a good, solid technical understanding and being able to speak to developers and help unblock them building with stuff, that is really powerful. So that's important as well.

37:25 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2245s)

No, that makes a makes a lot of sense, and the reason I always ask is that it's a common question. I ask anybody who's in Tech these days is like: what is the value of a Twitter follower? What's the value of a, of someone who's telling you like you know, on your Facebook page, and so on? Because I've taken the very opposite approach over the years. You know, I'm very much. I'm not, I'm not an anti-twitter person, I just don't get it and the amount of time it takes to do it properly. It's a, it's a full-time effort.

You know, it's not a case people think that all these great developer relations and all these posts get accidentally, get popular. It's like: no, it's actually done very deliberately, where content was properly curated for the audience and the time and the format of it was optimized. It's a, it's a. Really, it's a skill and a skill that I do not have, and the approach I've taken over the years is really that Google search indexes my content.

I will just create content on problems that usually that I'm currently facing, as I'm, like you know, hacking away at something really cool and you know and not, and then I write about it and a year or two later enough. People are like, oh, I'm doing this now, I ran into this and it just happens to be found, and that, to me, has been one that is always an interesting one because we talk about developer relations and like how some people you know, you don't really hear about it much, but they're still very influential.

One of the more interesting the operations people that I have known over the years has no social media account yet is one of the more popular presenters at conferences, where they always end up like selling out often- I'm not selling out, at least the rooms are at capacity oftentimes, yeah, and it's always fast and it's always fascinating because it also speaks the audience for them. It's not really you don't discover this individual through Twitter or social media.

It's a traditional B2B kind of a system where if you're in the know of like these kind of products, then you know who this person is and I'm like that's another interesting way of thinking about how to position yourself. It's like it's very crowded here. What is a niche that you can find that you can kind of set yourself apart in? But I do agree with them building your brand.

I think it's the right word in many ways because, yeah, competitive space and, as we've seen, you know, we're, you know, tomorrow we'll both be replaced by another version of an AI Avatar that's doing exactly the same thing as us, using our previous content as trading material. And you know, and no one outside of basically you and I would know that it's not us doing this and so having a certain reputation that can't be easily replicated or is tied to any one company or brand or industry, because.

39:54 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2394s)

The world evolves. Yeah, yeah, no, you make some really good points there, really good points, it's it, yeah, it's just it's. It's just really fascinating, it's really fascinating. It just the whole, the way we've moved on and DevRel- and yeah, that's a really good point you make about. It- doesn't matter if you don't have a large social following, you can just be as impactful and powerful and not having that.

But, yeah, I think there's a lot of people who want to get into the industry and my advice to people getting into DevRel is: just be a developer for a while, and appreciate the problems that developers have, because that makes the job so much easier. So, you know, if you can, if you can become a developer, or can get a, you know a job as a front-end developer or back-end developer, Junior developer, whatever it be. Spend some time just kind of being faced with problems day to day and appreciate the levels and the quality differences of solutions and tools you're using.

That makes things a little bit easier when it, when you do actually come to DevRel- because, yes, you've got the advocacy Side and being someone that is influential and, you know, can help others and speak to people. Nice is great, but if you don't understand the problems that people have, it makes things a lot harder. Because you can't have a conversation with your product team- oh, we should be doing this and you know why. Like you can't answer the why. And I think it helps just kind of having some context.

Even if you've never faced the problems that your customers come to you with, you can empathize with them and appreciate how something that may might seem very, very small is a huge problem to them. And just being that kind of articulate ways to approach the product team on why we should fix this now or improve this now, being a being spending some time as a developer can really help with that. And, yeah, I was lucky enough that I just kind of naturally went down that path. You know, DevRel wasn't really a thing when I first started out.

But I see a lot of people now- and I know somebody who is not working in Tech but wants to get involved- and they're like, oh, I want to be in DevRel. I'm like, yeah, it's an awesome space to be in, but you might not enjoy the fast-paced and it's. You know how fast it is, how, how you context switch a lot of the times. So maybe spend some time just in a startup to get used to that and then move on to the next things. But you know that's not to say some. You know it's not a great fit as someone's first job.

I think people do tend to succeed more when they've understood the problems of Developers.

42:47 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2567s)

Would your recommendation be for someone who wants to enter the developer relations industry to work as a developer and then, in their part-time or spare time, test the waters a bit and see whether they would even enjoy the kind of work that it involves? Because I spend a lot of time talking to very talented people, and the fear it takes to hit publish on an idea you have is pretty large. It's something that I think you and I overcame, probably foolishly, through having been in the early days of FTP and the whole have an idea, publish it, and see what happens world.

But I think there's a lot of inertia that prevents someone from being able to do some of this.

43:26 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2606s)

Yeah, absolutely, and I think that comes in many different forms as well. If you're building something and facing a problem and you think you can help someone, just record a video. It doesn't matter how cringey it is or how bad the video is. Just record something, because it might help someone. That's an easy way to test the waters and figure out, is this for me?

You might not get the perfect answer right away, but it gives you an idea of the types of things you can do, because many people trying to record a video for the first time are going to hit record six or seven times in the first 10 minutes because it's not natural and they don't know how to do that yet. And if you want to open source something that you're working on, do that as well. Create a project that is open source and get involved with the open source community by contributing your ideas. Maybe you're not a great speaker to begin with, but that will come.

If you build something and a lot of people appreciate what you've open-sourced, you could go on in a few years' time talking about that and sharing it and presenting it to smaller groups like meetups just to get used to it. That's also a good avenue into DevRel. Open source it, talk about it at meetups, and let those audiences naturally get bigger. I think you become more confident at that point.

45:08 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2708s)

Yeah, that sounds great, and so I think this is a great action plan for anybody who wants to go into developer relations. The part that always kind of- you know, missing pause a bit- is there's a lot of people who are doing the exact same thing. How do you stand out- and it's a two-part kind of a question there- how do you stand out in a world where the algorithms that determine what becomes popular or not popular, especially today? You know, I think today, if you want to become successful operations engineer, I think you probably do need to have a social media presence.

I think, though, you know, I think a lot of the people they talk about were from an era before then, so they can kind of ride that reputational way forward, but if we're starting today, it's a uphill battle.

45:53 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2753s)

It is. It is, and you know, you said something earlier which really resonated with me, and that was not creating content for the algorithms and for social media, but just for you and other people in your shoes, and I think that is. I still think that is a really good way, like if you can begin to just kind of share content on your own website. I've seen people share these in blogs and Snippets and, digital Gardens- I think they're called just sharing these ideas. I think building those up all the time does help build your brand, but, yeah, just spend time in any way.

Anything that can help you stand out is by building a resource that people can come to you and get help with. And, you know, don't be afraid to just say, like, I've done this myself and I know many people that have done this to me in the past and it's why I'm kind of continuing it on is because, oh, they've done something for me. I want to then pass that on to someone else. And that could you know. You wrote a lot of content back in the day that I consumed, that. I went on to create content that others consumed and I think, if you can kind of do that.

That helps, but certainly, to stand out, you need to do something different. And for me personally, it's just creating content that I would enjoy or I get help from, and, like I say, I don't care about the algorithm, I don't write stuff for the algorithm. I tried writing some cringy tweets and people would DM me saying: why, what is it? What are you doing? Like this is weird. Like you're talking, you're speaking differently and it doesn't feel like it's you. You're just, you know, fluffing stuff with buzzwords.

And I stopped and I had I tried a different type of video style which was kind of just given more of an overview, and I had feedback from people: we, I don't like that. Like I like your content because it was to the point. This is how I do this with this, and that's kind of a style that I consumed from the rails days. Brian Bates of railscasts, he did that and I learned so much doing that where it was like this is what I want to learn and this is how you know. This is how to do it.

The videos were very short, and I think, yeah, you can stand out in ways, just kind of finding your niche and this I think I think today with AI, there's a lot of, you know, ideas that haven't even been thought of and I have so many ideas for people who want to create content that you know people can. There's so many ideas that people can have and I have a lot of ideas that I don't have time to do, but I think the position we're in now with AI, there's so much stuff that people can begin to teach and share online and become recognized.

We've seen this when Web3 was kind of taken off and ethereum got really popular. We've seen people creating content around Web3,. So you know people will be doing that now with AI and if anyone's watching that wants to get into content creation, find your Niche there. You will stand out if you get in early. I did that with GraphQL where I create a few videos so many years ago about GraphQL, and I got friendly with people in the GraphQL space and I took some time out. I just was an engineer for a while working with GraphQL.

Then I went on to create videos and then I've stopped again and like, just find your Niche and I think right now is an amazing time to try. You know, if you want to get involved with content creation and standing out, now is now is an amazing time with the AI, with AI on the. You know everyone wants, everyone wants to get involved, everyone feels like they're missing out. Get involved and share content.

49:58 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=2998s)

Absolutely. The interesting thing always is that when we take as many steps back as possible, let's say a 20,000-foot overview of everything that we're doing, in this case developer relations and attention and getting people to focus on what we're doing, it's almost no different than selling a product. Let's say you're selling apples. There are so many factors that determine whether you're going to be successful or not: price, location, distribution, whether you're going to a giant retailer or selling outside somewhere like an amusement park, or basically anywhere people are going to be. So much of it is based on being in the right place at the right time.

There might be a situation where the weather is unseasonably hot and people want apples, or you manage to make apple juice while everyone else is selling apples and now you have your niche there. Being part of an early market that isn't fully grown yet matters a lot. I always point to your early GraphQL content as a great example, because GraphQL wasn't as well known at the time, but you loved it, you were talking about it, and then as the GraphQL community grew, you became seen as an influential figure in it. If we go back decades into the Flash world, it was very much the same case.

I had no idea that Flash was going to be huge or that it was going to be the right thing. I was in middle school, the same age as you, like 10 or 11 years old, and I was like, oh, I like this, it's cool, I'm just going to write about it. It just so happened, thanks to the great work Macromedia did and then Adobe did afterward, that it took off and we rode that wave in many ways. Whenever I look back and ask what helped me do these things, I'm like, I got lucky.

Say 80 was luck, 20 was that I was passionate about teaching and wanting to help people. But there are a million other people who are also passionate about helping and teaching people, and they picked areas where the market got crowded or the industry just went away. If I was doing Flash today, I'd be in the same category. It's like, yeah, I'm writing about Flash and I love it, but there's no market for it. There's a little bit of choosing your topic very carefully, and I think that's a big part of it, especially today.

We used to talk about the world not being a zero-sum game, that there are opportunities for everyone to grow and make things happen. For whatever reason, maybe it's the cynic in me as I'm getting older, the more I look at the industry today, the more I think we're in a moment where it is a zero-sum game, where us gaining attention in these areas means that some other technologies are losing attention because it's oversaturated and we have only 24 hours in a day. Every second and every moment is being heavily tracked, advertised, and monetized by everything we do.

The moment I get in the car I start seeing my in-dash entertainment, and I'm like, why is it so bad? Then I'm like, well, they can cede this control to Apple or Google, but for them those 10 or 20 minutes of my commute are the only time the car manufacturer gets to learn about me and what I'm doing. That gets multiplied a million times and extends into our developer relations world as well. That goes back to the Tailwind conversations. The biggest arguments aren't really about whether Tailwind is good or not. It's why should I use this instead of that?

The answers are very rarely about the best developer experience or the best ergonomics over the years. That's a tension I often see. So I know I went on a big rant there, but that's the thing that always stands out to me.

53:49 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=3229s)

Yeah, no, I agree, I think, on the Tailwind thing, who really cares? Like what, what you use? Just get on with it, just get you know if. If you want to use Tailwind or you want to use styled-components, CSS modules, if you can get the job done, just use whatever you want. I see a lot of people who I and- and this is great- I- love experimenting and learning new things.

But I see a lot of people who will in startups that I've worked out over the past, jump to the hot, the newest, hottest thing, without kind of figuring out is this even worth spending the time and investing on, and I think a lot of companies can't afford to do that. And certainly as we go forward now, you know, in the time turn, at the moment more companies just need to just get on and build stuff and I think having DevRel in companies like that can speak to people, figure out, you know, where is it that?

Where's their product Market fit, where are people wanting the most out of their product? And be able to kind of relay their feedback back to the management team is great, but the people you know on those teams. You don't really make any progress if you're just kind of arguing about what framework to use. So just just use whatever you feel. Great, don't feel as though you need to kind of tweet- and I think a lot, of, a lot of people get this- like you can just run on Twitter about why you should use Tailwind. If you don't use Tailwind, don't use Tailwind it.

You know it doesn't affect anyone else but yourself. And you know, the same can be said for, you know, I like a certain type of food. I'm not, you know, or there's I have friends who are vegans. They don't sit there and tell me: you know, be a vegan, be a vegan, be a vegan, like. Everyone has a choice, right, and it doesn't affect anyone else. People make their own decisions and you know CSS Frameworks are no different.

55:46 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=3346s)

Yeah, it's a. It's a Collision of so many things in terms of the rise of social media, the- yeah, this connectedness we often feel with everyone else, especially from, like you know, the pandemic and all these things, where the few things you can hold strongly are your opinions on Tech stacks and favorite font and you know what VS Code theme you're using and things like that, and I'm like: great, you know, that's what's gonna get you engaged in the conversation. That's, yeah, how, the best use of your time and we all participate and watch it, though. So the algorithm trains. Oh, people, like some hot Tailwind drama this week.

Yeah, we show it to Kirupa and Jamie, you know over and.

56:24 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=3384s)

Over and over again. Yeah, and I will say I do fall for it sometimes. I do occasionally doom-scroll Tailwind content just for fun. It's funny. I think it's great that people are passionate enough. That's the thing not to take away from this. If someone is saying, do this, it's great that they're passionate and putting their passion into your project. So yeah, it's funny.

56:50 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=3410s)

Well, Jamie, it was great catching up with you and learning a lot about developer relations and, of course, your journey through all the various decades of work in this area.

57:00 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=3420s)

Thank you, and thank you. I think we should definitely catch up again and talk about forums, the death of them or the rise of them, and what it will take.

57:07 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=3427s)

Yeah, that's very near and dear to me, very much so. Clearly I learned through this chat that it is for you as well, having not only used them but also built one. At some point we should definitely dive into that one, because I think you and I probably have a lot of opinions and thoughts there.

57:25 - Jamie Barton (https://www.youtube.com/watch?v=6GehrPUhGRI&t=3445s)

Absolutely. I wish forums would come back in force like they used to. I'd love to speak to you a lot more about them. I would recommend that you reach out to Matt Mecham from Invision, because he is an amazing person who created something and is very passionate about this, so he will probably have a lot more to say than I do. He's built one of the biggest forum software platforms. But he's a really cool guy, and I'm happy to talk about it as well. Maybe the three of us talk about it.

57:58 - Kirupa (https://www.youtube.com/watch?v=6GehrPUhGRI&t=3478s)

I think that's exactly what to say. I think the three of us can talk about it. Yeah, awesome. It's been great to catch up. Thank you very much. All right, I'll see you next time. Bye.


Browse all Interviews with Creative People: https://www.kirupa.com/podcast/index.htm