Developer Relations and Beyond with Jamie Barton (Alternate Upload)
===================================================================

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

Jamie Barton (https://twitter.com/notrab) treats developer relations as real product work. Across stories about forums, documentation, startup life, and content creation, he shows how adoption grows when someone takes responsibility for clarity, feedback, and trust instead of assuming good technology will explain itself for free, or that strong tooling removes the need for teaching.

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

ABOUT THIS CONVERSATION

Jamie Barton makes a strong case that developer relations is easiest to understand when you stop thinking about the title and start looking at the jobs underneath it. In his telling, DevRel is part educator, part product guide, part advocate, and part systems translator. That perspective comes from experience. He grew up in web communities, spent years building things himself, and carried those instincts forward into work centered on GraphQL, developer education, and product adoption.

A big part of the episode is about what developers actually feel when they approach a tool for the first time. Jamie talks about writing tutorials early, running forums, and later rebuilding documentation so it felt more welcoming and useful. That matters because polished marketing does not rescue confusing onboarding. Examples, explanations, and honest structure do. He describes the payoff in simple terms: once people can see the path, they are much more willing to keep going. That first-run experience is where trust gets won or lost.

The conversation is also refreshingly unsentimental about the role. DevRel can look glamorous from the outside, but Jamie describes a job full of context switching, feedback gathering, event prep, content decisions, and internal conversations about what should get fixed next. He is careful about social media too. A following can create opportunity, but it should not be confused with substance. The more durable path is to understand developer pain, teach clearly, ship practical material, and keep your taste grounded in what helps rather than what merely gets attention.

WHAT YOU'LL HEAR ABOUT

- DevRel is often the connective tissue between product teams and the developers they hope to serve.
- Developers feel the quality of documentation almost immediately, especially during first contact with a tool.
- Useful examples and clear onboarding do more for trust than polished messaging alone.
- The role rewards people who can switch contexts quickly without losing technical clarity.
- Audience size is less important than being consistently helpful to the right people.
- Developer education works best when it stays concrete, direct, and respectful of the reader's time.

JUMP TO A TOPIC

- 0:00 - An introduction to Jamie: Jamie opens with his background in GraphQL, education, and the work he does in developer relations today. (https://www.youtube.com/watch?v=YcWmt7idulA&t=0s)
- 6:00 - Learning from web communities: He revisits the Flash and Swish era and the online spaces that taught him how much teaching can matter. (https://www.youtube.com/watch?v=YcWmt7idulA&t=360s)
- 12:00 - From personal sites to public teaching: The interview follows Jamie from early website experiments into forums, tutorials, and educational content. (https://www.youtube.com/watch?v=YcWmt7idulA&t=720s)
- 24:00 - Docs, examples, and developer success: Jamie explains why documentation quality can directly shape whether developers stay with a product. (https://www.youtube.com/watch?v=YcWmt7idulA&t=1440s)
- 30:00 - The many layers of DevRel: He unpacks the role beyond the stereotype and shows how much coordination sits behind the label. (https://www.youtube.com/watch?v=YcWmt7idulA&t=1800s)
- 36:00 - Reputation versus real work: The discussion looks at social media, visibility, and the quieter responsibilities that actually drive results. (https://www.youtube.com/watch?v=YcWmt7idulA&t=2160s)
- 42:00 - Advice for future DevRel folks: Jamie shares what helps newcomers most, from engineering context to startup experience and empathy. (https://www.youtube.com/watch?v=YcWmt7idulA&t=2520s)
- 48:00 - Content style and the AI moment: He talks about making concise educational material and where AI may open fresh room for teaching. (https://www.youtube.com/watch?v=YcWmt7idulA&t=2880s)
- 54:00 - Choosing tools with clear eyes: The closing section argues for practical decisions, product-market fit, and less fascination with whatever is trending. (https://www.youtube.com/watch?v=YcWmt7idulA&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=YcWmt7idulA&t=0s)

The common wisdom is this: it's easy to build a product. It is difficult to build a loyal community around that product, and if your product happens to be something targeted at developers, the community builders in this case are the fearless individuals who are part of developer relations. To dive deep into what developer relations is, I chat with one of the OGs in the space, Jamie Barton. So grab a chair, pull up a drink, or the other way around, but anyway, let's get started.

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

Yeah, hey, thanks for having me. It's great to be here. I'm Jamie. I'm a DevRel at Graphbase, and I create educational content on GraphQL. I've been around a while in the tech scene, 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:47 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=47s)

Cool, yeah. I feel like I've known you for a very long time as well through your online content, and I'll put a link in the description below. I think last year you and I had a recording where we talked about GraphQL, 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 pieces of it, I want to learn more about how you got started in tech.

1:11 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=71s)

Well, I got started when I was around 11, maybe 10 or 11 years old, when I first got my PC. My grandfather bought it for me, and from that day I was fascinated with the web. I didn't even have internet at home back then. My 56K modem was in my machine, but I didn't have internet access, and I managed to persuade my mum at the time to go out and buy a CD with an ISP installation thing on it. We would then install the drivers, and I got hooked on that whole aspect of installing things, configuring things, and playing around with things.

And when I did get the internet, I was just hooked. I created my first website on my machine, I think with FrontPage, and I used something called Netscape Web Builder or something like that. It was part of the Netscape Navigator stuff, and I just got really hooked. I can talk about this forever, but I got hooked at that point and just fell in love. My memory doesn't go back perfectly, but I remember they had this tool where you could log in. I think maybe it was attached to your ISP login, because back then logging in and authentication were all very new.

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 Jamie'sMagic3. Cjb. Net, one of my first sites. And the cjb. Net thing was just something you could get a subdomain for that pointed to an FTP account, and I would use FTP from my ISP to host my website.

I was doing this for friends in school, and I just loved playing with this stuff and figuring it out. This was back when you had to create borders and border radiuses with images.

3:37 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=217s)

That's right, the spacer GIFs with the corner radius. Essentially, what would normally be a typical border would actually be a table with a three-by-three layout — nine cells, basically — and one of those would make a typical corner. That makes me laugh. It's pretty funny, 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. It was Netscape Composer for me, 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 the HTML, type in the iframe, and then the editor would just show you what needed to be done. I was like, where's the insert-iframe button? Kudos to Microsoft's marketing back then: they actually said you can edit iframes. And the funny thing is that 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. We deprecated the server extensions on Unix machines quite a while ago. Can you please do something slightly differently? So I did a massive bulk replace with Apache server-side includes, which is what I still use today. I used Dreamweaver because FrontPage had been discontinued, Expression Web, which was the replacement for it, had been discontinued, and so Dreamweaver was the only one that survived up until now. For me it's the closest to that what-you-see-is-what-you-get experience, so when you describe it, I'm like, that might have been what was done decades ago.

Unfortunately, it's what I deal with even today.

5:35 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=335s)

Yeah, that's pretty cool, that's really cool.

5:42 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=342s)

Yeah, I mean, the day when they say Dreamweaver's also discontinued and I really have to figure out a more modern solution to this — is it WordPress? — I'm not sure what the solution is, 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 redesigns along the way, some abandoned and then brought back again, and so on. I'm hoping that day doesn't happen anytime soon.

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

So when I started out, I got into Flash and picked it up. Obviously your website was a huge resource back in the day for Flash stuff, and I loved visiting just to learn things. And I also 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 and create my own content. I used Flash, 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 also 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 bit more of the ActionScript side of things, then trying to relay that back to Swish because I was familiar with it. As much as the web's moved on, those days were really fun.

I don't care what anyone says — that was an awesome time to be alive.

7:38 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=458s)

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

We always have to say that the thing that made the web better than traditional languages like C++ and Java and so on is that you get Hello World up and running in the fastest time. Launch 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 who are still doing this work, can remember it.

Everyone today is more like, yeah, the norm is I spend a few hours in my build tools, setup, web host, and then they look at other IDEs and are like, yeah, no, I'm just going to write code for everything I want to do — even visual things. I'm like, that sounds so backward. But hopefully tools like Webflow and some of these low-code tools we're using right now are getting a little 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 or no coding experience can create Snake and these very elaborate applications that even seasoned developers would have difficulty figuring out.

9:14 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=554s)

Yeah, yeah. It would take me a while to get started and create something from scratch again. I think these days it's very easy for developers to reach for a component library or a CSS library, and I know there are so many little 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 a way that you could take your files, drop them somewhere, and it just 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 been someone who just enjoys writing code from scratch. I'll look at an example online and it may give me the tutorial, and I've always just written it out again.

I haven't copy-and-pasted, and it probably makes me a little slower, but it's a good way to learn and memorize some of the semantics of stuff. So I've just enjoyed doing that, and I haven't worked in the CMS space for the last few years. I've been telling people, oh, everything's composable and you need to bring things in and use this service for that and another service for this. That is awesome at a really large scale, but for a lot of people who are just getting started, that is very, very overwhelming.

So I agree that things like OpenAI, and generically a lot of the AI tools, are going to make the onboarding or intro to development easier, I hope, because it's mind-blowing that you can create apps, games, and all kinds of stuff with AI now, and it's just 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 going to be an interesting time. I think 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, and you can feed it your own stuff so everything is contextualized, which is going to be even more powerful. So this is only going to get better.

11:57 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=717s)

Yes, and by the time we finish a recording and get it live, probably a whole new set of things will have come out since then that completely move the needle even further in terms of what is capable there. So you went from being in the Flash community for quite some time to creating content. Tell me more about that. What motivated you? What was the first piece 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:31 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=751s)

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 vBulletin guy. The vBulletin- for anyone watching this- I enjoyed like 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 Invision and I still speak to on Twitter today, Matt Mitchum, the creator of that, 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 more 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 a few years later actually- that my school gave grants for people starting 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 which is which was 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 as I could. To the point where I met someone called ali who ran a swish 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, you know, faster than 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.

17:12 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=1032s)

No, that's really impressive, because one of the Pains of dealing with most the performance back then was that it was in usually MySQL, and then you had to figure out like how do you back it up regularly? What if it gets corrupted- which happened all the time and people went up for like large attachments. Somebody glitch somewhere and you're like: great, I have no idea what I'm going to do now. Let me restore my backup and move some data. The text file solution is very elegant, yeah.

17:34 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=1054s)

Yeah, we thought so too. It was like, I say, it was so fast, and that was because the page P file just lived next to the text file and back then, you know latency and people weren't really too concerned about this at that time. You know, people had 56k modems, so it's not like everything was Blazing fast, like no one really knew if something took one second or two seconds foreign. Yeah, 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 can't remember 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 fit 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. 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- I think I- posted it to a PHP endpoint back then.

I- I can't remember, I think it was a PHP endpoint, but I remember just writing about this and it'll be on the way back 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:47 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=1247s)

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

20:55 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=1255s)

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 Max.

It was kind of my full-time job and I was 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 said, 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, and times are 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 the 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'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:48 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=1548s)

You know, 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 on my one-on-ones and on my calendar are people in developer relations. Because when it comes time to feel like you're building a developer-facing product — which is what I work on, Firebase and that area — the people who know the most about what developers want, need, and might want over the next couple of years are developer-relations individuals. I always found them to be the best resource to use outside of you actually talking to customers yourself.

But even if you do talk to the customers yourself, are you the right person? Are you asking the right questions? Are you subject-matter expert enough to be able to carry on and see between the answers they're giving? Developer relations always has that one completely figured out. So I was very interested to learn more about how you got into it, because I've been following your content for quite some time and I've greatly enjoyed it, so it's a great answer there.

26:45 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=1605s)

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 is 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 stays with me forever, that it doesn't matter what that person does if they move from one company to another. I 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 devorelle 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 uses 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:26 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=1766s)

Yeah, oftentimes you hear that developer-relations team members are like customer zero for any product that's being built, because they are both early adopters of whatever technology your team or company is building and they can provide feedback that channels what the broader community would want as the right set of developer ergonomics, for lack of a better word, based on what competitors are doing, based on what the trends are in the market, based on what kind of libraries and quirks and all those things are out there. And I think that voice of reason between balancing technical needs, customer needs, and even business needs is oftentimes a very unique skill.

30:10 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=1810s)

Yeah, yeah. It's, you know, every day is different, and it's fun because of that. I think a lot of the time, when I first became or moved into the DevRel space — and I think the role was Dev Success — no one really understood what Dev Success or developer relations did. Six or seven years ago, I don't think I did either, but I think today there's still maybe some misconception. It's a lot better today because people appreciate the results and the work that DevRels do. But I remember way back when no one really knew what they did.

They thought they just kind of tweeted all day and created stuff on Twitter and posted blogs, and that's certainly a huge part of the role. But under the developer-relations umbrella there are a lot of different avenues that you can work in. The advocacy side is more about sharing and speaking and presenting your product — not just at conferences, but through video content, workshops, and whatever that stuff. I think a lot of businesses don't understand the actual value that that brings. They just see it as, oh, they're an influencer or whatever.

But if somebody is in DevRel and they are technical, they can make that content very, very helpful for converting users and getting people signed up for your product. At the end of the day, that's what it comes down to: we want people to pay for our stuff, and the easier people find your product, the more likely they are to pay for it. It's as simple as that. I think the biggest misconception is that people just sit and tweet all day or scroll Twitter and rage about which framework you should use, like you mentioned with Tailwind. That's every week right now. But I think that's a misconception.

On the flip side, what people miss is the actual results of everything that DevRels do. Yes, you can go meet people and talk to people, but I guarantee there are a lot of engineers — and I don't mean this in a negative way, because I have friends who have been like this — who will put their hand up and say, I'm an engineer, I don't really like speaking to people. That's where DevRel is great. Being able to speak to somebody and have a technical understanding and experience is massively underappreciated if you've got someone on your team who can do that.

33:16 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=1996s)

Yeah, that's it. Always look backwards right in terms of like. What are organizations and companies and their framework ultimately doing? Is you're building something that's going to be 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 end point of like is someone who is window shopping, let's say, for a particular solution for their technical problem. Are they able to find us?

And when they do find us, are they able to say that 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- you know what we typically call like an independent or a bottomed up kind of a developer, be the one who basically pulls up their chair with documentation and themselves. What is the journey? You know how friction free can we make it for them- and I work with developer relations, you know, across mostly large companies, but they approach these products. Often use has been very different.

You know, one company I worked for was very B2B focused. The decision on what solution you use was made by a CTO or a sales team years ago. It was a massive contract and then developed relations was really okay. You've already made the decision to use the product. Now let's talk about how you can make it work. Very different Dynamics, very different tone and style of approach in another compared to others, to the solution where it's easy to switch from what you're building right now to another product from someone else. Everyone recognizes that and so the approachability and tone again is very different.

These are all like art, art forms that I've seen in, like how the conversation goes and things. So watching these things firsthand was a huge learning experience. Just the range of the operations and the style that you have to follow, depending on the type of business they're currently in.

35:00 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=2100s)

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:23 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=2183s)

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

36:34 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=2194s)

I don't think it is that important. I think this there's two. There's two things this I think. The first is selfishly for you as a, as 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 like become recognized and you know that can lead to potential opportunities, whether it's new jobs, projects or, you know, Partners in starting a new business or whatever and on. On the other side. The second point is it's if you understand something. That is often all it takes.

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

37:43 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=2263s)

No, that 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: what is the value of a Twitter follower? What's the value of someone on your Facebook page, and so on? I've taken the very opposite approach over the years. I'm not an anti-Twitter person, I just don't get it, and the amount of time it takes to do it properly is a full-time effort. People think all these great developer-relations posts that accidentally get popular happen by chance, but no — it's actually done very deliberately.

The content is properly curated for the audience, the time, and the format. It's a real skill, and one that I do not have. The approach I've taken over the years is really that Google Search indexes my content. I create content on problems that I'm currently facing as I'm hacking away at something really cool, and then I write about it. A year or two later enough people are like, oh, I'm doing this now, I ran into this, and it just happens.

That's always been an interesting one for me because we talk about operations and influence and there are some people you don't really hear about much, but they're still very, very influential. One of the more interesting people I've known over the years has no social-media account, yet is one of the more popular presenters at conferences, where the rooms are often at capacity. It's fascinating because it also speaks to the audience for them. You don't discover this individual through Twitter or social media. It's a traditional B2B kind of system where, if you're in the know about certain products, then you know who this person is.

That's another interesting way of thinking about how to position yourself. It's like, it's very crowded here. What niche can you find to set yourself apart in? But I do agree with building your own brand, because it's a competitive space. And as you've seen, tomorrow we'll both be replaced by another version of an AI avatar that's doing exactly the same thing, using our previous content as training material. No one outside of basically you and I would know that it's not us doing this. So having a certain reputation that can't be easily replicated, or that isn't tied to any one company, brand, or industry, matters — because the world evolves.

40:14 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=2414s)

Yeah, yeah, no, you make some really good points there. It's really fascinating. And that's a really good point you make about how it doesn't matter if you don't have a large social following — you can still be just as impactful and powerful without that. I think there are 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.

If you can become a developer, or get a job as a front-end developer, back-end developer, junior developer, whatever it may be, spend some time being faced with problems day to day and appreciating the levels and quality differences of the solutions and tools you're using. That makes things a little easier when you actually come into DevRel because, yes, you've got the advocacy side and being someone who is influential, can help others, and can speak to people nicely is great, but if you don't understand the problems people have, it makes things a lot harder.

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

But I see a lot of people now — and I know somebody who isn't 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 how fast-paced it is and how much you context-switch. So maybe spend some time in a startup to get used to that and then move on to the next things. That's not to say it's not a great fit as someone's first job, but I do think people tend to succeed more when they've understood the problems of developers.

43:05 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=2585s)

Would your recommendation be for someone who wants to become a- you know, entered it up for relations industry- to work as a developer and in their part time, on their spare time, just test the waters a bit and see a what they even enjoy the kind of work it involves- because I spend a lot of time talking to a very talented people- and the fear it takes to basically hit publish on an idea that you have. It's pretty large.

It's something that I think you and I have overcome, probably foolishly, through having been at the early days of like FTP and again, you know, have an idea, publish, see what happens, kind of a world, but I think there's a lot of inertia that prevents someone from being able to do them.

43:43 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=2623s)

Yeah, absolutely I, and I think that comes in many different formats as well. You know that could be: 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 cringy it is, it doesn't matter how bad the video is, just record something and it might help someone. And that you know that's, that's a, an easy way to get and test the waters. I guess kind of just figure out. Is this for me?

You know you might not get the answer, like the black my answer, but it just gives you an idea of the types of things you can do, because many people just trying to record a video the first time are going to hit record six or seven times in the first 10 minutes because it's not natural they don't know how to do that. So it's just something to get. You can try yourself, get you know getting into by recording these things. And also, if you are someone that just wants to open source something that you're working on, do that as well.

Create a project that is open source, trying to get involved with the open source Community by contributing your ideas. It might be you're on a great speaker or anything to begin with, but that will come. I think if you build something and a lot of people appreciate what you've open sourced, you know you could go on and yes time talking about that and sharing about that and presenting its smaller groups like meetups, just to kind of get used to it. That's also a good Avenue into. DevRel is open source. Talk about it at meetups and, you know, let those audiences naturally get bigger and I think you'll become more confident.

At that.

45:26 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=2726s)

Yeah, that sounds great. So I think this is a great action plan for anybody who wants to go into developer relations. The part that always makes it difficult is that a lot of people are doing the exact same thing. How do you stand out? And there's a two-part question there: how do you stand out in a world where the algorithms determine what becomes popular, especially today? I think if you want to become a successful developer-relations engineer today, you probably do need to have a social-media presence. A lot of the people we talk about are from an era before that, so they can ride that reputational wave forward.

But if you're starting today, it's an uphill battle.

46:10 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=2770s)

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 to 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 you know you wrote a lot of content back in the day that I consumed.

Then 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 written writing some cringy tweets and people would DM me saying why, what is, 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. You 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.

50:16 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=3016s)

Absolutely. You know, the interesting thing always is that when we take as many steps back, you know, let's take like a 20 000 foot overview of everything that we're doing, in this case, develop relations, attention, getting people to focus on what we're doing is almost no different than selling a product that you might be. Let's say you are selling, like you know, a particular, let's say you're selling apples. You know where. You know, at a place, there's so many factors that go in determining whether you're gonna be successful or not: prices, one location is the other. What's the distribution?

Are you going to be going to a giant, you know retailer, or gonna be, you know outside, like on an amusement park or basically a you know just anywhere people are going to be, and so much of it is also based on just being at the right place at the right time. There might be a situation where, like, the weather is unseasonably hot and people want apples, or you've managed to bake apple juice whereas everyone is making selling this apples and you have your 800 Niche there and so being part of it, you know being early in a market that is, you know, not fully grown yet.

Like, I always felt like your early GraphQL content was great because GraphQL wasn't as well known at the time, but you loved it. You're talking about it and then, at the GraphQL community grows greatly, you were able to, like you know, be like seen as an influential figure in it. Yeah, if we go back decades into the or in the flash world, it's very much the same case. You know you would switch tools and me with flash. I had no idea that flash is going to be huge, is going to be the right thing.

I mean, I was in Middle School- it's like you know, the same age as you- like 10 and 11 years old, and so 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 macro media did and then Adobe did afterwards, that it took off and we just kind of rode the wave in many ways. So whenever I look back and I go like, what was it that you know helped you be, you know, able to do these things with them, like I got lucky, you know say, 80 was luck, 20 was that?

Yes, I was generally passionate about teaching and wanting to help people, but there are a million other people who are also passionate about helping- and, you know, teaching- people, but they picked areas where other colored Market or that entire industry just completely went away. And if I was doing flash today, I'm in the same category- like, yeah, I'm writing about Flash, but I love it, but there's no market for it. There's a little bit of. It is like choosing your topic very carefully. I think is a big part of it, especially today when, yeah, yeah, we used to talk about like the world isn't a zero-sum game.

There are opportunities for everyone to grow and to make all these things happen. For whatever reason- though maybe it's a cynic in me as I'm getting older, the more I look at the industry today, the more I look at what we're doing. I do think we're in a moment where it is a zero-sum game, where us gaining attention in these areas means that someone or some group of, like other Technologies, are losing attention at this point because it's over saturated, 24 hours in a day, every second and every moment is being heavily tracked, advertised, monetized by everything we do.

The moment I get in the car, I you know I start seeing my in-dash entertainment, so I'm like, why is it so bad then? I'm like, well, they could see this control to Apple or Google, but for them, those 10- 20 minutes I am doing my commute is the only time that the car manufacturer gets to basically learn about me and what they're doing, and that is Multiplied a million times and it extends into our developer relations kind of a world as well. Is that? Yeah, that goes back to the Tailwind conversations you know the biggest arguments aren't really about. Is Tailwind good or not?

It's why should I use this instead of that? And the answers are very rarely. I thought like this provides the best developer experience. This gives you the best you know, ergonomics in terms of like how you can scale your content over the years, and that's attention I often see. So I think it gave a big rant here, but yeah.

54:06 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=3246s)

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 style 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 at over the past, jump to 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 zone, 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 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.

56:04 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=3364s)

Yeah, it's a collision of so many things in terms of the rise of social media, this connectedness we often feel with everyone else, especially from the pandemic and all these things, where one of the few things you can hold strongly are your opinions on tech stacks, favorite fonts, what VS Code theme you're using, and things like that. And I'm like, great, that's what's going to get you engaged in the conversation. That's the best use of your time, and we all participate and watch it, though. So the audience likes some hot Tailwind drama this week, and we show it to Kirupa and Jamie, you know, over and over and over again.

56:44 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=3404s)

Yeah, and I would say I do fall for it sometimes. I do occasionally doom-scroll. It's funny. And 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, that's great — they're passionate. Put that passion into your project. So yeah, it's funny.

57:08 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=3428s)

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

57:18 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=3438s)

Yeah, thank you, and thanks. We should definitely catch up again and talk about forums — the death of them or the rise of them — and what will it...

57:25 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=3445s)

Yeah, very near and dear to me, very much. Clearly, even through this chat with 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:42 - Jamie Barton (https://www.youtube.com/watch?v=YcWmt7idulA&t=3462s)

Yeah, absolutely. I wish forums would come back in force like they used to be. I'd love to speak to you a lot more. I would recommend that you reach out to, or speak to, Matt Mitchum 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. But he's built one of the biggest forum software platforms, and he's a really cool guy. I'm happy to talk about it as well. Maybe the three of us talk about it.

58:16 - Kirupa (https://www.youtube.com/watch?v=YcWmt7idulA&t=3496s)

I think that's exactly what to say. I think the three of us can talk about it. Yeah, yeah, awesome. Well, no, 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