DevXPod

The radiating circles in DevX with Swyx (Head of Developer Experience, Temporal)

• Mike & Pauline • Season 1 • Episode 5

Share episode

In this episode, we chat to Shawn (also known as Swyx online) about his take on developer experience as a discipline - we have hot takes, developer love for Svelte, video content and have analogies about radiators. This one's a good one!

The hosts  ▻

Our guests  ▻

Things mentioned ▻

Let's chat some more! ▻

Pauline:

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:

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:

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

Shawn:

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:

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:

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:

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:

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 sense, yes. The role of UI design, I think is very powerful. The last point I'll mentioned for you as well, is that another principle or API design principle that applies regardless of whether you're doing visual or programmatic SDK work, is that you want to try to enhance the power of a single command. So for us it was Netlify deploy or git commit, and that would create a whole new deploy preview. And that was a big revolution in front end development. There was other analogies in the CLI that we should, that we shift this well that I was involved in. But I always think about that in terms of like, okay, how do you increase the power of a single action and just pack as much as possible in there? I really liked that idea. I don't know if that is described as good developer experience, but to me, I think that really contributes to a wow moment that where you type a single command and something magical happens, because that would have typically taken many steps to accomplish.

Mike:

I think this is a great way to describe it. The other thing I like is when it does what you expect it to do, I think that's another huge one. You could have add whatever, but then, it does only half of the stuff or, yeah there's really good examples out there for sure. Nice.

Shawn:

There's a part of a developer experience, which I often talk about which is a developer exceptions. In other words, developer experience often we talk about happy paths. Like, oh, if you ask them, do I like this? Look at how amazing it is. Look at how awesome and how fast and how everything, how amazing everything is. But people in developer experience often don't talk about the, what happens when things go wrong and actually sometimes paying attention to giving you a nice remedial path when something goes wrong is actually also a really good experience that developer experience, which people don't talk. So improving observability, making sure that you don't have pricing mistakes or your pricing is predictable, at least. And doing things like having clear versioning and deprecation support policies, these all kind of boring and less headliner things that you want to ship, but it's actually very key for developer experience.

Pauline:

That's a really good point. You said having a wow moment and that I think is a really good explanation of what developer experience is. Why is it important to you that we have that wow moment? Why should we even care about developer experience? Why have that wow moment?

Shawn:

I think the wow moment is more of a marketing thing in the sense that there's a lot of developer tools out there and you need to stand out somehow and you need to get to that wow moment as quickly as possible because everyone has other things going on. They may click away if you don't get to that wow moment. so I think that's part of it. The other part, which is also like game design, in the sense that, you need to keep having rushes of endorphins to you, to make your job fun, to have the developers stay in flow and developers that stay in flow and more productive. As to why in general, should we even care about developer experience? I actually, yeah. There's a cynical view. And then there's a more genuine view. The one genuine view is that developer experience helps, developers be more productive, which helps ship more products and makes users happy and blah, blah, blah, develop a tooling companies are worth multiple billions of dollars. And if you can help a developer tools company improve the developer experience in whatever form, then that creates a lot of value for developers. That's the feel good, happy view. My secret problem with developer experiences that I don't think it's that important. Like it's, you're not curing cancer. You're not flying to Mars or anything like that. So I think it's intellectually, interesting and financially very rewarding career. But we should also be a bit humble about. Yeah. Like nobody wakes nobody else outside of developers cares about developing experience. We, they just care about, are you making the thing that helps me make the other thing go faster or ship faster, whatever. And that's it. All these other metrics around, like, I don't know, like number of people visiting your blog posts, like no one cares. So I'm very cynical about that sort of thing. Oh

Mike:

no, my analytics,

Pauline:

I was just going to say that's... That's probably the most refreshing take actually. Because I feel like a lot of other people have not mentioned it in that sort of way or describe developer experience in that way you are right.

Shawn:

Also, I wasn't interviewing there, I was talking with a very senior person at Cloudflare and, I told him this . And he was, I think he was like considering to hire me or whatever. And it wasn't an interview or anything, but I think I closed that door when I told him this, because he was like, what are you talking about? Developer Experience is everything. I'm like, dude, like, come on. Like, like developers are very pampered. Like we have like unlimited leave ,we have like six figure salaries. We're fine. Like, we don't, you don't have to pretend like this is the highest value thing in the world. But, I mean, it's still very valuable. It's just it's one of many possible things that smart people are. Oh, could you read it one more? Nice thing, which is that I think improving the developer experience for beginners is very important. Enables beginners to get started, to make the career, to, to transition their careers which is I'm a career changer myself. And if I did not have the help of people who focus so much on docs and community and, making things accessible to beginners, then I would not be here. I'm not against it. I'm just saying it's not, you know, there are also many other important things.

Pauline:

Absolutely. If you're like a doctor or a surgeon, or solving our pandemic . Yeah. No, thank you for that. A lot of our guests have said accessibility especially to begin as is why people should continue caring about developer experience and improving it and stuff like that. That's a good point.

Shawn:

Yes.

Mike:

No, no, I, I was, uh, I wanted to move on, but that's a good point. And it does make moving on a bit easier then on the previous note we talked about, so I think we talked about the commands that, you know, do a lot for you. What other kind of like excellent developer experience have you experienced or maybe build yourself or with the team that you can share about?

Shawn:

I feel like I should write this down because there's a number of nice develop experiences that stick in my head that I haven't really articulated very well. So in other words, single command doing multiple things that's good until the point that it becomes too magic and then that's bad. We've established that already. Another one that I really like is making some cycles faster, right? If you can make things in order of magnitude faster than you have better developer experience. Something that people bring up a lot is the benchmarks of IES built in the JavaScript ecosystem, comparing to Webpack or a parcel or roll-up. On the ESPP build website, they have a very prominent benchmark that shows that they are a hundred times faster than Webpack. And that is. And when anytime you increase things by orders of magnitude, that you unlock different usage of that tool. And so I think it's a very important thing to try to always look for areas in which you can speed up the feedback cycle because then you unlock opportunities for play. I think one of the best talks on developer experience that everybody has talked about is I think Bret Victor's inventing on principle talk, where he shows like, okay, if instead of jumping back and forth between your editor and your final output, why not just combine them and have your app or your writing be directly interactable so that you can shape it and play with it as you go along and discover new things because of the play. So I really am inspired by that. And there's a simple analogy to the shift left ideology that came out of IBM, which is that a lot of times when people discover bugs, they discover it very late in production, or even after they shifted in production. And if you shift things left, if you reduce the feedback loop of finding bugs, whether through tests or types or a QA or whatever, right? There's a whole bunch of techniques that are all developer tooling and development experience related. If you shift those items left from production back into the development time, then you enable the opportunity to increase the feedback loop in and correct your mistakes before they get too far out, or you build too much. So I really liked that feedback loop reduction, and then another developer experience thing, which I really like is this idea that everything is just there for you. In other words, you don't have to go out and assemble a bunch of different tools yourself, having an all in one package that with blessed the tools that are known to work together, I think is really helpful. One example of this is I'm actually going to venture out to the jobs review system and talk about Anaconda and Python. So Python is a fairly wide and huge community. But Anaconda is a specific distribution of hyphen with preselected pack packages that are all guaranteed to work together because dependency resolution was a huge problem for the Python ecosystem and the data scientists that were using Python, where it's spending so much time, like trying to say, like, does this work at the other thing? No, it doesn't. So I will have to both drop back to like an older version of the common thing, blah, blah, blah. Very common in JavaScript as well, by the way. But Anaconda actually managed to carve out a niche in Python and made Python, the de facto language for machine learning because they made that develop experience so much. And I actually genuinely think that they are, single-handedly responsible for making Python itself that much more popular. I think that's another interesting thing, which is like, where's the all-in-one for the 80% of use cases that don't need that much customization. Of course, if you want to customize sure, go ahead. You have the full power, but most people, they don't, they just have very standard needs. Let's just do this, just pave out the common path. And so that's how I went from using React. Which is the most popular Javascript framework, to Svelte, which Mike knows very well. And so has all the tools and tools included batteries included. And if I need to customize or drop out of it, I can. And I think that is also a really good developer experience in there so that the, all the ones who toolkit it, that doesn't constrain you too much.

Mike:

So really the question for 2022 is what's the Anaconda of JavaScript?

Shawn:

When Vercel talks about building the SDK for the web, that's what they mean.

Mike:

Yeah. Good point.

Pauline:

You gave me lots of flashbacks of playing around with Python over the past few years. I haven't really been in that ecosystem in a long time. Actually, Mike will be really proud of me, but I started learning and rebuilding one of my big projects. One of my, well, actually my blog, which is my biggest project, in Svelte, moving away from Nextjs. But, it's taking me quite a long time, longer than I thought, because there's so many. I don't know, there's so many different things that I need to learn how to use this Svelte way of doing things. But yeah, it's really interesting. It's a lot of fun. I understand why Mike and yourself love it so much. I think.

Mike:

We will talk offline about that Pauline.

Pauline:

So let's, let's do that. Yeah. Lots to, lots of talk about, yeah, it's messy. Yeah. Awesome. Thank you for sharing that.

Shawn:

One thing I'll share with you about this Svelte thing. I'm friends with Rich. I had come across Svelte, but actually ignored him for a year until I was like on a trip with him at Barcelona. And then he was like, he's still talking about Svelte. And I was like, okay, I have to try this because you can only be friends with someone so long before you have to try their things. And then I tried it and I was like, oh, okay. I'm an idiot for ignoring this for so long. But the other thing. Notice was that Svelte did not have a very strong community backing behind it. So actually started Svelte society as a part of the next stage of developer experience. So if you think about that reading radiating circle thing, had a very strong product already and it needed and it had pretty good docs. It needed the next level, which is community or DevRel, whatever that is. There is no first party DevRel for Svelte, but I guess Rich's the one had a one man show for that. The community part was the thing that I focused on and that's how Svelte society got started.

Pauline:

I was going to say, but this is what is this? Maybe the sixth or seventh episodes that we'll be posting on dev X pod and community has taken the lead every single time. It's always the thing that brings everything together. And it's also very validating because I focused on community at Gitpod so every time I hear it, I'm just like, yeah, that was great. Cool. Awesome. I wanted to move on to our next question, which is, where do you see DevX evolving? Will we be focused on tools or people or community?

Shawn:

I think, in line with the model that we've been developing, in this episode, either you integrate forward or integrate backwards, in other words, a typical typically develop experience is very tied to developer relations and a lot of first party content creation. So you integrate forward, meaning that talk a little bit more with community, you take on more community management roles or you encourage more, third party content by holding workshops and stuff like that. Or you integrate backwards, which is you get more involved with products. So I think that's an interesting way to think about this in terms of the radiating circles, but the other way to think about it as well is what's the shift within the content creation meta game, which I think about a lot as well. So for me right now is that I think a lot of people should be shifting towards video. I think that, the amount of time that how much time do you spend. You know, a week or a day I spent roughly an hour or two hours. Yeah,

Pauline:

exactly. I was going to say a bigger number than that, so, yeah. I'm glad you said your number first.

Shawn:

We all spend, we all spent a lot of time and a lot of times we're never going to spend on developer content because we're just on YouTube to veg out to. But I think people who do video very well are getting disproportionate attention. And I think it's a very scalable format. There are challenges with it, which I think Mike has maybe one up in the past before, which is that video is very expensive to produce and it gets outdated very quickly. There will be new tools that arise to fix that. But otherwise, I think the sheer reach of YouTube is just unparalleled. It is the second biggest search engine in the world. The content that lives on there, if you can get it to be evergreen, it can be extremely valuable. I still get comments on videos that I did two years ago, I always think about the half-life of content. The half-life of a tweet is four hours. The half-life of a blog post is maybe like a year or if it's a good blog post, if it's a normal. blog post that everyone is like treating us nothing special then. Yeah. It's probably a day or so. That will be irrelevant in a non-existent, but for videos. It's definitely very long. So I'm very interested in that. And I almost also interested in this idea of having a short game in the long game. It's kind of like tennis. If you only play long games, if you only stay at the back and you only love the ball and then you get killed on the, on the short game. Likewise. So in other words, do you have a short form game where you can pitch your startup in very short and concise detail? And do you have a long game where if people want to engage with you over very in-depth conversation, you also have ability to go deep and you have the content to offer them. I think having, so this is why I focus on having two minute videos and three hour workshops. you want to go extremes? There's a lot of 30 minute talks and podcasts out there. That's fine. But, I think the areas of relative under development are the short game and the long game.

Mike:

I had a conversation with a friend recently where she was asking me like, Hey, why don't we put some educational tech content on TikTok? And it was around the time when, TikTok had took over Google products in terms of like number of visits in 2021. And that was yeah, actually, why not? So I signed up for TikTok and I spent like 10 minutes watching videos. And I'm like, this is crap. Like what the heck? There's just too much stuff I don't care about. So I need a way to filter the stuff I care about. But then I started searching for things like web development, full stack development, and then whatnot. And there's a few things, but I think what you're saying in terms of the two minutes versus longer things, you can take that to an even other extreme of I'm going to take a real cheesy example, but array methods. One video, 15 seconds about each method and put it up there, see if it goes viral and people talk about it. But I think this is another platform that it's going to up and coming and currently not used for it, I think might be a really interesting play.

Shawn:

To see if it started watching it. I'm keeping eyes on it as well. The problem is that every, everybody knows array methods and you're not really doing anything for your work by explaining a writing methods. You might grow your own personal following, but that's also not a very valuable following. And let's just be real about that, right? If you get a whole bunch of beginners, then you will be incentivized to create more beginner content and you'll be stuck in beginner tutorial. And then I see a lot of people also get stuck to that because the numbers are only thing that matters to them. So I think, as far as philosophy of consecration goes, I definitely aim for some mix of intellectual curiosity and reach. And if you have only reach, then you may sell out yourself and you may burn out. You may not fall in love with the process. And I think that is the saddest thing in the world for someone to be in such a privileged job as a developer experience person, and to have your own personal intellectual curiosity, thrown by the wayside. I do, and they're doing courage to try to pursue some mix of reach plus first intellectual curiosity. I think the person that really does it best is Scott Hanselman. I don't know if you follow him. To talk as well. He does introductory stuff, but it's always authentic to him. He's not selling out. He's genuinely like, Hey, I think this is really important. And whether or not it happens to be advanced or intermediate or beginner, he's always very much that this is something he genuinely thinks in his.

Pauline:

The first thing that's on my mind is the fact that I love how in the past two episodes, actually we've been talking about, we've been bringing to light, content creation in developer experience because I don't think a lot of people think about that. Certainly until the previous episode, I didn't really think of developer experience, including content creation or including things like videos or tech talks, because the only thing I was thinking about was the products, like how can we make the product better? So that engineers on board quickly. So yeah, I really liked this conversation and it's really quite eye opening for me. I don't know. Mike, I wanted to say to your point, TikTok does get better after you train the algorithm. I was like, I don't know why anyone is on this app is just full of gen Z. I was just like, I don't understand this. But then after I started watching content that I actually liked it's really good it's really interesting. And now I've been hooked like at least an hour a day. I've been on it.

Mike:

But well, on the bright side, I have a lot of different methods to peel a pineapple now. So I learned a

Pauline:

lot of, and the how to use an air fryer in all these different ways, how to cook all these different recipes. Oh, yeah, it's really cool. I just find it really interesting that content creation is included, but it really validates where my thoughts are in terms of content creation and develop experience as a whole.

Shawn:

This job, this industry is still very nascent, so it's not well-defined. So I don't think you should feel weird about it at all. I think for me, I came at it from my background, which is that we called this DevRel function, this content creation function at Netlify, we called it developer experience engineer. And so that's part of what we do. I should also mention that. Yeah, we were responsible for third-party integrations as well. So I guess.

Pauline:

Exactly.

Shawn:

But no, I think, at the end of the day, people wants to develop the tools. Companies want people to discover them and the best ways to, through content marketing. And that's why they hire people who are smart at that. And getting them down through that top of the funnel is very useful to them. I think probably where that we need to do better is that yes, I can pull a lot of people at the top of funnel, but if the product doesn't align with what they expect, then it's going to be a very leaky bucket. A lot of people going to come in, they're going to kick the tires and then they're going to leave. So how can we get a higher qualified audience or how can we get a product that is more intuitive or that retains people better? My own personal journey has been very much backward integrating into.

Mike:

Nice. Yeah, I feel like every episode we recorders, I always go away with it and I'm like, okay, let me think about all that again. And then I started researching and digging deeper and I'm like, there's a lot of interesting stuff. And we're really just getting started and five years from now, if we had another episode and talked about what is DevRel going? We would have a very interesting conversation, probably very different to today. Definitely looking forward to it. Cool. So one thing we tried to do is use kind of at the end of the podcast to wrap up with a fun thing that you recently came across with, or somebody you want to give a shout out to, that really made your day in the last couple of weeks or so? Um, yeah anything top of mind that you want to share?

Shawn:

I wasn't prepared for this, but I guess I'll shout out to obsidian. So I think for me, my personal note taking system is very much very important to me in terms of having it as a second brain where I store all the thoughts that I had that are still working progress or data points on some essay that I'm writing, but it's not done yet. And I moved around a lot from simple note to one note to notion. And most recently I made the shift to obsidian and the way I decided on this is that I really wanted to bet on mark down. I think mark down is a format that's going to. Longer than any of us. And that I also wanted it to sync, to GitHub and to have a good mobile application and obsidian match all of those things. Plus it has an optional service to publish your notes so I can share what I am thinking as I think it, for people who really care about, finding out before I publish something on my blog. Obsidian is a really good note taking.

Pauline:

I was going to say that is really interesting that you shared that for this week because Mike I'll just go next. But the thing that I wanted to share this week is actually LogSeq which is similar to obsidian. I don't know if you've heard of it. I think it's created by the same people or someone had left obsidian team and then built it. I'm not actually sure of the background. But I have been using it for the past two months now. And it's my favorite note taking app, just because, I think in bullet points. And I sometimes feel overwhelmed when I used to use other note taking apps where I would write like a long block of notes and then I try to organize it, but it just all felt overwhelming. Whereas when I have bullet points at the start of when I'm taking notes, it just like sinking things into my head better. I don't know. No, it just makes sense for my workflow. And then every single day, I don't need to worry about organizing my notes. I can just when I open up the app tomorrow, I will have a fresh, clean slate and I can start I'm taking notes of my day. And again, it's become my second brain because then I can just scroll back down and be like, what did they do yesterday again? And then everything is in one place. So yeah, LogSeq is my shout out of the week actually. And it was just really interesting that you brought up obsidian. Cause I think they go hand in hand. Well, but yeah, over to you, Mike, what's your fun thing about.

Mike:

Well, you really put me in a tough spot because I feel like I need to talk about my note taking,

Pauline:

I genuinely have this prepared in my notes. I was like, this is what I'm going to talk about, which is why I was really interested in,

Mike:

oh, I'll take the Liberty to do two things. One is my note taking app, which is Reflect.App. Exactly the same concept. You get a little graph every day. It gives you a new empty note, you take your note, but same idea. Markdown, I guess, for the win. The other thing I did have in my notes though to share is I don't even know if I should share it because I literally just found out about it two days ago when I read the landing page, but I want to dive deeper into it. It's swim.io with double M. And what they're saying is that they sync your talks with your code. So it's more of like a documentation tool for code, it seems well, the screenshot looks interesting. Let's say that. So I'm going to dive into it, but I figured this, is it something that is literally just top of mind, for today's podcast then? Um, I figured

Shawn:

out what share that. Yeah, we actually a hand-rolled we had wrote something like this for our own docs. I don't know if it's a startup. I remember this one because, swim, they raised a pretty big series, a 30 million, and also it's coming out of Israel. So it's just like a really it's the market, this big come on. But, uh, Hey, you know, it's a hard problem and it helps developer experience.

Pauline:

We'll link everything that we mentioned from this episode in the show notes, but we have reached the end of the podcast. Oh my gosh time has flown by. Thank you so much, Shawn, for joining us today, I'm excited to share this episode with everyone. So many things to think about, and Mike said earlier, I actually edit these podcasts, so I listen to them, quite a few times over. Every time I listened to them, I'm like, wow, there's so many ideas here that we can take on for Gitpod, for community or whatever it is. I'm really excited to re-listen to this multiple times, take the best bits and then share it with everyone. So yeah. Just want to say thank you again.

Shawn:

Well, thanks for having me pleasure. I'm really excited that you guys are doing this because people are dying for more DevX content. Every time I post something about it. You know, how I feel about that mix now? And so every time I posted about it, I always feel like a bit of a mix of like, okay, like, this is interesting, but also I don't want it to define who I am, but I think it, yeah, it's definitely very valuable and people are very interested.

Pauline:

Yes, absolutely. Absolutely. I'm sure it's going to be an interesting lesson to a lot of people!

People on this episode

Head Shot

Christian Weichel

Host
Head Shot

Pauline Narvas

Co-host