tejas-and-friends-amanda-martin
===

[00:00:00] Welcome to PodRocket. PodRocket is the podcast from LogRocket. LogRocket helps software teams improve user experience with a session replay, error tracking, and product analytics. Try it free at logrocket. com today. I'm Tejas Kumar, and I'd love to welcome you to this episode where we chat with Amanda Martin.

Amanda is a dear friend. We've bumped into each other a number of conferences and is a talented engineer at Wix, but without me doing a lot of the intro, I'd just love to welcome Amanda and it. hi, Amanda. How are you?

Hi, Tejas, you've upgraded me. , I'm not an engineer at Wix. I'm not building Wix but I am a developer advocate for Wix. We do have a number of amazing and talented engineers.

I'm glad you made that clarification. I'm curious then, do dev advocates at Wix code? What does the, because DevRel is so new and emerging and different teams do it differently. What does that look like at Wix?

It's so funny, and I'm glad that you asked that because I feel like when I hear Twitter spaces or anything on, what is a developer advocate to because there's so much curiosity about it, I often don't relate to a lot of what people talk about [00:01:00] because my job I think is a bit different. It's not as focused on social media and that external content creation that we see a lot of folks in rel teams.

So we're positioned under marketing, which is fairly traditional, I think, in a lot of dev rel teams. And so I don't write code every single day. And when I do write code, I would say it's very simple. It's to either get somebody unstuck, or I notice a common question coming up in the community. I might make a short demo app about it, but it's very rare that I would build something complex.

I don't build RSVKs or anything like that, like maybe a developer. Relations engineer might, I don't write our documentation. We have an incredible docs team. So I collaborate with a lot of internal teams, but it's actually very rare I write code anymore. And I I feel complicated about that. I think as many in DevRel do.

That's interesting. So, I mean, It makes sense for Wix, right? Because Wix is a low code tool as, as far as I know. And, If , the less code you write, it's almost like a measure [00:02:00] of success of Wix, because its whole goal is to be this visual editor where you don't need to code as much. Is that accurate?

Yeah I would say so. You want to write only as much code as you need. Every time you write a line of code, that's something else you need to maintain. And if you think about the trade offs with a platform like Wix, you want to use as much of what they give you out of the box. That's the point, right?

And then you add code where it makes sense to add code, and you add as much or as little as you want. But one of the reasons that I end up writing, I would say maybe smaller JavaScript snippets and things to get people unstuck is because of the approachability of a platform like Wix, you get all kinds of people and all kinds of backgrounds coming.

And the people that need the most help are the people that perhaps do not have any kind of background in development. Maybe they're a designer and they've been building on Wix and they're like, I'm curious. I think I could, I think I could do a little bit of this myself. And then just getting, That's a huge box of worms.

You're like, Oh, maybe I could do a little bit of JavaScript. There's just never, it's never just a little bit. And then you start getting into it. It's overwhelming. It's such an [00:03:00] overwhelming world. And so when you come to a platform like Wix, and you're like, wow, this is so easy. Then you think, okay, writing code is going to be so easy on Wix.

And it's easy to get started. But writing code is its own thing. Different kind of thing, and it's huge, and it's very complicated, but so trying to help folks that are motivated and inspired say, okay there are some things you can do and help them be successful, whereas other folks that come to us that maybe are established engineers and are using Wix for something that's a useful.

Uh, Use case for it that makes their lives easier. Maybe it's a side project. Maybe they're trying to get a startup idea going more quickly, and they want to get their landing page and kind of their MVP up. They don't need as much help generally. The documentation's enough. The examples we have are enough.

And a lot of times when they have questions, it's about something that I'm going to really need somebody that Is deeply involved with our infrastructure or how the actual tool is built to come and speak with them. So then I'm a liaison versus the person that definitely knows the answer.

. So in so [00:04:00] many ways, I see how this is actually like legitimately being an advocate for the various kinds of developers that even use something like Wix, right? If we think about Other tools where we see developer advocates, places like Vercel or Netlify or SerialDB, there's a lot of these database companies that have developer advocates.

Those target developers are people who are just writing code every day, more or less. But for Wix, I can see how You're advocating for so many different kinds of developers. \ you mentioned there's people who create content. There's docs maintainers, there's engineers that build SDKs.

There's so many different functions in dev rel in, in your role as an advocate, I'm curious what do you do day to day if it's not for those overlapping functions?

So I'd say my primary focus is on the community. So being an active part of our discord servers, our forums, and working to support the community in whatever they need, whether they're having some problems, whether. It's just figuring out how to keep people engaged and excited and getting those connections together, [00:05:00] hosting office hours.

I'll be part of a, like a live stream tomorrow. That's going to be just answering different questions about Velo, which is the dev environment that we have on Wix. It's just JavaScript based for anybody listening that doesn't know what that is. Velo is a. Word apparently, I think that means bicycle in another language.

So if you search the word fellow, you might find like bicycle products depending, which is interesting to me. So it's it's a lot of community work and a lot of helping the product understand how people are building with Wix. What are they doing? What are they creating workarounds for? What's hard for people?

Where are docs lacking? And then where content is concerned, a lot of times I'll do Kind of ideation. Sometimes I'll be creating content, but most of the time we like to get the person that built the thing to be part of creating the content. So right now I'm working with our headless team on how to approach creating a video that.

You would want to watch and , how that can be approached and how to break them up, but [00:06:00] we're going to have the headless devs and the engineers actually do the recording and the scripting with my help, but they're the expert, they built headless, right? So they have all of that cool details in their head that I can perhaps do some more entry level, like getting into headless and come from just a user perspective.

But when you built the thing, then you have all these extra little tidbits in this fun stuff. And that's like. Why you want to watch a video, why you would go to the video versus the docs is you're getting all that, that cool, deep details that only the people that built the thing can do it. So a lot of times we try to put our engineers front and center when we can, especially if we're trying to get more of a behind the scenes about the product and we'll help them get over that hump of you can make a video and almost advocating for them to be like, no, you're the expert.

People want to hear from you and helping with that.

That I find really amazing. And I do want to emphasize and applaud what you said, because I feel like a big function. of DevRel is bidirectional. So like you said, you're supporting people, in the community, but you're also taking their feedback [00:07:00] back in and you're enabling the rest of your org to do what is typically associated with DevRel folks, right?

To do the work typically associated with DevRel folks, that is making videos, being the face of a feature and really enable it. I've been in DevRel for a few years and what I find is engineers, depending on the personality, typically, Struggle to communicate. And that's really what dev rel is.

So I, for example, I'm an engineer who also can talk about code pretty comfortably, but not everybody's the same. And most of the challenges that I face working with dev rel is. putting the spotlight on the really talented engineers that create the thing and enabling the engineers themselves, who are somewhat shy.

Most of the people I work with are like, Oh, I don't know if I'm the right person, and part of what I do is like, No, no, no, you are, believe me. And sometimes they still refuse, and at that point I say, Okay, then come on a podcast, and we'll both do it. And that's like a, I don't want to say gateway drug, but it then helps them become a little bit more comfortable.

Is that, do you have similar experience with that type

Very similar. Yeah. And again, and I think this is where I think some of the, what we see, like maybe on Twitter [00:08:00] or anywhere about dev rel is not necessarily true. Yeah. I can be the face. I can make the video. If all of our engineers that built headless were like, I'm so uncomfortable. I'd be like, all right, let's work together.

You're the expert. So I'm going to, I'm going to build, I'm going to play, and I'm going to have a lot of questions for you and I'll come up with the content and I'm happy to do it. But again I feel like. There's this idea that the developer advocate is always going to be like, the face of the product.

But I find that a lot of my work is yeah. Hyping up the engineers be like, no, they want to hear from you. And then, yeah, I'm here for you. If you need me, how can I support this effort? , I've had people that just don't even know where to start to create essentially an outline of how the content should flow.

So maybe I'll start the content and just be like, okay, you fill in your expertise in these areas. Let's build the content together. And let them record it though, if they're comfortable. Or if I'm doing like, I know there's a webinar we'd like to do for the community. If we have a new feature come out, a new API, something that's going to be a little harder for them to.

Get conceptual. I'm like let's do it together. Like you come to answer the questions. I won't be able to answer, but I'll introduce the [00:09:00] topic. We'll show some demos. We'll go back and forth. Maybe we'll code, maybe we won't, but it's yeah, being that support. so yeah, You're advocating for your engineers to have a voice.

To and you're advocating for the people using your product, at least in my experience. So less often am I like, I am going to be the face of this content. I'm happy to do it, but I almost feel like it's almost more efficient if I can just support the person who already. Has all of that information in their brain, more so than me.

It'll take me longer.

yeah. A lot of the work is I feel like it's trying to understand how do you unlock people's communication abilities, right? So you mentioned being really active in discord and other places where the users hang out. And receiving, user feedback and taking it to the engineers. I assume a lot of the feedback you get is qualitative.

It's this quality of Wix affects me this way, and I wish this was different, or I'm struggling with that, etc. How do you balance then, and rather, how do the engineers, receive qualitative feedback, and is there more of a [00:10:00] desire for quantitative? Sort of like, 20 percent of our users are complaining about this thing, and how does Discord activity translate into Product direction.

Yeah. And that's, it's hard discord. Like it's hard to track because we don't know if you come to say our forum, we know who you are in our system as a Wix user. We know how many sites you've built, how long you've been with us, things like that. Like we can access that kind of customer information, but discord is anonymous, right?

I know some of the users just from knowing them for a long time and chatting with them, and I know who they are, I know what they build, we have a relationship, but sometimes you'll get this information like, this thing sucks for me, and I hate it, and I have no idea who you are, how long you've been building with us, if, I don't know your level too, because I get, with Wix, it's, you have such a wide range from Writing their first line of JavaScript ever in their life to, I've been doing this for 20 years.

Don't tell me anything. I know everything. So I also don't know your level too. And so where you're coming at me with this problem or feature that you absolutely need, so as far as. It's [00:11:00] getting the information to the different teams. Every team functions very independently. Of course, it allows them to move quickly to run their teams the way they want to as far as getting features out or whatever APIs or whatever product they own.

So they're all moving very independently. So we do have one place that we put all of the feedback as individual lines, of course. So then from there you can take that BI and say, okay well, let's look and see. Go through and see how many people mentioned this API, mentioned this issue. If it's a team, because the other part of DevRel is building relationships with the internal teams, especially a company as large as Wix.

There are still people and engineers that are building things that I've probably never talked to and don't know I exist and what I do there. Because it's just... So it's such a big company, but some of the teams I'm quite close to, I talk to on a regular basis for them, in addition to recording in our system that we try to track it in and get that more quantitative data to say how many people need this thing or are having this problem.

And for some of the other teams, I'll have, I'll also have a conversation and be like, Oh, Hey, I was [00:12:00] talking to this one user and this came up and I think it's really cool and look what they're doing. And so I might also just go straight to that PM or that dev that's building that thing. Cause I just know they like to maybe talk about it.

want to be able to necessarily talk to the actual users like, Oh, let's set up an actual interview. We want to go deeper with this person because what they're talking about is very, it's very interesting to us. So it depends a lot on the different teams, but we still also do funnel all that information into one place.

So you can have some kind of BI around it as well. And then for the users, of course, there's a front facing like, request the feature voting thing. So then you can also see how many people have clicked, like , we want that feature and I think that's like on our product roadmap, which were.

We have as well working on making things very transparent about what's coming. And that's been a work in progress, getting it more robust. Cause again, when you have every team kind of functioning independently in some ways, making sure everybody's updating what are you guys working on?

What's coming down the road? So that any users that come to us, any developers are like, Oh, okay. I know exactly what they're [00:13:00] building and where they're heading and where they're putting a lot of effort right now and whether or not that's relevant to their business.

Interesting. Is that roadmap thing? Do y'all use some external servers for that? Or is that an in house sort of tool that

It's probably in house, we tend to start, I don't know that specific site, but I know it is built on Wix, the site, so I'm going to assume it's connected to also an in house product. Sometimes we go externally, but we do like to build a lot on our own products which I think is super important for a brand and a tool like Wix to show the abilities of what is actually possible.

So that's very interesting for me to see even how complicated you can build on Wix if you want to, like our entire internal employee portal is all built on Wix and it's, huge enterprise level, kind of tons of people accessing and using this portal all the time.

So I do believe that is, but then like our forum we did originally have on Wix. But the forum is not, I'd say a primary product for us. There's a forum that you can stick on a [00:14:00] Wix site and it has some APIs, but for the level of forum we wanted to give to our users decided to go third party as opposed to spending more dev resources, getting all of the features we needed for it.

As it's not like a primary product for our users. So we like we use discourse for that.

We're almost about to wrap up and I appreciate, thank you so much for the insights on DevRel at Wix. I think there's a lot of things people can learn here about DevRel and taking qualitative and quantitative feedback back to their teams.

And so on. But if we step outside of Wix for a moment you've been pretty active in the open source world. You're an advocate for Wix, but you're also an advocate for open source from what I can see. I'm curious if you could speak to that in terms of the products or the projects you maintain and what helps you move fast as a maintainer and not just move fast and break things, but move fast safely.

Yeah. Actually a year ago this month, I've touched open source before, but I like first had met Eddie jowled for anybody listening and meeting him. I was very, I was talking to a bit about [00:15:00] open source and why I'd never really dived into being part of the community, but that by.

Becoming a developer advocate. I had a lot of just that nervousness that I'm gonna forget how to build things quite honestly, because I won't be building every day anymore. And then, of course, I'm as Eddie's energy level will just suck you right on in and between meeting him and Sarah.

And I was like, this sounds like such a welcoming place. I'm gonna I'm gonna get into it. So I yeah. Started to make my first contributions in, I believe it was link free at the time, which is now called BioDrop, which is the main repository that the EdiHub community works on. And I just really enjoyed building with everybody.

And it's a fairly at least the parts of it I touch are fairly simple to me as you're, it's like a react and next application and they're using Mongo on the back end right now and there's some other things in there too, but I was like, okay I know how to, I know how to do this. Like I can get involved with this and actually do it in my free time, which leads to What I had to work on as a balance. At first, of course, I was contributing all the time. I was very excited. I was hanging out in the community. I joined [00:16:00] several communities and I realized, okay, this is too much. I was very excited about it. So I paired back, stayed just with Eddie hub and was, and eventually was invited to be a maintainer and more recently a moderator within the discord server as well.

And. I just really enjoy getting my hands into a technology that I no longer use every day anymore. And so I get to touch React or review React PRs and see what people are talking about. Because I don't need that for Wix development right now. Who knows for the future, but so it allowed me to stay up to date and to be balanced and be able to review PRs and be able to say, okay, if I'm going to be a maintainer and take on this.

Responsibility to the community that I show up for them as much as I can. And working full time, that, that is hard. So one of my favorite things that I love to use that is in all the repos in Eddie hub and there's, like I said, bio drop, there's a, like a landing page repository for kind of the main Eddie hub portal.

There's a live map that's for showing contributions [00:17:00] during a live stream, and there's some other things on there as well, but the main and most busy repo is bio drop. So for me that, so a lot of PRs can come in, a lot of new issues, things like that. And the best tool that I think is available for me as a maintainer is Gitpod.

And I can just review a PR in there so quickly, bring in the code, run it up. It's just, one of these cloud based environments. I don't have to get Docker set up and make sure that everything's like up to date on my computer. In my environment, which is more time consuming, especially if maybe I'm only going to review one PR it's one off.

I don't feel like going through and figuring out how far behind my version of the repo got since last time I touched it, I can just spin it up, pull in the person's code, review their PR very quickly. And provide value back to the developers that are coming into the community without taking a whole lot of time to get my environment up to date if it's out of date, which happens very quickly in a repo that's very active.

Interesting. Gitpod. I've never, I've, I know the company, I've never actually [00:18:00] used their product and now I'm eager to try it out.

Yeah, I really enjoy it. I had never used it before joining the ID Hub community either. So at first I was like, what is this? How does this work? And I just, it's my go to environment for working in with that open source community now. Now, if I want to build a feature I was helping them The maybe at the end of last week, we were building something together for that.

I'm going to go into VS code. I'm going to go locally. I'm going to go to for to my regular tools and environment, but for, especially for PR reviews, I just love get pods so much for that.

interesting. Is it built with Next. js and the app router or is it the page's router?

Let's, I don't believe we've migrated bio drop to the app router yet. It was page it, it is pages for now, but the newest repo that they just started on Friday for the. Like eddy hub, that's going to have the landing page and the newsletter and everything that's using the latest.

So that's the app directory. So we'll see how that goes. We didn't, we decided against putting TypeScript into that project because there isn't going to be really a use for it. But they do want to and hopefully I'm not calling Eddie out here because I don't know [00:19:00] when this will happen. But I know there's been a lot of talk of migrating BioDrop to TypeScript, which it's not right now.

And, but it's gotten big enough. It really. It could really use it.

Awesome. Great. I'm curious. We're just... Arriving at the end here. I wanted to get a hot take of yours on something on web.

I think, to be frank, I actually got one with with your take on not all projects need TypeScript. I was like 

that is one of my hot takes

My actual I think my biggest hot take right now and it goes around and i'm I wouldn't call myself any deep expert in any one technology I'm, definitely more of a generalist so I don't really have a technology based hot take but my biggest hot take and I think it comes up occasionally especially when you're in the social media world is like Wherever you are right now is good.

Whatever you're building with is good Any place you are is good. Just keep building, enjoying tech. You don't, everything that comes out, comes and goes, things like that, do what's working for you and you're doing a great job, whoever you are out there building, I [00:20:00] think there's a lot of stress in learning and a lot of stress in newer devs to be up to date on every little thing and end every little hot take that comes out and just like wherever you are is fine.

I get recruiters that still reach out to me that desperately in need of. net developers, and I haven't touched it. In so long, and if they even looked at my resume, they would never ask me to even consider building. But I think there's just so many things out there that aren't necessarily the flashy topic.

And if you're good at that, and you're good at solving problems and explaining why you're choosing to think about the tech you are and build in it, like you're doing a great job. Don't worry.

I love that so much and because it gives me a lot of comfort, because my website still uses the pages directory of Next. js, I'm, I'm happy that it yeah and, I was just recently playing the new Spider Man game on PlayStation, and there's this similar, one of the leading figures gives advice to a new person who said and I love what they say if you have a silly question, and you're scared of asking it just ask it anyway, and the people who judge [00:21:00] you are the people who aren't important.

And I was like, whoa, all that to say no one important will judge you. And I think that's a really great

Yes. Yeah. Don't get scared. I feel like it's easy to get wrapped up in what's going on. So my hot take is don't worry about the hot takes. Just keep building.

message. Fantastic. With that, Amanda, it's been such a pleasure having you on the show. Thank you so much for coming on and teaching us about all things DevRel and open source and awesome, encouraging hot take at the end. It's been a pleasure having you on the podcast.

Thank you. Thank you for having me.