[Weekend Drop] The radiating circles of DevX on the GitPod DevX Podcast

The Circles
- product (incl integrations)
- docs
- content
- community
- UGC

TALK ABOUT SVELTE SOCIETY STORY

Dimensions of the Circles
- negative engineering? or dev exceptions
- onboarding -> production -> prod-dev -> billing -?

Other definitions of devx
- single command do a lot -> until too magic
- does what it says you would do
- making some cycles faster -> esbuild 100x faster - bret victor inventing on principle

Future of Devx? integrate forward, or backward
- content creation meta - video. shortgame + longgame.
- backward -> going into docs, product

Listen to the DevX pod: https://devxpod.buzzsprout.com/1895030/10012425-the-radiating-circles-in-devx-with-swyx-head-of-developer-experience-temporal

Pauline: 0:00

Hi, Shawn! Thank you so much for joining us for a DevX pod today. We're really excited to have you on board. I just wanted to point out this is one of those things where I tweeted about something and then someone was like, I recommend this person. And then I found you, so this is really exciting and we're going to have this awesome conversation about developer experience. Maybe for those who may not have heard of you before, can you give us a bit of an introduction on your story? What you're all about?

Shawn: 0:31

Yeah. Thanks for inviting me on. I'm Shawn also known as swyx online. I originally am from Singapore and, moved to the U S for college and pretty much the rest of my career and spent my first career in finance before changing careers to tech. And since I joined tech, I've been fairly known for learning in public, for speaking about reacts and serverless. And now I work as Head of Developer Experience at Temporal.

Pauline: 0:55

I have a follow-up question actually. What does it mean to be head of developer experience at Temporal?

Shawn: 1:02

It's a role that we basically, I created for myself because when they were reaching out to hire me, they didn't have something like that. And I don't think it's a common role at a startup as well. The bit of a background, which we can get into like how I got started into developer experience. I previously worked at Netlify where I originally joined as a developer advocate type person, but then when Sarah Drasner came along and started leading us as a VP she restructured the whole thing to make it more of a developer experience engineer. So I'm turning developer relations into something where you actually do a bit more engineering and are responsible for parts of the developer experience rather than talking about it. Then I continued that into AWS, whereas also a driver advocate for AWS Amplify. Well, I think for me, the role that I really thought would make the most sense to borrow was something that spans across docs and developer advocacy as well as community. And then I was also a product manager for our recent tax group STK. When you're in a smaller startup, you kind of have to wear many hats. And so, uh, this developer experience umbrella felt that the most descriptive

Mike: 2:14

I think you literally just covered the next two questions I wanted to go talk about. I wonder if you have any more details in terms of overall what DevX is to you?

Shawn: 2:25

Yeah. I've actually written some thoughts about this. I kind of think about it as a radiating circle out from the core product. And so part of this is influenced by me struggling with developer relations at Netlify and at AWS, because often there's a separate team that is responsible for docs. There's a separate team that's responsible for product. It's very hard actually, when you realize. A lot of the things that you do as a developer advocate is very it's downstream of everything else that's above you. And if they're shipped and organized by different teams, then you can get a very disjoint experience. Essentially like your impact as a developer advocate may not be as high because people don't see your stuff as much as they see the docs or the experience about it. So just think about it in terms of like, okay, you start with the core products, make sure that the product design and you get enough feedback. You make sure that API design is really solid. then you radiate out into the docs, which is your sort of first party content on how to use it. I consider docs secondary to products because the best doc's is the docs you don't have to read, right. That is intuitive experience, but still you need docs anyway. And then going out from the docs you need, you go into first party content, which is the role of a developer advocate. And that is anything that's ancillary to docs that explains the why instead of the, what or the how. But you can also dive into the what and the how as well. Like sometimes you just need to pitch the same thing, seven different ways before someone gets it. And then you go from the first party content, which is your blog posts and talks and stuff like that. It's very traditional DevRel fodder into community, which is going from one to many communication to many, to many communication. In other words, having a place where your users talk to other users and help each other out. And then the final tier is enabling third-party content, which is I think about it in terms of users writing blog posts and books, workshops and courses and tutorials about you, even posting jobs with your tool or your technology in the job description on anything like this, where it's very user initiated. I really like encouraging that because that's how you know that you start scaling developer experience beyond the sheer number of people that are working in your company because you have users working for you. But that only happens after you got all the core inner loop stuff right.

Mike: 4:48

I like the analogy with the radiator being in the middle and starting to do, send the heat out. I wonder, what's your take on in product developer experience, how do you make sure you don't have to ride this doc? Do you know that chapter in the documentation and how do you deal with that? Are you directly involved in the product to make certain changes that you think are more intuitive? Or how does that go?

Shawn: 5:13

Yeah, I think it depends on the maturity of the company. This role or this job changes very much depending on whether you're a seed stage or series B and maybe you're not a venture funded company, but depending on the maturity of the products, right? If the thing is mostly fully formed, then you have much less impact or possibility of changing things. But for me, I was directly involved in shaping every single part of the API that we shipped for the TypeScript and I wrote almost every single word of the docs. Very extremely involved! Because then after that it can flow from there to my DevRel efforts and community building efforts. So I think it really depends. The second thing it really depends on is how visual you are versus how much of a code base Platform you are. So we are very code based. In other words, we care much more about API design than user experience design or UI design. I think UI design for visual product makes sense. I think Gitpod probably more of a visual products because there's no Gitpod API. I mean, there's a config and there's no Gitpod API that I integrate into my app or anything like that. Netlify where I used to work as well. Yes, there's another Netlify config, but like the rest of the thing is just point and click. So in that ...