I'm excited to welcome back to Developer Tea today, Allie Spittel. Allie is a Senior Developer Advocate at AWS. She's also the co-host of the Ladybug podcast. She's a blogger, and she's been on this show before. Go and check out what Allie is doing. You can follow her on Twitter. That's where most people are following her. Her Twitter handle is aspittel. I want to take a moment to invite you to join our Discord community as well. You can head over to developertea.com slash discord. Other engineers like you who are looking for answers are in that Discord. You don't have to be an engineer to join. In fact, there are no qualifications other than just following the basic rules. Decency is really all we care about. I really want to engage with people who are looking to improve in their careers, who are looking to think on a better level. That's the whole goal of that Discord community. That's developertea.com slash discord. Thank you so much for listening to the show. Let's get straight into the interview with Allie Spittel. Allie, welcome back to the show. Thank you so much for having me. Last time we talked, as we were just discussing beforehand, I think you were at DevCon. Dev too. It was around the time that you had either joined or you were about to leave. I can't remember exactly when you talked. As you were saying, dates are hard. I don't even know how long ago it was. It could be eight months ago or it could be three years ago. I really don't know what that was. It all blends together, especially in COVID time. I keep putting my dog's birthday wrong down on things because she's two and a half. I keep saying that she was born in 2020. She was not. Yeah. I did the same thing except with my human daughter. So I understand. I guess she was born in 2019. Well, now. She was born in 2019, and I continuously can't remember because the time is just so strange. Yeah. It's wild. It's wild. Yeah. So I guess working at Dev was almost two years ago now. Oh, wow. Okay. So it's been a while. Since we've chatted. Just because I'm going to drive somebody crazy if I don't look this up. I'm going to go back and look up exactly when you were on Developer Tea. So I'm Googling right now in the background. And it looks like it was. Oh, man. Hold on. Oh, we don't have the date. We don't have the date. I'm going to have to take that down as a reminder. I need to put the date on the episodes. This is in. Oh, I don't have it. There's no date on the feed either. Okay. Well, we'll figure it out. Anyway, welcome back to the show. I'd love to have you kind of give a quick review of what has happened in the apparently two-ish years since we spoke last. Yeah. So for about a year of that time, maybe a little bit more than that, I went back to teaching full time at General Assembly, which is a coding boot camp. So I had a ton of fun. I had a ton of fun. I had a ton of fun. I had a ton of fun. I had a ton of fun. I had a ton of fun. I had a ton of fun. I had a ton of fun. I had a ton of fun. I had a ton of fun. I had a ton of fun. I had a bunch of people to code and bringing them into the industry, which I think is a lot of fun and like a really different but awesome role. And then I have been working up creating content and kind of scaling that up, playing around with different formats. And then most recently, I just started at AWS this summer where I'm going to be doing or where I am doing developer advocacy specifically on the AWS. And then I have been working at AWS Amplify team where we make products tailored towards front end and mobile developers. That sounds like a full couple of years. As I've found out now, it's actually March 2019 is when our last interview aired. So a couple of years now. Yeah, it was like almost exactly a year before the United States really kind of started taking the pandemic at least somewhat seriously. So it feels like four years ago in my head. Yeah. It does. It does. So developer advocacy. This is something that I think a lot of engineers hear. And there's some pre kind of preconceptions of what this is. All right. So I'm going to lay out some of the preconceptions from my kind of heuristics, my mental models of what developer advocacy would be. The first preconception I have is that it happens only as a job in big companies, which obviously, Amazon. AWS is a fairly big company. I don't know if anybody's heard of it. But then also that there's kind of this preconceived notion that developer advocacy, that it's engineers who or it's not necessarily even engineers who have to work in this role, although it can be helpful. But that because it's more like a community outreach. Position rather than an actual like, you're not actually working on code day to day. Am I right or wrong about those two things? And in what ways would you fix my preconceived notions? Oh, super interesting. So I think developer advocacy can work at almost any level with a company. Dev2 was kind of a developer advocate there, too. And I think it was hire number seven. So really early on in their startup kind of journey there. But then AWS. Yeah. AWS is much, much, much bigger and have the same sort of role there as well. So I think it can work at any scale. But I think that it really helps if you're working on developer tooling, something that developers will use as part of their jobs. As far as writing code. So developer advocacy, in my experience, is a totally different job at different companies. And I think that's fascinating. At some places, it falls much more under market. And so you'll be working more in that type of realm. Whereas what I do at AWS, I work on a product team. And so my job is to write a lot of code with our tools so that I know it really in depth, but also so that people have demos that they can use when they're building their own projects. There's some awareness in there in kind of marketing. But it's a little bit more community focused and a little bit more focused on education and getting feedback from the customers or the users in response. So if somebody uses Amplify, what are the parts that they struggled with? What are the things that were really great for them? What are the features that they want to see in the future? And then bubble that back up to the product team and use GitHub issues or Slack messages or conversations and meetings about what our customers really want to see. And how we can make the best possible product for them. So I see it as kind of this middle ground between being a software engineer. I was that for a lot of years. And then a little bit of marketing in that there is some awareness building, especially when you have a relatively large audience on the internet. And then the third part of it is product and informing what will be the best decisions for the product in the future. This is interesting. And it reminds me of another... kind of similar role, although it's less to do with developer advocacy in this particular role that I'm talking about and more to do with kind of trying to connect those. And I guess in this case, your customers are engineers, or at least your end users are engineers, ostensibly at least. So the role that I'm thinking about is a customer success engineer role, which is different. In a couple of ways. One being that you're probably in a customer success engineer role. You're probably not keeping your finger on the pulse of the GitHub issues or PRs that people are opening. And you're more keeping your finger on the pulse of what's going on with the business problems or the customer issues that are hard to solve that aren't being solved by the average documentation page. But there is some interesting overlap here in that you seem to be in this role, where you're kind of in the role of a bridge, where it's kind of hard to bridge from the community of engineers to the engineers that are building the thing that the community is using. That's a hard bridge to make. And then also from that community of engineers who are using the thing to the product people who are responsible for deciding the product roadmap, for example, if you use roadmaps. So it seems like it's a bridge position. And in that particular regard, I promise I have a point. How does this relate to, say, like a management role? How would you contrast those two kinds of roles? Yeah, that's a really great question. I think there are so many similar type roles of, you said, customer success engineering, also solutions architects who I think do a similar role, but a little bit more internal facing from what I've seen. Then management, I think they work a lot more with the individual engineers and making sure that their career development is where it needs to be and that the tasks are manageable and all that. But then also the product managers, they work really closely with us. I'm actually on a product team. So the meetings that I go to for the most part are with a bunch of PMs. And so I think that there's a lot of similarities there. They are deciding the real project or the real roadmap. And I think that's a really good point. I think that's a really good point. What is going to be prioritized and what is going to be focused on, whereas we're more providing the voice of the community in some way that helps inform that decision. Yeah. Yes. So I'm interested in this role because I've seen it pop up a lot more. And as we continue to have more companies that are building kind of these meta products, right, it's not just going to be. AWS, but there's going to be, you know, companies that are building things on top of AWS that would still need to fill the same role. And there already are. Right. Yeah, for sure. What I'm interested in is, you know, if I'm a software engineer now, let's say I'm a junior software engineer even. And maybe I'm in my first my first role two or three years in whatever the title is. And I kind of like this idea. You know, how would I know if my motivations are are leading me to this role or am I burning out? Like, how do you know when you would want to switch into a role like this? And if, you know, if my particular skill set or strengths or interests would lead me to do well in a role like this? Oh, I think this leads to two interesting conversations. The first is and I see this conversation actually a lot in developer advocacy. Communities is should there be junior developer advocates? And then the second piece of the conversation is like, what skills should you develop if you want to do it as a career? So I'll kind of talk about both. Does that sound OK? Yeah, absolutely. OK, so the first one. And this is really controversial. As I've been saying, I was pretty senior when I became a developer advocate. I had been in the industry for quite a few years and been a software engineer at different levels. Including like lead level and senior level. And I'd been teaching for a while. So that's my background. But I do think that the idea of having junior developer advocates is really interesting because. Junior developers often have the hardest time getting started with certain technologies. And so we want the documentation to be great for them. We want their user experience to be great. We want their voice to be heard in the community. Because they're going to be in the community as customers as well. And so I think that the idea of having like a junior developer advocate is a really great one and something that more teams should have. I think it's really rare, though. I think most companies are searching for more senior people because it allows them to have somebody who can kind of get up to speed on building with the product a little bit faster. And work with the bridges. And I think that's really important. And I think that's really important. And I think that's really important. And I think that's really important. I have this technology. Some partner has this technology. How do these two things work together? So I do see more senior roles being available. But I do wish that there were more junior ones. And I think that they're valuable and should become more of a thing. The other side of this is what should you do if you want to be a developer advocate? And I think this gets into a little bit of a sticky area. And that is because a lot of it is doing work outside of work. And I don't want to necessarily encourage that because I know that that's not realistic for a lot of people. And it does require privilege in order to do that. You have to have a life that allows you to do that. And so I think the best thing that you can do is start small. And for me, actually, this has been for all of my jobs, is I've gotten those jobs by doing the job before I had it. And so for becoming a developer advocate, I was writing blog posts. I was. I was tweeting. I was interacting with the community, doing open source projects. I was making relationships and leading meetups and making those bonds with key community members. And so I was doing a lot of this a long time before I had the title. And I don't want to recommend that as the only path. I think starting small and speaking at one meetup or demoing something online or sharing what you've learned is really great for your career at any level, even if developer advocacy isn't your career path. But I think that that's the best way that I know of, at least to demonstrate that you do have an interest in content creation and that you do want to get involved with the developer community. We'll be right back with the rest of the first part of my interview with Ali Spittel. Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel Ali Spittel 365 human support. It's a weird sentence, but it means they're always there with no tiers, no handoffs, regardless of your plan size. You can choose shared and dedicated compute instances, or you can even use your $100 in credit for S3 compatible object storage, managed Kubernetes, and more. Remember, if it runs on Linux, it will run on Linode. Head over to linode.com slash developer T and click on the create free account button to get started. And thank you again to Linode for sponsoring today's episode of Developer Team. Yeah, this is great advice. And straight from someone who has been working with engineers, really for... Your whole career, right? It seems that you have an interest in enabling other engineers, no matter what your title is, that seems to be kind of the theme running through your career. Would you agree that that's kind of your... I don't know. I don't want to use the word calling or mission, but something along those lines, your kind of driving motivation that seems to be like the through line, I guess. Yeah, I think the idea of making... Code as accessible and fun as possible is kind of my mission. I originally came into computer science by accident and kind of got gatekept out pretty early in my coding career. And I only got back into it because I realized that I could make my life a lot easier by using it to automate a lot of my job. And so I started creating content because I knew that... Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. and also make it so that it's an easier thing for them and that they feel like they can do it because it's something that I've struggled with, imposter syndrome and really doubting myself. And so I'd really rather people not deal with that in their journey. Yeah. Yeah, I think you could make an entire career off of, and I guess some people have, off of helping people deal with imposter syndrome and understand it in its right context. Not having a level of overconfidence that is inappropriate to the complexity of the problem they're trying to solve, but rather the confidence to be able to fail without it being an indictment on, are you ever going to succeed? Well, that's where imposter syndrome, I think, is most damaging. And it makes sense to have some level of realism when it comes to, man, there's just so much, there's so much to learn. And just because there's so much to learn does not make me incapable. And I think that's, anyway, I think that's just me thinking out loud, but I believe that it's, you know, this is something that every developer through their whole career faces. It's not just, you know, in that super early part. It's, I'm 10 years in and I'm still feeling like I'm behind somehow, right? That there's so much left to learn. And there's no way I'm ever going to learn it all. Oh, yeah, that's so real. I mean, even starting this new job at AWS, I was like, there's a million and one acronyms that I need to learn. And so much that's way outside my depth as somebody who's like spent most of my life in Python and JavaScript, like, how am I going to learn all this cloud stuff on top of that? And this is way outside of what I can learn. And this inundation at first that it's so intimidating and so, you know, it's so, you know, it's so, you know, it's so, you know, it's so terrifying. And then you kind of start learning and then it's even more scary because you then are starting to realize how much you don't know and how much there is still out there that you need to absorb. And then from there, eventually you get to this high point where you're like, okay, I know what I don't know and I'm okay with that. Like, I'm never going to know everything. You're never going to know everything as a developer. And that's something that I really struggled with early in my career. Like, I used to buy Udemy courses. Whenever they were on sale for things that were completely irrelevant to what I did, like game development. And you're never going to take it. You're never going to get through the whole thing. Oh, never. And like, I don't need to know .NET. Like, I mean, a lot of people use it, but I don't need to know like AngularJS. It was so funny. I would try to buy all these courses because they were on sale for like five bucks or whatever. And I was like, oh yeah, I should learn all this so that I can become a real developer. But anyways, I think that that's, such a huge thing in this industry of like shiny object syndrome and seeing all the new hot things that are out there and wanting to learn them all. And I think that there's a real good side to that in that wanting to always expand your knowledge and grow more. But I think what the really dangerous side is, is having this anxiety that if I don't know everything, that I'm not going to be where I need to be. I think the realization that you're never going to know everything is really important. Yeah, this is a topic that I've thought for years about because I think software engineers face some unique circumstances that are different from most kind of longstanding, established, you know, industrial jobs, right? Including also knowledge work, like being a lawyer or being, I don't know, a doctor. Maybe doctor is closer in some ways, but with the idea that they just don't have a super, fast changing landscape to adjust to. Doctors certainly have more research that's coming out and they have to adjust that. But in terms of, you know, the law, right? If I'm a lawyer, I really don't have, you know, not every lawyer is out there like contributing open source laws that I have to go and keep, you know, keep on learning every day, right? So there's this constant treadmill that's, it's more like a flywheel. It's increasing. It's increasing in speed. And if you were to try to keep up, it would be impossible. But if you were to compare this to almost any other industry, virtually no other industries, maybe some, but virtually no other industries have the same kind of, you know, implicit imperative of keeping up, right? Imagine being an author. You don't have to read every single book that comes out to continue being an author. Right? You can do it. You can do it. You can do it. You can do it. You can do it. You can do it. You can do it. You can do it. You can do it. You can do it. You can do it. You can do it. You can do it. You can really focus on the fundamentals of writing and become a better author and feel confident in that. And I don't think, I think as engineers, we feel like everybody else's work is what we have to learn. And I think that on its own is damaging. Maybe not damaging, but it's difficult to get past. It really is. And it's amazing how fast it evolves too. I think I wrote my first Hello World eight years ago, which is not that long ago. Not long ago at all. But nothing looks at all the same as it did back then. I was writing Python 2 code and now it's Python 3. I started off with jQuery and then AngularJS and then moved to React. I was like a very early adapter for React. And so I feel like I've been writing React for forever, but like I haven't. Nobody's been writing React for forever. Or then all the new ones like Vue and Svelte. And there's so much out there. And so focusing on what you actually need to know and making that roadmap for yourself, I think is one of the most challenging things for new developers because there is so much out there and there's no real right decision on what to learn and what to choose to learn either. Thank you again, Allie, for joining me on Developer Tea for a second round. The first part of my interview, make sure you go ahead and subscribe on whatever podcasting app you currently use so you don't miss out on the second part of my interview with Allie. Thank you again to Linode for sponsoring today's episode. To get $100 in free credit, head over to linode.com slash developer tea and click on the create free account button. If you want to join the developer tea discord, head over to developertea.com slash discord. Once again, the second part of this interview will come out in the next episode of Developer Tea. So go ahead and subscribe in whatever podcasting app, you're currently using. Thanks so much for listening. And until next time, enjoy your tea.