Supper Club × Developer Experience with Shawn Wang

I sure hope you're hungry.

Oh, I'm starving.

Wash those hands, pull up a chair, and secure that feed bag, because it's time to listen to Scott Tolinski and Wes Bos attempt to use human language to converse with and pick the brains of other developers. I thought there was gonna be food, so buckle up and grab that old handle because this ride is going to get wild.

This is the Syntax supper club.

Welcome to Syntax. This is the Syntax supper club.

And today, We're gonna be talking about DX, and I'm not talking about degeneration x. I'm talking about developer experience with Sean Wang here, and we're gonna be talking all about Sean's new project as well as just developer experience in general, what the heck it is, why you should care about it, and just the overview, and we'll Get into some deep dive on some interesting stuff here. My name is Scott Talinski. I'm a developer from Denver. And with me, as always, is Wes Bos.

It's funny. Looking at the the or the the calendar invite for this, I was like, Sean Wang. Oh, Swix.

Yeah. Yeah. Your your screen name is so well known.

Like, it surpassed your actual name.

Yeah. That isn't that that's that's interesting. This episode So this sponsored by 2 amazing sponsors, Hasura and LogRocket.

Hasura is an amazing service to get a GraphQL, a GraphQL API spun up in just about no time with all sorts of excellent handy features and a Ton of really great performance stuff as well as LogRocket, which is the perfect place to see all of your errors and exceptions happen.

Alright.

Sean,

What's up? How are you doing? I'm doing very good. I've been a longtime listener, so this is a dream come true for me. Nice. Do you want to give a little background

about who you are, what you're doing, and, how you gained so many followers on Twitter so fast?

Jeez. Yeah. I'm not sure that's a good sign, to be honest.

So I'm Sean, also known as Swyx.

Those are my initials in case anyone was wondering. And I just like it just because there tend to be other Shawn's, but there's only One other company named Swix, and, it's it's actually like a publicly listed German telco. And so my and they they own swix.com as the FDIO.

And so my my joke is either I'll buy them or they or vice versa. Yeah. Right? Yeah. Nice.

Yeah. As somebody whose last name is Talinsky, The I I really appreciate that you have a nice and easy digestible, handle to to for people to latch on to. Yeah. Right. Exactly.

So yeah. May I I'm originally from Singapore. Shout out to any Singaporeans that are listening.

I moved over to the US for college and did my 1st career in finance Where I did, investment banking and hedge funds. We can always talk about money and and, that wonderful world as well if you're interested.

But then I basically burned out with the finance part, and I really liked, I picked up coding along the side and really wanted to get into that. So I did a career switch at age 30 Using feed code camp and then, taking a JavaScript boot camp as well.

Also just taking a bunch of Wes Wes' courses.

So I had And and this was round about the time that you guys are starting syntax as well. So, like, I definitely remember, you know, sort of cramming my some nights and weekend Feed code cam crashes while listening to you guys. So this is, this is a kind of full circle for me, to be honest.

And, yeah. That that transition to JavaScript like, I had done a bit of Python, a bit of Haskell in in previous jobs.

But JavaScript was the hardest language to learn by far just because it was so There's so much incompatibility and so much confusion between frameworks and, this is the roundabout the transition to ES 6 as well. So there's just a lot of confusion as to like, what is the best practice and what should I learn? So you, I think, you know, Resources like syntax definitely help us help people figure out, like, what the state of the nation is, you know. And I I think that's definitely something that you see me Try to do as well as a service to others. Heck, yeah.

I I I graduated, in New York and and I was a front end engineer at 2 Sigma, which is a well known sort of QuantEdge 1 in New York.

And then was the 2nd definitions higher in Netlify? That's where a lot of people know me for from because I started speaking as well. So I think that's part of The hack, if if it can be called a hack, which is get paid to speak and write. And therefore, you'll you'll start to grow your own personal following as well as, as part of your job.

After Netlify, I went to AWS and basically was a developer advocate for the AWS stack. And it was Amplify working with Netter Dabit, Who a lot of people in the React ecosystem are gonna know.

And then I've I, was very interested in sort of long running jobs because I felt like That was one part of serverless, the serverless ecosystem that was not well handled. So I wrote a blog post and that blog post eventually got me a job at Temporal as, hit a developer experience there. So that's, and and then finally, I just recently joined, Airbyte as also as head of developer experience in the data engineering field.

So that's so basically, the past 5 years, I've had some form of title of developer experience in my role. At Netlify, we called it Developer experience engineer and Sarah Jastner, our our VP of developer experience, sort of defined that role for us. And and I thought there was Definitely a category defining role that was a sort of early a little bit early before its time, but now it's becoming a very hot topic. Nice. Yeah. We really need to get Sarah on the show. I'll have to We have had her on once before, but her back on? Sarah

no. We haven't. No. No. We've never had her on the show.

Oh, you know what? We had her scheduled on, and

yeah. She had never had been. No. Reschedule, and we have not made that happen. So now now that we're doing Regular schedule interviews. Yeah. We'll get her back on the show, especially because I think her her book is, you know, in in preorder and stuff so we can have around to talk about some of that stuff. Cool. So developer experience, is a word that, developers kinda hear around. Right? You hear DX or developer experience around. What what's your what's your, like, plain English Description for what the heck developer experience is.

Well, the the cheesy shortcut is that it's user experience for developers, But I find that that is not super useful for people who are trying to figure out, like, what translates and what doesn't. Mhmm.

So I I think basically, developer experience is everything that tries to bridge the gap between the code and the human.

And I really like the talk that was given in 2017 by Cheng Lu, who was a part of the VX core team and then moved to the reason core team, where he called, we call it like, you know, there's there's there's there's the code base which is the code that actually runs on the machine. But in order to make that Code usable. You need documentation, you need, blog posts, you need tutorials, you need workshops, and all the way up to podcasts.

It's meta stuff around the code That helps make the code more consumable. And I think that's essentially what developer experience is. It's kind of that the glue layer between

The code and the human. Is that talk, by any chance, called on the spectrum of abstraction?

Is is that you would does that sound about right? You said it was taming the middle language is Taming the metalanguage. Okay. That's the one I want. You're right. Yeah. So the language being the the the code, and the metalanguage being the conversation about the code. Which is essentially Documentation and blog posts and speaking and writing, you know, all that all that good stuff, in in community. So, you know, I do have, like, a mental model how I organize the World Breakthroughs.

But, probably what one thing to note right off the bat is that it's a it's a very, very trendy buzzword and therefore, there are a bunch of people claiming, this term. And so there there are 2 camps. The first camp is sort of internal DX and and the 2nd camp is external DX. And I grew up within the sort of external DX side of things. So what is what does this mean? So internal DX is trying to improve the productivity of developers at your own company An external would be trying to basically working at a developer tool company trying to improve products video developers outside to in other companies.

And I think that would be my primary division there. So a lot of people

would be in one of those 2 organizations and not be aware of the other. Interesting. So So would you define, like, a a tool like Versus Code? Right? It's our text editor that a lot of people use. Is that Versus Code considered like, the tools within Versus Code, is that considered External

DX, if I'm getting this correct, or is that is that way off? The v s code itself is a product. It's it's something that you it's It's neither. So I I I would consider it neither.

The activities that you do around that can be sort of internal evangelism or external.

And that's where the division starts to melt a little bit. Right? So I think there's always when you we start investigating something, you start to see the divisions and then you start to see the similarities across all of them. So, Versus Code is definitely one of those where, like, yes, it probably improves the productivity of people at Microsoft, but it's products managed like a like Like a like an actual product for the the general sort of, Microsoft mindshare of the developer community, and, it's been one of the most successful ones at that. Cool. Let's talk about why is d x important. Like, if you

maybe let's start talking about, like, Internally to a product team. I have a buddy of mine who just just asked about that. So he's working on a new team at at a company, and they're really trying to double down on DX. Like like, why would they do that for their their own developers? Why is that important? Yeah. But honestly, because developer time is expensive.

Based on the math, if you have 50 engineers And you think it's possible to improve their productivity by 1% a quarter? Then you basically should have 1 to 2 engineers who are full time not working on the product. They just focus on making everyone else more productive because just mathematically, that just makes sense. And if you think about A lot of the repetitive stuff or the sort of infrastructural stuff that you always worry about, like and but you never have time to do, Having someone specialize in that and take, and and try to deliver that internally as a service, I think is extremely valuable. And that that Obviously makes sense when you have a 50 person company but, you know, scale that up to a 1,000 person company and now you have a whole developer experience organization within your Within your firm. The way to think about where you can improve your productivity, there are a bunch of different places to do that. My favorite model is the Netflix productivity engineering model. That is the name of their team that that they talk about on the Front End Happy Hour podcast, Which is essentially there are 3 major components. Right? Think about going from new hire to productive local dev, which is sort of the boot camp and onboarding and bootstrapping tool. And then from local dev to production, which is sort of their build, bake, and deploy paved role, like, kind of like the CICD and and, sort of deployment platform. Then for production, back to dev. So it's like telemetry and, observability.

So I think that's a really nice mental model to think about. Right? What are the long Running dev loops there, what what are we doing a lot of manually just because no one's really thought about, automating it or making it more efficient?

And you can probably see a lot of opportunities to improve. Yeah. Okay. So I I I think that's spawned a couple of things for me. And one thing that, you know, kinda stuck out was, like, we're talking about, like, production hours, productivity, across, You know, large organizations with a lot a lot of engineers. Is this a is this a problem that is mostly found in large organizations, or is this something that just kind It exponentially scales with, the amount of developers

that you're working with. I do think it scales up And it starts to become really serious money with larger organizations.

But even on a single person team, like, obviously, there's There's that x k c v chart that's super famous about how much time are you spending in doing something individually versus automating it and and where that trade off matters. And I think there's some part of, like, okay, being able being able to make that trade off in, for yourself or for your small team. But also A lot of what developer experience and developer tools do is they move the boundary of what becomes a feasible trade off and what is not. And I think I think expanding the possibility of, like, what is, You know, what what what that boundary is, I think is is super useful. So I'll give I'll give one very very relatable example which is the move From React being a custom built, app every single time in sort of the pre 2016 era, to create React app, Well, you can just run 1 command and you had to react out. That was probably the single biggest developer experience upgrade, in the history of React.

And that was just 1 person, like, It's it's Danny Bernalvan, Christopher Chanel, like just hacking on it on one one day and then releasing it to, the broader v f community. And Everyone's in productivity just massively improved by by that. So, like, I I thought it was a Yeah. Yeah. It's yeah. It's a big difference. I mean, it's, you know, It's now a little bit old hat just because time has passed and, trends have moved on. But I I still think about that often is is like how how can you find that one wedge by which you can drive products with you because everyone is doing the same thing over and over and over again, and you really don't have to.

You think Versal is probably one of the top leaders in that area of of DX, just like all of their products is just like, oh, man. Like, I feel like, Guillermo and all the people that work at Vercel are all like, this should be easier or this should be more enjoyable to use. And, I just wanted to, like there's lots of companies that do this type of stuff, but I feel like their stuff is just like they go they are aggressively DX in terms of, like, How can this be as easy and as enjoyable to work on? Yeah. Yeah. The the term that they started adopting for it is they call it building an SDK for the web,

which It's like, okay, like, what are you talking about? The web has standard APIs. Why why do you need an SDK for it? What's inside you do? For for a lot of small things and especially when, the bar for what a good website is keeps getting moved by Google, they conveniently have very good relationships with Google to Yeah. Right. Yeah. To help you, to reach those, things. But you kinda need it, you know, as as a developer with, like, way too much going on. Like, You just need a production ready web framework, and it turns out Next. Js is, by far the the most well developed, one out of out of all of them. I will say the other thing that NextEase does well, but, about DX is they don't give you too much too many integration points. And that's something that, you know, I found, for example, comparing Next JS with Gatsby.

The the API surface area is small, Just like React's API surface area is small. And I think that design philosophy of parsimony, which is not too much, not too little, just giving you enough building blocks to express The 90% of use cases that you that you really wanna do, that's good enough because, most people are don't have that complicated of needs, and they they need a paved path to, to to figure things out. And they they they need to know they need to not learn, like, a whole universe of APIs just to get Stuffed up. Parsimony.

That's can we can we talk about parsimony for a second? That's a good word. Oh, it's a it's a beautiful word. I have never Used that word before? It comes from my statistical training. So parsimony

in statistical models and machine learning is all about trying to Balance the trade off between overfitting a curve because, like, if you want to make a predictive model, you you want to the. You're just naturally gonna get more and more of a fit the more variables you throw at it. But the more you do that, the more you're gonna overfit and, actually just model something that doesn't that isn't really there in the data. So parsimony is this kind of rule that like if This additional dataset, if this additional data coin doesn't really add that much then just throw it out. Even though it technically improves your overall, fit to the to the to the the dataset, like it's not really carrying its weight. And that's kind of what I think about when in terms of API design as well. Like, when it when you wanna keep a small API surface area, you should have proximity in your sort of design principles. Man, that's it it

Kinda sounds like, to me, like a type of fruit tea I would get. Mhmm. Go to the boba tea shop and get some parsimony

parsimony tea. Or is it maybe

yes. It kinda seems like a lot of this is just about productivity.

Is productivity, like, the main focus, Or is there, you know, I kind of border between, like, we have these ideas of, you know, you have to be super of all the time and here are these things to make us more productive.

But there's also, like, to me, I guess, an aspect of, like, joy in what you're doing to have it be easy.

Did does do you think it fall follows,

like, pretty much into productivity, or or is this much larger than that? I think productivity is the base, Like it's the economic layer of reasoning. If, like, you would need to explain to the bean counters, that's the thing that makes sense to them. But really as creators, what we care about is Creativity is is about that staying in flow.

And whenever you have a process that takes you out of flow, you start to get distracted and you start to lose your, connection with the problem, and it's and you start to lose your, connection with the problem, and it starts to be very disruptive. So there there's a lot of sort of intangible cost that comes with Very slow dev cycles. I should also mention, by the way, that the other very popular mental model for breaking down developer productivity is the accelerate metrics, by Nicole Forsgren, and also known as the Dora Metrics for anyone, trying to look up, the the the the literature on this Literature on this. A Dora? Okay.

Yeah. Dora, d u r a. Oh, d u r. Oh, nice. Yeah. You know, we just got a a Dora the Explorer, toy for my my child, and they're, like, speaking Spanish already. So shout out to Dora the Explorer.

There's so little in software that Actually has good empirical research. So the reason that people really like the accelerated metrics is that they actually did the hard work of studying a bunch of, for engineering organizations. And this is backed by academic and empirical research. So, I really like promoting that as much as possible but it's also really hard because Who knows, like, what applies to a bunch of findings for a few 100 companies may not apply to you. Right? It's it's a social technical, thing rather than, like, a law of physics.

Okay. So, the the other thing sorry. I I kinda lost my Wait. I'm sorry. Yeah. I

I I I derailed this.

So so, the The other thing about productivity okay. We talked about productivity leading into creativity, right? The ability to play.

And probably the best, talk about this is Brent Victor's inventing on principle, where he showed you the effects of what happens when you reduce the distance between what you're writing, what you're quoting and you're seeing the results. Right. And and having that direct connection actually really helps you, appreciate, like, what the impact of your code is, when when you're playing directly and and having direct manipulation on your on your end result. For a lot of code, especially back end code, you can never have that. But Basically, every order of magnitude improvement in, your your latency, increases your productivity and play. And it unlocks a whole different set of use cases that you never really thought of before.

So I I I do like that mental model of, like, how can we Improve by orders of magnitude the the feedback loop. And then finally, I think it's this is very hard to document, but there are documented examples of people admitting to people like Gerge Oros Who is, who who's the author of the Pragmatic Engineer, the a really popular newsletter that's reporting on job trends in the industry.

They're like, you know, there's there's all talk about, like, the great resignation and like, you know, software engineer salaries, going up into the right. But really, the reason I left my company is just because I didn't feel productive. I hated the tooling that we have at our current company. So it's a retention tool.

Yeah. If you Right. You just hate your tools that that, like, the people that people that your company force you to use. You can leave anytime because there's a there's another company that with a better set of tools Out there. I gotta say, you know what? On a a side note, you know, I don't know how much we'll get into Svelte

on this podcast specifically, But we had a developer who whose salary was going to get doubled with the job offer he had received.

And he was like, I'm I'm sorry that, like, I you can't match your salary. I really don't want to leave your Svelte code base and go to work back and react again. I really don't want to, But I have to take this job, and I was thinking, like, alright. Our our code base is almost worth that kind of bump in a salary. It made it hard. Yeah. It made it hard. That somebody would prefer to To work in in not only our code base, but spelled specifically over it. Totally. Let's actually take a quick minute to talk about one of our sponsors, which is Hasura, which actually, fits really nicely into this conversation considering your kid about, making some of the pain points of getting a GraphQL API just That much more ironed out. In fact, Hesura is one of those things where they gave us a little quick demo. Wes and I got a nice little demo on some Hesura features, and and we were both Pretty shocked at just the ease in which, they were able to get all sorts of, multiple data sources, relations, authentication, all of these things. And, also, like, they they had emails Sending to us in a demo in just about a couple of couple of minutes. So it was all very fascinating to see just how quickly you can get stuff up and running. Well, Hasura is a cloud managed GraphQL service providing auto scaling and high high availability.

It gives A ton of nice little features so that you can do things like subscriptions with no effort to connects to, your data sources with ease, Whether that's a Postgres or any of the Postgres family of databases, and it auto generates your GraphQL API Right away, you can get started just with no time whatsoever, and you can have all of your services right there with you, GraphQL and or REST.

It's just a really great service, so check it out. What you wanna do is head on over to hasura.infoforward/ Free trial. The coupon code is try, and you'll get 3 months of Hasura cloud standard.

And only the first 100 people, who who signed up, get this offer? So give it a try, Hasura. I was actually just on Hasura's website today working on a a demo with my GraphQL library. So shout out to Hasura for making the process of having a GraphQL API that much easier. I wanna talk more about,

React, specifically so, like, you use are you a React developer? Right?

We saw you at Reactathon. You use React. Right? I I still I I'll still do I see the reaction time tonight. Yeah.

Oh, what what's your what's your framework of choice? Because, like, we're here we are talking about d x, and, like, let's talk about use effect for a second. You know? Like, what what's your thoughts on React?

Just Wes going right to the jugular.

Right for the jugular. I'm gonna be canceled here, but we're like okay. Well, I mean, we're a few minutes into the podcast, so only the true fans are here now. Yeah. Yeah. Right. So there if

If you have strong feelings about useEffect, you love it, please, now it's time to to leave. Step out of the room for a minute.

Well, no. I think I think the the React Community is very ready to move on. Even the the core team is ready ready to move on for useEffect.

So, my official stance is for sites and React for apps.

And that is not a very popular opinion among, people. But essentially, that is the right balance for me in terms of Productivity and, the ability to ship stuff quickly. So and that that's primarily the the thing that I care about. So React, you know, I and I've I was around for that, transition to to hooks, and hooks are the greatest thing to happen to React since React. The one thing that VX has always struggled with is that it tries to force the functional paradigm onto a fundamentally mutable and imperative, substrate, which is what Frutares calls it. Right? There is an impedance mismatch, and that was all shoveled under the hood in useEffect.

And unfortunately, that was something that people had to be forced to to use.

Maybe could have used a little bit more time to bake Because it turns out that, parts of it are not parts of the so those design design decisions, particularly the dependency array, We're not technically necessary. You could see Vue and Solid and other other frameworks sort of taking the the best of The hooks, design paradigm, but then avoid the dependency array, I think I think that's a very interesting phenomenon. But also, with use event, which is the new API that is being proposed by React, you can see some of that being avoided as well. So, I just think, like, it's a very interesting evolution.

I'm not I I I'm far from saying that I could have done any better, but I do think that it has probably Created a lot of foot guns by people. Yeah. And, the the people that, you know, write these super long blog posts about, like, how to deal with use effects and, you know, what the best practices are, You kind of miss the forest with the trees because there's a little bit of Stockholm syndrome with React where, like, I I I'm, like, sort of the consultant that, like, understands how to use these these APIs. Really, like, maybe you should they just shouldn't be that hard to use in Christmas. Yeah. Yeah. Yeah. I that's always been a good thing for me. Said. Yeah. It's like, why is it so easy

To have an infinite rerender, like, why is it so easy to do that, and why do people have to have that knowledge? Or Why is it so why why does it require so much effort to memoize things or have different I mean, now you have to have a different useEffect for if you're dealing with server side code. There's, like, so many little gotchas that probably have fueled, but, like, 20 probably fueled, like, a whole tutorial series from myself.

Like, but why do I have to do a 20 video tutorial series on this thing that that should be just a little bit easier for for the user? And, you know, I had that same feeling when I came to React in the 1st time because when I came from Angular one, 14 or something, I was thinking, like, why is this also hard When it was a little bit easier, albeit not as not as good. And then once you get used to react, you're like, oh, yeah. It's it's a little bit more difficult because of these following reasons, but you get these benefits out of it. And then, like you said, eventually, that kind of Stockholm syndrome mean, now now it's kind of been elaborated upon and invented upon. And now We have systems that have all the benefits but are easier.

So why are we using the harder one? Yeah. Yeah. Yeah. We have that a lot. We should do a whole show, Scott. Throw it on the books Of not necessarily just react. Like, I'm not going to keep them, but more just in general. Like, you know, the people Say these things like only animate, transform, and CSS. Like, why? Why can't you know, like, because it's more performing. Okay. Only, interfaces are faster than types in TypeScript, so use an interface. Why? You know, like like, why? Do it for me. Why? Do it for me. I don't wanna do it.

Do it for me. That's the name of the show. Already made made the card. Do it for me. Yep.

I hear you. Right.

Yeah. That that's a lot of, like, what developer experience is. Right? Like, so I have this sort of mental model of DX as starting from product, going out to docs, going out to blog posts and content and community,

at the at the the audible slayer. John, I gotta over I gotta interrupt you really quickly here. Yeah. You you transition directly into my next question without even seeing our notes here. So, please please continue as we talk about the radiating circles of DX, as you call it. Correct? Is that is that where you're going to? That's that was my next question, so I'm glad you went there. I'm just trying to respond to Wes' Discussion which is essentially

like you have to design for a pit of success. Like API design is really at the core. If you screw up the API design, no amount of good docs, No amount of good blog posts can really fix that. Right? Like at the end of the day, like if you've made actually, if you if you made a bad API design choice, Like, you actually cause a lot more load on your community, a lot more load on your on your documentation, in your, in your blog post just to make up for the fact that you made the wrong decision on the API design. And I'm also I'm not saying, like, you had use effects was wrong because they had they had other priorities at the time. But, like, a lot of API design and a lot of developer experience, Decision making is a lot about getting people to fall on the pit of success. And, that is a very famous blog post by Jeff Atwood,

who is the cofounder of Stack Overflow? I I it's funny because this kind of does fall also into another thing that Wes and I were just talking about earlier today. We just recorded an episode on Viewport Units.

And because of the decisions made with the original CSS viewport units, there was initially 4 viewport units, and we now have teen Viewport units. Sixteen different Viewport units.

So if the right API would have been chosen in the first or the, I guess, the, yeah, the right API, then We wouldn't be having to deal with what are the difference between 16 different Viewport units now.

Yeah. That totally greatly illustrates that. Well, so I would say that It's easy for people like us sitting on a podcast to criticize. Right? Totally. Like Yes. That that's the tricky thing. It's like, Oh, you know, with the new ones. Being able to fold a phone. You know? It's the best part about my job is that I can just I can just criticize it without having to deal with it. Yeah? Right. Yeah. So so, you know, the the people who work on these products, they'll they'll their response to you would be there's a fundamental complexity that cannot be erased. Right? That that is, that is the response there. And a lot of times when I I sit at the, at the intersection between users and the people working on the the core product, I have to basically trade those off and and try to convince people on either side that they made the right choice or to guide them towards something that the other side will accept.

And that is a fundamental tension in working in DX, which is, like, what part of fun what what part of your API design is essential complexity, to use a Fred Brooks Term and what part is accidental complexity and how much can be moved that accidental complexity away just by clever design.

And so some Some part of it, you can you can deal with, and some part of it, you just have to document a lot.

And that's what happened with Q4 units.

No matter how much you document things,

there'll always be something that goes wrong, and you'll probably hit some errors and exceptions. West, this is the first time that West gets Do a log rocket ad read. So I'm I'm interested to hear this. Oh, I haven't done them in a while. Scott usually takes them, but let me do one here. Log rocket. They do. We've heard a 1000000 times us talk about Log Rocket, and they have a JavaScript scrubbable replay. And we we generally frame it In the in the point of view where they're they're tracking, like, issues that happen on your thing. But you can use LogRocket for a little bit more than that. They're really kind of getting into this is that, since LogRocket does a great job at tracking what's going on on your website with your users, you can do, you can use LogRocket to drive Product adoption and engagement. So if you want to know, where are people dropping off on your website? Are people scrolling down Far enough to that point, are they clicking the right elements that you want? What like, 20% of the people aren't actually buying it.

Why? You know, like, what did they click and when did they when did they drop off? Is it when they saw they didn't they weren't able to see how much Shipping was before entering their email. I'm looking at you, Shopify. Stop doing that.

All kinds of information like that. You can drill down. You can create Funnels.

Basically, you wanna you wanna sell more stuff. You throw LogRocket on your website, and you can use that data to figure out, and convert, engage, and retain all of your customers. So we want you to check it out at logger rocket.comforward/ Syntax are gonna get you 14 days for free. Thank you, LogRocket, for sponsoring.

How was that, Scott?

Excellent. Just as Thank you.

It's very good. Okay. So we talked a little bit about is it internal DX? That's what that's what you refer to it as. Let's talk little bit about external DX. What's what's the difference here, and what are we, what are we getting into when we talk about external DX? Right. So

I think that is what is going on with developer relations in general, which is that people are rebranding themselves from just, glorify marketing arm to something that is a little bit more comprehensive, and I'll tell you why. I like, so, like, Part of this is just people trying to rebrand themselves into something grander. Right? Just as part of just general career progression. But it's real in the very real sense that I, as a developer advocate, Get to talk to people all the time and then get to fear feel their frustration.

And the best that I can do is write blog posts to try to solve it. Right. I can feed some I can feed some feedback back to the docs and to the product team, but I don't actually have any direct influence.

So in other words, the people who are most speaking to users the most, don't have have the least power to actually impact any, it it have any impact on the on the product that that fundamentally changes it.

And, I think this really drove drove it home for me when, you know, I realized like There's not a there's no single blog post that I can do that everyone will read, but everyone would probably read the docs. Right? So the people who who work on the docs And the people who work on the product just have way more impact, to the ultimate developer experience, than developer relations. And if I ever wanted to Solve something end to end for customers, then I should probably try to have more influence over something that's more core into the product.

So I think the smarter developer tools companies are reorganizing in recognition of that. For example, Netlify.

Now, docs and integrations report directly into the developer experience team.

And another interesting phenomenon that's happening with developer relations is that, they wanna keep them sharp as engineers. So with, with Netlify and and with, Airbyte, my current company, like, we'll spend We'll have our writers and our developer advocates spend a quarter of their time, like 3 months out of the year, working as engineers on the product.

So and I think Interesting. Yeah. That keeps them sharp as engineers, but also once they've worked on the the thing that they really, you know, really, really wanted to fix, they can go out and evangelize it. Yeah. That is it it is interesting because there are still some companies where the the DevRel position definitely feels Like like you said, it's an extension of the marketing arm. Right? They're they're just there to to connect. But, really, what we're we're trying to do here is get the developers who are using the thing to have a a little bit better understanding of it. And and I think there there's definitely a big difference

when The companies get that, I think, in terms of the what kind of output they're able to do. Yeah. And just to be clear, like, it's okay to be marketing. Right? Because traditional marketers are terrible at talking to developers.

So getting real developers to to talk to other developers is a win anyway. If you could just tell me what it is you do, It's a win.

Yeah. Totally.

And then just to round it out a little bit as to, like, what the cutting edge is in terms of developer experience.

A lot of, developer advocacy and dev relations is one to many. Like you're broadcasting as much as possible trying to, be that sort of That person that, goes to every conference or writes, writes a blog post that goes to Shopify Hacker News. But really, I think what people are finding is more scalable is, many to many conversations which is building community, and having people find each other and do local meet ups and, and solve Solve problems that way and and build a whole ecosystem around your products. So I think that is something that I'm personally very interested in, and that's why I I have side projects like building small society. Yeah. Yeah. Look. I love that. Do okay.

So one of the the pillars of of your career kind of has been this learning in public thing that you've been doing. Right? Yeah. Where you're often sharing what you're learning. You're you're posting a lot. You're you're not only just posting Helper blog posts here and there, but, like, really letting people know what what you're learning.

Is that something you recommend for a lot of developers, or Is it does it take a a special kind of person to do that type of learning in public?

I definitely don't Say that it is suitable for everybody, because it does take some time and some people are more vulnerable than others, and they should take necessary precautions.

By for every type of profile or background, I can point to people who successfully learn in public. And I think it benefits your career so much that it is worth it to at least try.

So it's definitely something that I have benefited from, You know, for for what for what is what if it's not my idea, you know, like, I got it from Kelsey Hightower and the earliest incidents that I can find Yeah. Is people who wrote about learning in public, at NASA, back in the early 2000.

So you might as well learn how rocket science learned, which is share what you learn and get corrected, and if you Whatever you get wrong, you you'll remember it for life because people will crawl over broken glass to fix you to to correct you. Yeah. Absolutely. Yeah. I I think we all know about that. Yeah. And I think, you know, you guys as developers, like, you know, doing this podcast, like, I'm sure every time you get something wrong, you'll hear about it. Right? And And that feedback loop is so is so solid because,