Episode #111: Amplifying Serverless Developers with Ali Spittel
September 20, 2021 • 60 minutes
On this episode, Jeremy and Rebecca chat with Ali Spittel about the ongoing evolution of AWS Amplify, why developers should be embracing low-code frameworks and platforms, why developers shouldn't feel like they need to know everything, and so much more.
Ali loves teaching people to code, and is currently doing so as a Senior Developer Advocate at AWS. She has been employed in the tech industry since 2014, holding multiple software engineering positions at startups, and a Distinguished Faculty and Faculty Lead role at General Assembly's Software Engineering Immersive. She blogs a lot about code and her life as a developer and also has a podcast with three other incredible women: Ladybug Podcast. They talk about the tech industry, their backgrounds, and go in depth on code-topics. When she’s not coding you can find her watching her favorite New England sports teams, taking runs with her dog Blair, or rock climbing.
Transcript
Rebecca: Hey everyone, I'm Rebecca Marshburn.
Jeremy: And I'm Jeremy Daly
Rebecca: And you're listening to Serverless Chats. Hey Jeremy, how have you been?
Jeremy: I have been well, Rebecca, and yourself?
Rebecca: Been doing good. Guess what I'm doing this weekend? You might not be able to guess from the pattern that has emerged.
Jeremy: I'm guessing you're going to a wedding.
Rebecca: Yes. I'm going to a wedding, and I'm doing the flowers.
Jeremy: Oh, nice. Beautiful.
Rebecca: So, the trend continues.
Jeremy: Beautiful. Well, we are now in full soccer mode in the Daly house. So I have my youngest daughter who is on the middle school team. And then also recreational soccer, my older daughter is playing in a soccer league as well. So, basically it is work, soccer, bed, work, soccer, bed, that's basically my whole life now.
Rebecca: And a few podcasts in between.
Jeremy: And a few podcasts, yeah. Games on Saturdays and Sundays, but during the week, yeah, it's kind of crazy. So anyways, we have an amazing podcast guest today, speaking of podcasts. Would you like to introduce our guest?
Rebecca: I absolutely would. Today, our guest is senior developer advocate for Amplify at Amazon web services, or AWS, she's the co-host of the Lady Bug Podcast, and founder of We Learn Code, Ali Spittel. Hey Ali, thank you for joining us.
Ali: Hey, thanks so much for having me. This will be a lot of fun.
Rebecca: Well, thank you so much for being here, Ali. And as I may have already given away, you're a senior developer, or advocate, you're a senior developer advocate for AWS Amplify. And my hunch would be that you are specifically drawn to wanting to teach around Amplify. I often hear developers praise it for its relative ease of use, when it comes to getting a full stack application up and running. I might even say it might be called the friendly, heavy air quotes, AWS service, depending on who you are. So, can you talk a bit about Amplify, and what made you want to be a DA for the service?
Ali: Yeah, for sure, for sure. So I think there's two parts of that, first is developer advocacy, and then the second part is why Amplify specifically? So, developer advocacy is relatively new for me, before this I was a teacher at a bootcamp, I was the faculty lead for General Assembly's software engineering program, but I was also a lead instructor before that. And I just loved seeing people on their coding journey, and seeing it click for them, going from, "Hello world," to building a full stack app in a certain amount of time was really cool. And to hear their career progression, like I have a student, a former student who's on my team at AWS now, and it's so cool to see that growth.
Ali: And I studied education in college as my minor, and got to shadow in a middle school and all that, and so I got to teach all different ages. And so, going from there, career progression-wise after teaching, developer advocacy seemed like a relatively natural fit. Where I'd still be writing code, I'd still be teaching code, and then I'd also be advocating for the product internally too, and making sure that different product features that will make it easier for customers to use. I think that's really exciting as well. And I really get to focus on those early career developers in my job too, which I absolutely love, because they're in a really unique point in their careers and we should really tailor our stuff to them as well. Not just focusing on these people who are 15 years into cloud computing, we should also be friendly to those who are newer to writing code as well.
Ali: So, I love that part of it. And then Amplify specifically, I have been doing more and more front end in the last few years. I started off as a very traditional, heavy back end engineer, and then moved more into the front end stuff. And so, Amplify is more tailored to those front end developers, and so being able to work with them is really exciting. But also, I think of AWS has this developer playground where there's just no end to the learning, and so I get to learn so much every single day. And that to me, makes my job really worthwhile, that I get to keep learning and growing myself. Because sometimes it feels like you stagnate at some point with parts of developing. You're building the same cred app over and over again. And so, that's the really cool thing about AWS, is I don't think I'll ever learn all of it. I don't think that's even possible.
Jeremy: Right. And that's one of those things about AWS, which is just, there is so much more to learn. And the idea of becoming stagnant in your career too, that was the thing... I owned a web development company for 12 years, and I got to a point where I had built so many online forms, that I'm like, "I can't do this anymore. I have to do something different." And then I just went down the startup road, and of course that's been a whole crazy experience for the last, I don't know, 15 years now, whatever that's been. But it's been... I totally get it, because that progression of keep learning, and learning, and learning is such an important thing.
Ali: Yeah. I think the form comment is exactly it. I could not build another form for a cred app. It's just just too much.
Rebecca: Well, I think we're really glad that you found Amplify, and that those who are trying to use Amplify found you, which is really special. I'm curious as, as someone working with newcomers to the service, and you really like to focus on that newcomer space, or perhaps not even a newcomer but someone who's new to this service, which is totally different for them than perhaps another way of working that they were used to. Have you seen any patterns or themes emerge, in terms of where people need the most guidance, where you keep having to go back to and kind of steer the ship?
Ali: Ooh, that's a great question. I think that something that my team focuses on a lot is... So, I think people see half of developer advocacy, of advocating externally, of creating content and doing conference talks, and streams and all that, and it's public facing. But then there's a whole nother half of it, which is being in those product meetings. And we do something called friction logging, which is where whenever we're creating a demo, we go through and step-by-step document every single step we take. And then also color code it red, yellow, green. Green is, "This is amazing, this was a developer experience thing that really shines and was fun to do." And then yellow is, "This could be better in some way." And red is like, "Oh my goodness, stop. This is something that we really need to work on."
Ali: And so, that's something that we try to do from our different personas that we cover too. So I focus really heavily on those beginner developers, so I try to put myself in their shoes as much as possible. And I'm not a beginner developer, I've been in this industry for almost a decade now. I try to keep that a little quiet, but I've been doing this for quite some time now. And so, I can try to be empathetic to that customer as much as possible, and think about, okay, they're going to know how to create a for-loop, but maybe they're not going to know what these different services are named, and what those different things do, like what is Amazon S3? It allows you to store images, or store static files.
Ali: And so thinking about those use cases rather than the jargon, I think is really important. This is something though, that when I'm teaching, I try to also give them that background. Because a lot of people do want to know that, and they do want to be able to use the jargon down the road. Because a lot of times they're going to be asked that in interviews, and if you're not all speaking the same language that becomes pretty tricky. And so, I think trying to make it as simple as possible, and start with step-by-step, and breaking down all the different pieces, and breaking down the different jargon, but still building them up so that they're able to build something real. That's something that I am really passionate about.
Jeremy: Yeah. So, this idea of the getting started experience or working with people early, that's one of the great things that I always loved about Amplify was you go through, it kind of asks you a series of questions. And you can bootstrap an application pretty quickly. And whether it's just a web front end, or you're using Flutter or one of these other things to do more, even iOS mobile and things like that, it gives you a lot of really easy ways to onboard you, bootstrap that thing.
Jeremy: Now, I've read a lot of blog posts about Amplify over the years, and it's been great cause it's cool to see people trying it, whatever. One of the common themes had been though, and I'm not sure if this true anymore, but one of the common themes has been hitting that feature ceiling. Like you get to a point where you're like, "All right, this just isn't growing with us anymore. We need to eject, or we need to graduate to something different." And I remember speaking with Nader Dabit, that was almost two years ago now. And this was early on, and I think he said something around, he said, "It's opinionated, we're trying to get people to follow a certain thing. And we get to a point where you might get to you need to object, you need to do something different. Maybe you modify the CloudFormation, maybe you take it over to Sam or something like that."
Jeremy: So I think that that is a valid, or at least was a valid argument, maybe not against using Amplify, but just something to be aware of that you would run up to that. But I'm kind of curious, there's been so many features added and things like that, are we still at that point? Can Amplify grow with you all the way, or is there still potentially that need where you're going to need to object after a while? And not that that's necessarily a bad thing, everybody grows and gets bigger, but I'm just curious, is the goal to try to keep everybody in Amplify and give them all the features they need? Or is that just something where you get to a certain point, and you might need to start thinking about other options?
Ali: Yeah, for sure. So, we are working really hard on that extensibility story, like you were saying, the idea that Amplify can keep growing with you as your product scales, and we can start you from the beginning to that point. That being said, we really do take the front to back approach, where we're thinking front end developers first, and then really customizing it to that story. And so, sometimes if you're at a point where you're hiring a ton of, ton of back end developers, the nice thing is that it's infrastructure as code, and you've got all that CloudFormation generated for you, and you can use that to move over to what you need to, to fit your team's use case. So yes, we've definitely been working really hard on that ability to keep with Amplify longer and longer, and keep growing with it. But also, we still are focusing on those front end developers first, and mobile developers too.
Rebecca: That is such a clever turn of language. I'm like a language lover, so the fact that you said front to back rather than... We would often say end to end, right? The whole experience, the experience for everyone. But what that does, is that kind of washes out the actual focus, where you want to focus first. So, front to back is so much more helpful in truly understanding where you're at, saying, "We're going to focus on front end first. If we have to make a trade off, we're going to go for a front end developer, because that's what we're serving. And we're going to make it to the back end." Rather than saying end to end, and them being like, "Well, they're both ends. Which end do we start at?"
Ali: Yeah, yeah, yeah. And I think that's one of those things that you have to have the people in mind that you're building for. If you're trying to build for everybody, you might not be building for anybody, to be honest. And that's something that I think about when I'm creating content too, is I have one specific person in mind that I'm writing a blog post to, and it ends up being different people from different backgrounds that are reading the thing. But if you have that person in mind, you know that it's going to help a person from that persona. If you don't have that in mind, then you're using some jargon, in some places you're breaking it down, in other places you're explaining some things in an expert-type way and other things in a beginner-type way. And you just end up not really being writing for anybody.
Ali: And so, I think the same is true with development products, is that you have these core customers or personas in mind that you're building for, and it'll end up helping more people than that. There are non front end developers using Amplify out there, but that's really the person that we're building with them in mind first.
Rebecca: Wow. I had a conversation, I was interviewing Jeff Barr for something else a couple of months ago. And I asked him about his writing process, since he has such a beloved blog, and the whole AWS evangelism. And he said the exact same thing. He said, "I meet people at conferences, and I remember them in my mind's eye. And I remember what we talked about, and I say, 'This blog post is for you, Kelsey.'" And he really does write with that person in mind, which I love that. And I wonder how many of you who also write and work at AWS, if you all actually secretly have a different developer in your head? I would love to see the whole portrait of all those developers.
Ali: Yeah. So, I actually manage our developer advocacy team now, so that's something that I have everybody do is write out their personas, like, "Who are you covering? Who am I covering? Who are these people that we want to help out?" For me, I said these beginner developers are really the core that I love working with and speaking to, but I also really like the indie maker story, because I have my blog which has turned into a company of sorts, and my podcast which has turned into a company as well. And so, I can speak to that customer pretty well as well.
Ali: But then I also have people on my team who want to talk more about the Amplify and production story, like how are you using this to talk to startups, and how are those customers doing that? And then also, I have a developer advocate on my team who is from Nigeria, and so he really wants to speak to the customer who may not have the most ideal internet situation. And so, it allows us to work together to cover these different types of people, and really speak to all of them, but also with tailoring our own experiences and incorporating those into the stories, but still having the people in mind that we really want to reach.
Rebecca: Yeah. All right, I took us for a little stroll because I got Really excited about your use of language. But I did want to ask you about the growth of Amplify, perhaps you're doing this front to back approach, but Amplify is, you're adding features and improvements to it, creating that extensibility story. And you wrote about this recently in your Dev.to blog about the 10 coolest releases. And a few of our recent favorites are mixing and matching authorization modes and data store support for storing environment variables, and secret access by AWS Lambda functions, and launching new full stack CICB capabilities. So, I'm wondering as a dev advocate, which releases have been your favorite in terms of seeing your customers and students benefit the most?
Ali: So, my favorite one personally is the admin UI. I just think that idea of... Okay, so the idea of low code, I think in general terrifies developers. It's like, "Where's my job going to go? It's going to be this awful user interface, and all the code is going to be abstracted away from me." But what I really like about our admin UI, is that it's a developer first mechanism for generating code. And it's a more visual interface, which I think does help some developers. They like having that visual way of creating a database. I know that I do too, I think that you create ERDs or whatever, entity relational diagrams when you're building out a database, and so if that can just be your database, you can then click a button and it generates it for you, I think that's pretty cool.
Ali: And then all the code is still generated for you. I think that's one of the cool things about Amplify too, is that so much of what it does is cogeneration. And so, I personally just think it's really fun to use. It's something that as a software engineer, I started up in the Jingo era and the Rails era, where we had all these admin consoles that would generate with the app. And the fact that we can do that with the admin UI, I think is really great too. We've kind of lost that with the more heavy front end framework era of development, and so bringing that back, I think is really cool. Because there was a really great developer experience that came from that, and I think some of that has gone missing. So, that to me is something I'm really excited about, and really excited to see more and more services integrated into. That's me personally.
Jeremy: Well, it's funny that you mentioned the admin UI console, because I wanted to talk about that as well. Because that's one of those things that I look at as a developer who has built, I don't even want to tell you how many applications I've built over my lifetime, but it's a lot. But one of the things I see, especially even in teams, you focus very much on building out that MVP and trying to get that product out the door. And admin is one of those things you just ignore almost all the time. It's like, well, we got to build an admin panel, but yeah, do we really right now, or can we just do this? And then you end up with a hodgepodge of scripts, so that you can delete users, or change something or whatever. And it's always like, "Call Jim," or, "Call Sue, we got to do something. We got to make some change," and nobody knows how to do it.
Jeremy: So, that idea of having an admin right out of the box is just, to me, is crazy. It's almost like table stakes now. Because you mentioned like Ruby on Rails, and even if you think back to like Symphony and some of these other frameworks that had this debugging console, and the whole admin experience, just so you can go and add and delete a user. That's amazing. And I'm sort of curious, in terms of what you're seeing from productivity-wise, because to me it's that kind of thing where as a developer, I don't have to build that piece of it. So, I don't have to go in and build the admin UI for adding and deleting users, or the data piece or whatever. But have you seen people embracing this now, and getting productivity gains from that?
Ali: Yeah, definitely, definitely. I think it's one of those pieces that the customers just are so excited about, and I am really excited about it too. I build Amplify apps like every day, I there's a limit on your AWS account that you can only have 25 Amplify apps per region, and I always hit that. I hit it probably three times a week. And so, just for me, it's so nice to be able to use that and generate a back end so quickly. And it's a huge productivity win too. Go back to forms, those forms are already built for you, so you can create that initial data to test out your app instead of having to build those forms yourself. So yeah, we've definitely heard great things from customers, and I'm really excited to see other categories being integrated into it too. The idea of potentially having image uploading through it, or something like that I think would be so cool.
Jeremy: Right. Well, so the other thing you mentioned too was the data, and that sort of visual data builder that you have. And anybody who doesn't have experience with NoSQL modeling, even if you do have experienced modeling NoSQL, it's not easy, right? It's can be a very complex process, just watch the Rick Houlihan videos, or read Alex DeBrie's book. But it's very, it is definitely a complex thing. And I don't think, just full transparency here, I don't think that the modeler is perfect. Because it can't be, because there's so many different ways to go down, but it is really good.
Jeremy: And that ability for you to do that, now, modeling is one thing, building out the GraphQL schema automatically for you, and giving you the mutations and the resolvers and all that kind of stuff, that's where it just sells it for me. Because again, building that stuff by hand is crazy. It's just undifferentiated heavy lifting that you do not need. So I'm just, I'm curious, obviously you're excited about it as well, but that's another massive productivity gain, another thing customers don't need to think about. And just that ability to leapfrog you years, it would take months and months and months, and probably years of experience before you can get to a point where you can build that the way you're supposed to. And that's just baked right in.
Ali: Oh, definitely. Definitely. I remember reading Alex's book. It's amazing, if you have not read it, Dynamo DB book, it's really great. It's a lot. And I just remember early in my career, using Postgres for everything and just absolutely loving it. And it has such great developer experience, where you can create these tables and rows, and just use them as is. And that's awesome, but then you need NoSQL if you're going to go to hyperscale, SQL doesn't do hyperscale well. And so, having those gains of NoSQL, but also having the developer experience that's more similar to a SQL type situation, where you're not having to think too much about the nitty gritty of modeling, or the wild west that can be NoSQL. I think that that's really great.
Ali: And the wrapper on it too, data story that allows the data to be available online and offline, that's something that I've implemented so many times as developer. I used to be a software engineer at Dev.to, which is a platform for developers, and I built their blog uploading tool. So, you can write a blog on there, and that has the online offline pattern, where if somebody accidentally refreshes the page or loses internet, it stores your blog post locally so you don't lose it. And so, data store just does that for you out of the box without you having to really implement that data pattern yourself, which is pretty nice.
Rebecca: That is so cool. So, you use one of the products that you built almost every day. You blog on Dev.to and I see a lot of your content hosted on there. Which is really cool, but I wonder how that feels for you to like, "Oh, I remember that. I didn't change that in the code base, and it's still persisting."
Ali: Yeah, yeah, yeah. I think it's so cool to have worked for them. I was like hire number seven, so super, super early stage. Very different than working for AWS, which is a very large company. But it is so cool to still use the things that I built, there's also an offline page that you can draw using, so it uses HTML Canvas and you can draw pictures while you're stuck offline. I built that too, and that one always resurfaces on social media or on Reddit sometimes. And I'm like, oh, I built that, this is so funny.
Rebecca: Yeah. You're going to have a bunch of people accessing that now after this podcast, who are like, "Wait, what? That's been there this whole time?" What a delight, turning something that's very frustrating into a delight, that's amazing. So, I'm curious if there's... As you said, you're constantly adding new stuff to Amplify. I love the green, yellow, red approach, and then so you know where to focus your time, and then from front to back. So, you have all these different ways of evaluation and criteria of what comes next, and what you build next, and what you focus on now. I'm wondering if there's something that you continue to hear as a wishlist item for Amplify, and what's something that you continue to poke the product teams about. Where you're like, "Hey y'all, I know we talked about this, but it's still there."
Ali: There's so many. So, I think a big one up until recently was the Next.js full support. So we just added service side rendering for Next.js in the last couple of months, and before that we had so many customers asking for that, or trying to deploy it and it just wouldn't work. And so, that was a huge one. But to follow up on that Next.js, we don't have server side rendering support for that yet, and I've gotten a ton of customers asking for that because the view community is also very busy, and very excited about things as well. So, definitely want to integrate that.
Ali: Also, just more support for different categories within the admin UI. I know when it came out, I was getting all sorts of requests for standard GraphQL support, because right now it's data store instead of just our raw GraphQL API, so that's another one that I hear about a lot. This is kind of a niche one, but we have a seed data feature within the admin UI, where you can press this button and generate like 20 rows of data or something like that. And right now it just does lorem ipsum for you. And I keep pushing them to use Faker, or a library like that to make it so that it's people's names instead of just like lorem ipsum. So that's a niche one, but it would be pretty fun too.
Rebecca: But also delightful, right? Because there are so many good libraries where you're like, wait a minute, that just told me a poem from Shakespeare, I'm just reading part of Hamlet? This is great.
Ali: Yeah, exactly, exactly. And then I think the other big one is the sensibility story we have been talking about, and that's something that we've worked a lot on. But I think we can still keep working on and keep getting better there, and really try to make it so that Amplify's something that you can scale with for a very long time.
Jeremy: Love it. So hey, you want to talk about low code for a couple of minutes?
Ali: Yeah, for sure.
Jeremy: Okay. So, you have a post that you wrote earlier this year, it was called The Case for Lower Code. And actually, I'm working on a project at Serverless, Inc, Serverless Cloud, which is basically trying to build a low code platform. So, I totally appreciate, it totally resonated with me exactly what you were talking about. And so, you did this really cool thing where you framed, the difference between full code and low code and no code, and so forth. And this idea that full code is, there's this ongoing cost and ongoing commitment, huge learning experience in order to get yourself to be a developer, the cost of hiring more developers to maintain all this stuff. Versus I think what you would position maybe, or call a more productive low code approach, where the developer still has a lot of control, but you're abstracting away a lot of things for them.
Jeremy: And so, I think just, and I'd love your opinion on this, but being a modern, in quotes, application developer now, I think is a lot harder. Even though we have all these tools, and all these frameworks, and all these other things, the scope of what you need to know, if you want to deploy a full application on AWS or Microsoft Azure or IBM Cloud or any of these things, it's not just writing for-loops and querying a database anymore. It is setting up the IAC, it's setting up your infrastructure's code, it's understanding the services. Like you said, like you might understand the attractions, but maybe you want to learn the services behind them. So, there's all kinds of crazy things like that.
Jeremy: You said you came from the Ruby on Rails days, that was magical, right? It was this, you don't even need to write the database, you just write the query and it sort of understood how it would save it in the database, and some interesting things like that. So I'm just curious here, even if you take the approach of AWS, CDK, or SAM, or Terraform, or serverless framework or any of those there, there is so much that you still have to know. More than you probably had to know in the past, even though a bunch of it is being abstracted away. So, I'm just curious, and I would think Amplify is sort of a low code, it wants to be low code. I think it goes not always low code in some places, but wants to be low code, and is certainly that direction. But I'm curious, from your perspective what's the holy grail of low code? What does the holy grail of a low code platform really look like, and maybe is that where Amplify's trying to go?
Ali: Yeah. I think that's a great question, and I would say that it probably doesn't exist yet, but I think it's something that's really exciting. And you brought up this Ruby on Rails discussion again, and I think that's honestly one of the best versions of low code in a way, that we've had. And it's a spectrum, I think in a lot of ways Ruby on Rails is not low code, you still have to write a huge amount of the code yourself. But you can do rails, generate something, and then it will generate a lot of the code for you. We talked about writing forms, and it would write the initial version of your HTML forms for you, so you didn't have to write that from scratch.
Ali: And then we have this framework era of front end development that we're in now, and we lost a lot of that developer productivity that we had at that era. There's not necessarily as many code generators that you can run, that can write a react form for you. I think that they're starting to exist, but that's not fully there yet. But Ruby on Rails was very much developer first, or it is very much developer first, I keep talking about it in the past tense, a lot of people still use this. I was still using Ruby on Rails on the job a couple of years ago.
Rebecca: Ruby on Rails is like, "I'm not dead."
Ali: Yeah, not dead yet. It's still amazing, it still has a great experience. I should not be using it in the past tense. So, Ruby on Rails has this developer experience that you can generate a lot of the code for you. That being said, I think that Serverless also has a lot of advantages, where you don't have to manage as much of the infrastructure yourself, and with Ruby on rails, it's not really fitting in this serverless paradigm, so you still have to manage the servers yourself.
Ali: And so, I think if we can combine the developer productivity of these two different eras, of having something where the infrastructure is mostly managed for you, where you don't need to worry as much about that, you can have more of a serverless approach, but then also you have the great code generation that comes, I think that that's really amazing too. I think the thing that a lot of low code tools are missing, is that they're not developer first. They have developers as an afterthought, and so most of the code is abstracted away completely from the developer, and you can't access it if you want to. And I think that having a full code generation is still a necessary, so that if anything needs to be tweaked, the developer can do that. I don't think we're at a point where you can build something that has full business logic without a developer.
Ali: I think you can build something that's static, like a Squarespace site or something like that, and you can do comments and things like that, but not something that has custom business logic at this point in history. So, I think the idea of web flow is really, really cool, and I know that it does generate code for you, but it's mostly, again, for those front end only sites. And so, if we had something that has all the code for you and also allows you to use the interface that generates the code, I think that's excellent. And whether that's through the command line, like developers are maybe more used to, or an interface, so that people who are less technical could also feel more comfortable, I think that's really exciting. That's just my two cents, is that we have reinvented the wheel so many times as developers, and let's make it so that in the future, developers can just focus on the hard stuff rather than reinventing the easy stuff over and over again.
Jeremy: Right. Yeah, it's funny because the front end frameworks, I totally agree. I used React for a while, I do a little bit of View, but I'm not really a front end developer, more of a back end developer. But that's the thing, is that I started my career writing everything with vanilla JavaScript, and then it was like, oh, now Scriptaculous exists. And there was this thing called Prototype, and there were a few other ones that gave you features. Then it went to J Query, and then you had J Query and MooTools and some of these other things. And then the next thing you know, you get full deployment ones with React and View, and what's the other one there? Angular, and things like that. So, I think that's a really good point. You start losing productivity as you... you lose productivity in a way, as you start taking control away.
Jeremy: I don't know if that, it seems like it's a good thing because you're like oh, this does all this for you. But oh, now you want to work around something and do it differently, you've got to jump through a bunch of hoops and figure that out. So yeah, I love that. I love that idea though, of still giving developers control. I just never see a no code thing, where a developer is going to be clicking through a UI. You want to see the code, you want to be able to touch it, but at the same time you don't want to be spinning up SQS queues, and setting up databases and managing those, and even maybe thinking about those as primitives. But yeah, no, I love that. I think that's spot on, that's kind of where I want to be. That's where I would love to be, I feel like it would be hyper productive, and still not reinventing the wheel every couple of years.
Ali: Yeah. I very much agree that we can use these tools to make developers more productive. Even if you think about Visual Studio code, for example, the text editor, there are so many visual tools built into that to build developer productivity. And a lot of developers are like, "No user interfaces, bad," but we all use them. And so, I think some sort of hybrid approach that is still great for maybe less technical users, but also can encompass those technical users. I always think, my dad works for Red Hat in business development, and he got a Linux computer when he worked there. And I remember just him freaking out about the command line, like, "What do I do with this? Help me." But then most developers are going to be more comfortable, almost in a command line than in a visual interface. And so, how do we merge those different worlds and make it so that both parties are happy?
Jeremy: Well, it's funny. It's a mix of both, because there's plenty of the visual tools that I use in VS code, but I still refuse to use the Git one, I still have to do Git from the command line, it's the only way I roll.
Ali: Yeah, no, I so agree. I so agree. I have all my aliases and functions built into Bash to make Git more productive than the visual one. Honestly though, working with students, the poll request visualization that VS code has for merge conflicts, is out of this world. Because the little dashes and things that we had to deal with back in the day that would confuse them so much, and so having that visual cue is really helpful.
Jeremy: Yeah, totally agree.
Rebecca: I think, so you used the word comfort a few different times. And it does seem to me, especially as someone who still has been around the developer world, understands the language, but maybe is not, I'm not confident in doing it myself, there's something about low code being something that can give someone who is interested in coding, but not totally sure how to do it once they, once you feel a little more comfortable then I think that allows you to keep moving forward. So there is something special, I think, around introducing some amount of comfort in having that low code experience, where now I feel like I sort of have my feet wet and I can keep going. Versus being like, "This is all too overwhelming, nevermind, I just need to shut this down."
Rebecca: And so, it does seem like that's a good transition or hybrid space between serving people who already feel really comfortable in code, and helping other people who are like, "Okay, now I can see where I'm going," versus being like, "I just need to jump in," and I think a lot of times people hit a barrier right at that moment. And that sounds, I can imagine as a teacher that feels pretty good. But you're constantly looking for that hybrid line to be like, "Okay, what helps people feel comfortable enough to keep going?" Versus shutting their brain down and being like, "Nevermind, I'm just going to go somewhere else."
Ali: For sure, for sure. I think there's this idea of the productive struggle, and at some point the struggle becomes unproductive. But you do need to do it, you still need to go through that Google process yourself, and the debugging and that frustration. If you don't that's, that's really what being a developer is, is being able to solve those small problems yourself, so you have to go through it.
Ali: But I think the reason why I think teaching front end from the beginning, is that you get something really visual, and you get visual feedback to what you're building. And that's the harder thing with teaching Python first, or Java or something like that, is that it's a little bit more abstract. You get something printing it out in your command line.
Jeremy: Look, I made a JSON object, yay!
Ali: Yeah, exactly. And it's like, okay, it's just not overly tangible what you're actually building. And so, I think that's something that's exciting, is the idea that people could be able to build with less and less code. And I hear this story from so many people, that their first time writing code was MySpace, or was tweaking Neo Pets or something along those lines. And so, I think that's a cool thing that maybe we're missing a little bit in this generation.
Rebecca: My favorite videos of yours, is seemingly simple. And you've had really, an array of stunning turns of phrases throughout this conversation, so thank you, like productive struggle, great. I already wrote that down. And front to back, love it. But so, you talk about all these sorts of pieces of advice or turns of phrase that I think are really memorable and really simple. And one of yours, your first piece of advice which is based on your own lessons when you started to learn how to code, is you don't need to know everything. Instead, you suggest that that someone should focus their attention and generally avoid shiny object syndrome, which you call it, from the developer space.
Rebecca: So, how did you choose your technologies and niches, and when did you know it was where you wanted to focus? I think what you offer there, it seems like a simple piece of advice, but it takes a long time to learn that, and then it takes a long time to feel confident enough to share it, and to say, "Hey, I didn't know, and I still don't know, and you don't need to know everything." And so, I'm wondering how you came to be in like, "This is where I want to focus, this is what I'm going to do."
Ali: Oh, definitely, definitely. So, my learning to code story was relatively unique. I didn't know what programming was until I needed a math class in college, and CS101 hit that box, and fit in my schedule. So, I ended up in this classroom, and was thinking that computer science was how to format Word documents or something like that. I had no idea what I was going to learn. And I fell in love with it, I thought it was so cool that you could type something in, and build a game with it and see these different pieces coming to life. I thought it was the coolest thing ever.
Ali: And then I decided to double major in computer science after that one class, and I ended up in data structures and algorithms, the infamous weed-out C++ class. And I was just in way over my head, most of the people in the class had been coding seemingly their whole lives. And I was spending all-nighters, trying to create Sudoku solvers, and these super tricky things. And I was like, okay, nevermind, this just isn't for me, I'm just not smart enough. And so, I quit coding. The only reason that I ended up back into it, is that I had an internship where I was doing a lot of data analysis, and I realized that I could use Python to automate most of my own job, because I was like this is just super repetitive, there's got to be a better way to do this. And I was like, oh, I know Python, I can figure this out.
Ali: But I think that early on in my career, I had this wild imposter syndrome. My career story is different than a lot of people's, I was too old learning this, which is hysterical because now I've taught like 50 and 60 year olds how to code. And I was 18, 19, so definitely was not too old, I can tell you that for sure. But, so I think that early on, I didn't even think that I was going to be a software engineer. Even when I was a software engineer, the first few years, I was like, this is a very temporary thing. I guess it was, because I'm a developer advocate now, but I guess it's still in the same realm.
Ali: And so, I think then I was buying... There's the site, Udemy, which has all these different courses on it, and you get all these emails with these different sales on courses, and I would just rack them all up. It didn't matter if it was on game development, on dot net, it was really just a grab bag of different things. And I was like, I have to learn all of these, there's no way I'm going to be successful. If I don't know how to build an operating system, and know how to do HTML, I'm not a real programmer. And then being in the industry longer, it was like, nobody knows all of these things. Everybody has to pick their specialization, and they have to pick the thing that they're good at and that they enjoy doing. Because there's just too much, nobody's going to know every single programming language, nobody's going to be an expert in all these different things.
Ali: And I think there's also this tendency with new developers, where when you're learning something at first, it's really fun and it's not very difficult. There's this beginning of learning where you're just dipping your toes in the water, and you're like, "Oh, this is really cool. I can write a hello world, I got this." And then it becomes a little bit more hard, and then you start really doubting yourself. And then there's this tendency to be like, "Okay, I'm going to quit this, and I'm going to go learn some other thing now." So, C++ is too hard for me, I'm going to learn, C Sharp instead, or whatever. And so, that's this idea of shiny object syndrome, of you're seeing all these different things, especially with social media the way it is now. I definitely did not know about tech Twitter when I was learning to code, but it seems like there are a lot of new developers on there now.
Ali: And so, you see all these different things, the new JavaScript framework of the week, at least at that point in history, that's coming out. And you're like, "I've got to learn all these different things," and you really just don't. And the knowledge that you're going to get from learning something more in depth, is going to be so much more valuable and so much more transferable than learning hello world in 20 languages. I guess the hello world transfers from language to language, but outside of that, it's going to be pretty hard to write something productive, if that's all you know how to do.
Jeremy: Right. And you actually, some other advice that you give I think in that same talk, where you talk about not getting stuck in this tutorial hamster wheel type thing. Because it's not only about switching to the new shiny object, it's also how far certain tutorials will take you. And I often find with tutorials, it's like beginning type script. Okay great, you take that. And then there might be one on advanced TypeScript, okay, so you take that. But you can watch those a hundred times, and you're never going to get the experience or the knowledge, or be able to actually build something until you actually start building something. And then start Googling, and stack overflowing, and find that random Dev.toposts that is about some edge case that you're having, and things like that.
Jeremy: So, I think that's great advice. Because that's just one of those things where it does seem like, "Well, I should know how to do this, or I should know how to do this, or I should know how to do this." But I'm telling you, finding an expert in any particular area, like if you can find somebody who really knows React, even if they don't know how to build an API, but they know how to interact with all of them, and they know how to handle all the use cases, and all the fail overs and everything that's around there, that is tremendously more valuable, at least in my opinion, than just being a jack of all trades and a master of none.
Ali: Oh definitely, definitely. And something that I bring up, is this idea of T-shaped knowledge. So, you have deep knowledge in one area, and then shallower knowledge in other areas, so that you can at least speak to them. You might not be a back end developer yourself, but you know what a database is, so you can communicate with your back end developer and talk to them about it. I also think, going back to the idea of tutorials, I saw this so often when teaching, is you'd give somebody an assignment like build a tic-tac-toe solver, or build a tic-tac-toe app. And then they would Google, "How to build a tic-tac-toe app with JavaScript and HTML," and then they'd copy and paste that and turn that in. That doesn't teach you how to be a programmer, that teaches you how to do a research assignment. And so, if you can break the problem into smaller and smaller problems, that's really what programming is. And so, Googling each one of those tiny little pieces instead of the puzzle in general, is way more helpful.
Jeremy: Yeah, totally agree. And now, you mentioned that you were unaware of tech Twitter, I wish I was now unaware of tech Twitter sometimes.
Ali: Same, same.
Jeremy: Because another piece of advice that you give is, "Don't listen to jerks." I think I've probably had a different experience than a lot of other people, depending on your background and things like that, it can be brutal. It can be brutal when you start posting things, and putting yourself out there, and it's real. And that's one of those things, so your advice is don't listen to them, but can you go a little deeper on that? Because I feel like it's easy, "Oh, just sticks and stones," right. But words cut deep sometimes, and it can really shake your confidence. So, what's your advice to people who are getting trolled or getting negative comments?
Ali: Yeah, for sure. So, I think at first there's this tendency to just be like, "Oh, they're jerks, just ignore them." And I think that's valid, but I think that's also much easier said than done. And so, people then get mad at themselves for taking these things personally, and that's psychologically how we work. We're just going to focus on the criticism that people give us, rather than the compliments. Even if there's a thousand compliments, if somebody says something nasty, you're most likely going to focus on that one nasty comment. That's just how we're wired. And so, I think giving yourself the grace to realize that, and not be mad at yourself for just seeing that.
Ali: And then I think a huge thing is taking time away, so making sure that this doesn't become everything. And I think at some point, it becomes really, almost addicting, the social clout of getting these likes on things, and views and all that. And so making sure that you have more outside of that too, like I pretty much don't use my phone on weekends, period. I pretty much use it nine to five on weekdays, and that's it. My friends outside of work are always like, "Why are you never on your phone?"
Ali: But I think having that separation is important. I also think that just having coping mechanisms and people close to you that get it, because they think a lot of people who don't deal with the social media stuff don't fully understand it. And so for me, having my podcast co-hosts, we've become incredibly close friends over the years, and they get it. They are people that are also having to be public facing, and so they understand these types of comments and how they can bring things up for you. I think the hard part is oftentimes these comments prey on insecurities that you have, and so you're like, "Oh, they caught me. They figured it out, they're the ones that realized that." So, it's really not them saying it, it's you saying it to yourself, and this being a confirmation of that.
Ali: And so, making sure to take that into your perspective, and say that you cannot be your critic like that, the continuous improvement is really important, but hatefulness and being too self-critical is not good. And there are things that you can change about yourself, and then there are things that you can not change about yourself. And you're not just the things that you're putting out there. I don't know, that's just my two cents. But I think the first thing is just having that patience with yourself, that it is hard, and not being mad at yourself if you're upset over it.
Jeremy: And I think you're right though, trolls are so good. They really know how to push buttons, you know what I mean? And really get under your skin. And I've heard this advice before, and whenever somebody asks me, I clearly don't have the following on Twitter that you do, you have done pretty well collecting quite a huge following, but is just not to engage those people. Just kind of stay away from them, if they make a comment... because you're never going to win. "I was able to change someone's mind with my long response on Facebook," said no one ever. That's sort of how it is.
Ali: Oh, for sure. The one caveat that I will give to that though, is so you're never going to change that person's mind, they're never going to change. But you can sometimes change the people reading it, and so sometimes if you can educate somebody, you're not going to educate them necessarily. But if a thousand people are also reading it, maybe it will change somebody else's mind, and maybe allow them to be more empathetic in a situation like that in the future. So, I try not to engage for the total trolls, the one follower, egg profile picture folks. But if somebody says something that's really sexist or something, or racist or something like that, sometimes responding in an educational way can be helpful to educate the other people reading it, not necessarily the person themselves.
Jeremy: I love that advice.
Rebecca: That is a really good call-out. I'm going to give everyone a peek behind the curtain here. You mentioned the Ladybug Podcast, which I know Jeremy has a question about, but before we get off the topic of learning, you do such an incredible job teaching students coming up. We know on this podcast, there's a bunch of people that are also on the other side, on your side. They're developer advocates, they're on the product side, they're trying to be teachers. And there's something that, not all tutorials or beginner guides are created equal, but what you create and the content you create, really resonates with people.
Rebecca: And so, since we have a lot of listeners out there who are also in the technical community, who are trying to teach, who are trying to be following in your footsteps, and they're trying to share and show and mentor others, I'm wondering if you have any tips for them, in terms of creating useful, accessible, helpful content. Where you're like, "All right, this can be hard. Not all tutorials are created equal, here's a few different ways to think about making accessible content."
Ali: Well, thank you. So, my first thing is having that persona in mind that you're writing to, we already covered that advice. But I even have documents about this, like who this person is that I'm writing to? Who, We Learn Code, which was my blog, who is the ideal reader of that? And so, I think putting yourself in that customer or that reader's footprint, or in their shoes is so important. So, that's the first step. The second thing is that scientifically, people learn best when they're learning the same information in multiple modalities. And so, you can kind of trick people into repeated content if you do it in a different enough way.
Ali: And so, usually what I try to do is I try to give the framing of why something's important, what something is. And then I show them an example of it, but then I also try to integrate things like videos, and images, and things like that, so that people are seeing the same material, but they're able to see it in a couple of different ways, so that it sticks a little bit better with them.
Ali: The other thing that I would say is that it's often, the hardest thing is just putting something out there. Because you're like, "Nobody's going to read this, it's going to suck," whatever. Well, the first thing is that primarily, you're going to benefit from it. Trying to challenge your knowledge and write something about something, is pretty challenging. And so, you have to research a lot to put all these strings together. Even if it's something that you've been using for years, you're probably still going to have to research something in order to explain it to somebody else, in some sort of way. And so, I think it's really, really valuable for you, even if nobody's going to read it at first, that's totally okay. I thought my first blog post got a bazillion views, it was like 37 people and I was like, oh my goodness, that's amazing. I never thought anybody was going to read this.
Rebecca: It is.
Ali: Yeah, it is. It is.
Jeremy: Yeah, no, I love that. The research advice is, because that's the way I am when I write blog posts, is like I start writing and I'm like, "I think this is right. Yeah, that's right. Well, is it right?" And then I got to go check it, and do that research. And then I usually end up learning more myself, and then it just makes for a better post all together.
Jeremy: All right. We're running out of time, but if you've got a couple more minutes, I'd love to talk about the Ladybug Podcast. So, you have an amazing podcast, and it is you Kelly Vaughn, Emma Bostian, Sidney Buckner, and you have topics that cover everything. So, everything from web development, to building your career, to how to nail an interview, a tech interview. I think I recently listened to one about financial planning, or things like that.
Jeremy: So, some of these get super deep and technical, some of them are more focused on your, and the other and the other women on the podcast, their experiences and their stories, which is amazing. So, I have a number of questions, but I guess I'll cut this down. One, how do you pick those topics? Because some of them seem broad, I know they all tie back to tech, and the conversations are great because you mentioned you've all become good friends. You can tell it's just like a friendly conversation between a bunch of women. And if you think this is only for women, I love it, I love listening to the podcast. It's great, there's so much information in there, it's not like it's for women. But maybe you could explain that better than I can, but who is this targeted for? So, if somebody has had the horrible misfortune of not listening to the Ladybug Podcast yet, who is this for?
Ali: Well, thanks. So, we try to balance it out with highly technical episodes, and less technical episodes that are more career focused. And we try to always interview people if it's something that we're not experts in, like financial planning, that one was very much a interview episode, because none of us are certified financial planners by any means.
Ali: And so, I think that again, it's this idea where we have this ideal person in mind for each episode, whether that's somebody who's more advanced in their tech career, or somebody who's more of a beginner. I think we definitely do skew maybe on the more beginner side for our technical episodes, where we're teaching something like React from scratch or TypeScript from scratch. But at the beginning of every season, we pretty much just brainstorm a huge list of potential episodes, and then we all vote on them. And that's the nice thing about having four of us, is that we can kind of say, "Okay, this one would be a really good one. This one might not be good." And then from there, it's just a balance of trying to appeal to the front end developers, for maybe the more back end folks, for people who are newer to their career and more advanced in their careers as well. So, we try to do a good balance of different things within that.
Rebecca: So, you have a ton of things going on and we've covered a huge span. You have a blog, you're on Twitter, you have your own portfolio, you have the Ladybug Podcast. I'm really struggling saying ladybug out loud, this is the first time I've ever noticed that. Can you tell some of the listeners where they can find you if they love this conversation? If they're not part of your huge fan base yet, where should they find you?
Ali: Yeah. So, I'm aspittel pretty much everywhere on the internet, so you can find me there. I think my YouTube is alispitteldev, because I took aspittel accidentally with my personal YouTube. So other than that, that's where I am. Welearncode.com is my blog, so that's kind of the primary thing. But Twitter, YouTube, all the things, try to-
Rebecca: And it will be in all the show notes, so people will be able to click on the link easily. But it's always nice to hear people say it out loud too.
Ali: Yeah, thanks so much.
Jeremy: Ali, this was amazing. Thank you so much for being here, and go check out Ali's stuff. Listen to her podcast, check out Amplify because it's an amazing product. Yeah, thanks again.
Ali: Thank you so much.
Rebecca: Such a treat to spend this morning with you, thank you.
Ali: Thanks for having me.
