I'm excited to welcome back to Developer Tea today, Ali Spittle. Ali 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 Ali is doing. You can follow her on Twitter. That's where most people are following her. Twitter handle is A. Spittle. 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. The DECENC is really all we care about. And I really want to engage with people who are looking to improve in their careers, who are looking to think on a better level. So 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 Ali Spittle. Ali, welcome back to the show. Thank you so much for having me. So last time we talked, as we were just discussing beforehand, you were, I think you were at Dev2 and it was around the time that you had either joined you or about to leave. I can't remember exactly when we talked, but 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 feel like this is, I keep putting my dogs birthday wrong down on things because she's two and a half. And I keep saying that she's born in 2020, which she was not. Yeah, I do the same thing except with my human daughter. So I understand the, I guess she was born in 2019 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. So it's been, 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, we're gone. 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 teaching 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 EWS this summer where I'm going to be doing, or where I am doing developer advocacy, specifically on the EWS 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. It does, it does. So developer advocacy, this is something that I think a lot of engineers here and there's some pre-conceptions of what this is. 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? Ooh, it was super interesting. So I think developer advocacy can work at almost any level with a company. Deb 2, I was kind of a developer advocate there too. And I think it was higher number seven. So really early on in their startup kind of journey there, but then 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 marketing. And so you'll be more 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 the 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 are 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 and 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 to 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 get hub 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 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 road maps. 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 road map and 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. I 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 these meta products, it's not just going to be AWS, but there's going to be companies that are building things on top of AWS that would still need to fill the same role. And they're already are. Yeah, for sure. What I'm interested in is 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. How would I know if my motivations are leading me to this role or am I burning out? How do you know when you would want to switch into a role like this? And if my particular skill set or strengths or interests would lead me to do well in a role like this. 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 okay? Yeah, absolutely. Okay. 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 between technologies. A lot of it is 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? 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 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. You're going to develop a 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 Alice Biddle. You can simplify your backend structure and cut your cloud bills in half with Linux virtual machines. You can develop deploying scale your modern applications faster and easier. Whether you are developing your personal project or maybe you're managing larger workloads with multiple nodes, all network together, you deserve simple, affordable and accessible cloud computing solutions. And that's what you get with Linux. You can get started on Linux today and you'll get $100 in free credit for listeners of this podcast. You can find all the details at linod.com slash Developer Tea. And of course, linod has data centers that are around the world with the same simple and consistent pricing regardless of the location. You can choose a data center that is nearest to you or nearest to your customers, for example, to reduce the latency between your server and their computer. You also receive 24.7 365 human support. It's a weird sentence, but it means they're always there with no tears, no handoffs, regardless of your plan size. You can choose shared and dedicated computing 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 linod. Head over to linod.com slash Developer Tea. Click on the Create Free Account button to get started. Thank you again to linod for sponsoring today's episode of Developer Tea. Yeah, but this is this is great advice and straight from someone who has been working with engineers really for your whole career. It seems that you have an interest in enabling other engineers no matter what your title is. It seems to be kind of the theme running through your career. Would you agree that that's kind of your, 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 gate kept 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. I started creating content because I knew that if I had somebody that I thought represented me when I was starting to learn that that would have made me stick to it a little bit more. I think the idea of programming being this like adult version of Legos is really powerful because you can really build anything and it enables you to do so much. You get to build products that so many more people could use than if they were off the web. I think there's a lot of power in that. I want to bring it to as many people as possible and also make it so that it's an easier thing for them and it feels like they can do it because it's something that I've struggled with in Poster syndrome and really doubting myself and so it really rather people not deal with that in their journey. I think you could make an entire career off of, and I guess some people have, off of helping people deal with in Poster syndrome and understand it in its right context, not having a level of overconfidence that is appropriate 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 in Poster syndrome I think is most damaging and it makes sense to have some level of realism when it comes to, and there's just 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 at 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 is 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 terrifying. And then you kind of start learning and then it's even more scary because you've been 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 has a developer and that's something that I really struggled with early in my career. Like, I used to buy you to meet 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 go 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 it 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 objects 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, industrial jobs, right? I'm including also knowledge work, like being a lawyer or being a doctor. Maybe doctors 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 the law, if I'm a lawyer, I really don't have, not every lawyer is out there like contributing open source laws that I have to go and keep on learning every day. So there's this constant treadmill that's, it's more like a flywheel. 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 implicit imperative of keeping up, right? Even being an author, right? You don't have to read every single book that comes out to continue being an author. 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 that, 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 to. I think I wrote my first Hello World eight years ago, which is not that 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 Angular.js and then moved to React. I was like a very early adapter for React. And so I feel like I've been writing React forever, but like I have it. Nobody's been writing React forever. Or then all the new ones like view and spell 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 or what to choose to learn either. Thank you again, Ali for joining me on Developer Tea for his second round. The first part of my interview, I make sure you go ahead and subscribe in whatever podcasting app you currently use. So you don't miss out on the second part of my interview with Ali. Thank you again to Leno for sponsoring today's episode. To get $100 in free credit, head over to linno.com slash Developer Tea, 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.