The Stack Overflow Podcast

Living on the Edge with Netlify

Episode Summary

Today’s guests are two of Cassidy’s former colleagues on Netlify’s developer experience team. Director of Developer Experience Phil Hawksworth and Staff Developer Experience Engineer Salma Alam Naylor join the crew to discuss the work they do at Netlify, why ensuring a good developer experience is so important, and why Jamstack deserves a special place in your heart.

Episode Notes

RIP Internet Explorer (1995-2022), “a good tool to download other browsers.” Bummer epitaph, but the meme stands.

Netlify’s unified web development workflow has out-of-this-world benefits for developer experience. Learn more by watching A Tale of Web Development in Two Universes.

Netlify recently announced Netlify Edge Functions, a fully serverless runtime environment. Here’s what that means and how it works.

For more on “The Edge” (not this guy or this guy), check out this episode of the Remotely Interesting podcast, featuring Phil, Salma, and Cassidy.

Jamstack makes developers’ lives “pretty peachy,” to borrow Salma’s phrase. Here, she explains what Jamstack is and how it makes the web (and developers) faster.

Salma helps “developers build stuff, learn things, and love what they do.” She loves helping people get into tech, where she started working after a career as a music teacher and comedian. Active in the developer community, she’s a Microsoft MVP for Developer Technologies, a partnered Twitch streamer, and a relentless advocate for building a truly accessible web. Salma is the founder of Unbreak.tech, Women Who Stream Tech, and Women of Jamstack, projects that call for social change and equality in tech. Connect with her on Twitter or LinkedIn.

Phil is passionate about browser technologies, the web’s empowering properties, and ingenuity and simplicity in the face of overengineering. He has built web apps for Google, Apple, Nike, R/GA, and The London Stock Exchange, and is a coauthor of Modern Web Development on the Jamstack (O’Reilly, 2019). Connect with Phil on Twitter or LinkedIn, or read his blog posts for Netlify.

Today’s Lifeboat badge goes to user Anton vBR for their answer to What’s the function of dedent() in Python?.

Episode Transcription

Salma Alam-Naylor Developers can just concentrate on writing the code and doing the bits that they enjoy. So I think a core part of the Developer Experience team at Netlify is ensuring that people that use Netlify and the associated tools around the web have the best experience they possibly can. Because the more enjoyable your experience is, the more dopamine you get from being able to put stuff online really quickly, when stuff just works and you don't have to pull your hair out trawling through documentation and looking through bugs and spending days on things that don't work.

[intro music plays]

Ben Popper Tired of security bottlenecks? Snyk is a developer security platform that automatically scans your code, dependencies, containers, and cloud configs, finding and fixing vulnerabilities in real time from the tools and workflows you already use. Create your free account at snyk.co/stackoverflow. Head on over, support the podcast. Let 'em know we sent you. 

Cassidy Williams Hello everybody, and welcome to the Stack Overflow Podcast. My name is Cassidy Williams and I am here with my lovely co-host, Ceora Ford. 

Ceora Ford Hi everyone!

CW And we have a couple of nerds here as our guests today. From my old team at Netlify, we have Phil and Salma who are on the Developer Experience team.

SAN Hello! 

Phil Hawksworth Hello. Thanks for having us. This is nice. Nice to see some friendly faces. 

CW Yeah, it's good to have you both.

CF It's exciting to be able to kind of meet you in a way after seeing you both all over Twitter all the time. 

SAN We are real people! 

CW I’m so used to just seeing their faces, but yeah, you get to see more than profile pictures now.

CF Yeah, isn't that nice? 

CW What a concept! So I'd like to start with learning a little bit more about you both and then getting into some of the nitty gritty of Jamstack things and the edge and all of that. And I don't mean Edge browser, although it's a nice browser, and I'd like to say rest in peace to Internet Explorer.

PH Thank you for your service.

CW The day of this recording is its last day and it is dead.

CF Wow.

SAN Should we have a moment of silence? 

CW It would be weird on a podcast.

PH I don’t know if we can have like a distant bugle in the background respectfully bugling. 

CF Every listener just needs to pause for 10 seconds. Pause for 10 seconds and then continue. 

CW Perfect. Speaking of things that are getting old, Phil, how did you begin your coding journey? I can say this because we're friends! I'm not just being rude! 

PH Wow. What a springboard into our conversation. Well my coding journey, back at the very beginning, well, I'm not starting at the beginning of the universe, but my first dabblings with building things on a computer were when I did my art exam when I was 15 on a Sinclair Spectrum writing Basic to make kind of Mondrian squares and lines of colors. And everybody around me thought I was completely crackers doing that. They thought it was, “What are you doing?” No one understood why I was doing that, and I just found it interesting. But I didn't touch them again for quite a while really. I went off and tried to study architecture and wasn't good enough at all of the things you need to do architecture so I went down a different path. And then I completely changed tack and was inspired by some friends of mine who were doing a computer science degree and got interested in it. So I changed course while I was at university and much to the delight of my parents, as you can imagine, who'd been paying for my studies so far, and I went off and did a computer science degree. And didn't enjoy it at all, I'll be very, very honest. There are aspects of it that were kind of satisfying, but largely I did not have a good time. There was nothing to do with the web in that degree, which maybe dates the degree, and by a result, me. So thanks for that lead-in, Cassidy. 

CW You're welcome. 

PH But I did start dabbling with making things for the web just on the side here and there and discovered that I could open a text editor, write some HTML, hit refresh in a browser, and kapow, there were things there to see. So that instant feedback loop was incredibly exciting, and that marked the start of my journey, really. And that was me learning by viewing source, asking people around me for help, learning bit by bit about hotlinking resources from other servers and other bits and pieces that just blew my mind when I hadn't really started to understand what the web was. And I was hooked then. So my studies for my degree didn't necessarily thrive as a result of it because I was a little distracted, but I think it reenergized me to a certain degree and that was where I began my journey, and then off into industry after I graduated doing things with web technology. So that was my route to it. 

CW Nice. And what about you Salma? 

SAN My coding journey is like a play in four acts. Act one was also starting with Basic. When I was six years old, I had a Commodore 64 and a manual, like a very thick manual. I was doing a thickness gesture but realized we're on a podcast, not a video. It was huge. And I would sit there at the age of six and copy out this Basic code from this manual and make stuff happen in the blue terminal, like colored squares and bouncy balls and all sorts of stuff. And the running theme throughout all of these four acts is the fascination that I had with making things happen on a computer. Act two was my discovery of GeoCities when I got the internet about seven years later. And I was building GeoCities websites whenever I could and I had no idea what I was really doing at the time. Act three was when I had a boyfriend who was a SharePoint developer who taught me the basics of HTML and CSS and uploading that via FTP to be on the web. And in combination with that, I was working with an old bit of software called iWeb on Mac computers where it was pretty much like drag and drop images. Websites that were image-based, I mean, I dread to see what the source code is like, but it allowed me to deploy that stuff. And act four begins the actual start of my career in industry, which through a series of very lucky events, I got a job at this very small magazine website house place as a graphic designer and salesperson. 

CF What a combination.

SAN Yeah, long story. But there was one IT person there, his name was Steve, and I'm still in touch with Steve now. We got talking and he noticed my love and passion and excitement about building for the web, and he was the only developer building the CMS, the front end, the infrastructure and everything. So, cheekily, without asking for permission, I moved my chair around from my desk to his desk and he started teaching me the stack. It was PHP, we were writing CoffeeScript and SAS. I was in the deep end. So that was technically my first dev job, and then I got a series of different front end focused jobs, moved up to being a tech lead, and now I am here. 

CW Dang, CoffeeScript. They were arrow functions before arrow functions were a thing. Good times. 

CF I'm not even going to lie, I have no idea about most of the stuff both of you talked about. As someone who's only been around for like a year and a half now, I'm really like, “What?” But I did some Googling on the side so I can have an idea of what's being discussed. I think the natural transition, now that we have an idea of how you got started coding, is to learn more about what you do at Netlify. And once you tell us in the technical way, try to also tell us in a way that a five-year-old would understand too. I like to hear both, because sometimes I'm the five-year-old who has a harder time understanding some of those things. So yeah, just explain to us what you do at Netlify, what your day to day looks like, all that kind of stuff. 

SAN I guess I'll start with a five-year-old definition, which is that I help people build stuff for the web. I help people make websites really, bottom line. Whether that might be how it looks, how it works, where it comes from in the world, when you put a website address into your browser, we can get onto that later. Everything to do with things that you look at in a web browser on your phone or on your computer or wherever you are, I help people make those in the best way I know how to. And Phil, you can do the complicated description.

PH I'll be honest, I think that is the harder one to do, to try and kind of distill this down to the five-year-old friendly one. I think that is the harder one. But so Salma and I work together in the Developer Experience team, and Netlify being a product which is for developers, we're trying to make sure that the first users of our services are as intuitive and powerful and effective as possible really. So I think it's probably fair to say, I don't want to put words in Salma’s mouth, but I suspect that we both found our way there by being enthusiastic about this way of building sites for the web, and found that it got obstacles out of our way so we got enthusiastic about building things in a certain way, and Netlify happened to be the tool that was helping us to do that, or rather the glue that helped us use whichever tools we were interested in is probably a more appropriate way of describing it. Because Salma and I have got slightly different experiences in the way that we've built things, we've got different levels of experiences with different tools, but we both ultimately want to get things out onto the web as quickly as possible and we want to help others do the same. So that really is what we're trying to do. We're trying to help developers understand how they can use the tools that we’re familiar with to solve the problems that they have day to day. And back in my origin story where I was looking at writing things in a text editor and then hitting refresh and seeing them in the browser, that was the thing that excited me, writing first of all HTML, and then some CSS and then ultimately JavaScript, I was JavaScript developer for quite some time. But the thing that I was terrible at is hosting infrastructure. Don't get me wrong, I was very excited building things with PHP, I could get MySQL running, I built lots of things on the LAMP stack. For me, if I was to do that professionally and try and make sure that that was resilient and suitable for the world to come and look at, I was not the person to do it. So there's a long way between being able to do it for you and being able to do it production-level. So the thing that excites me about where we are now is that we're building tools that help people a bit like us. I'm sorry, I keep on putting words in your mouth Salma, I'm sure you'll correct me. But people who build things with web technologies, particularly at the front end, being able to get those things out to the world as robustly and quickly and effortlessly as possible so we can concentrate on writing the code and what I personally find to be the fun stuff. So that's where I spend my time. 

SAN That's the core part, what Phil just said, about how developers can just concentrate on writing the code and doing the bits that they enjoy. So I think a core part of the Developer Experience team at Netlify is ensuring that people that use Netlify and the associated tools around the web have the best experience they possibly can. Because the more enjoyable your experience is, the more dopamine you get from being able to put stuff online really quickly, when stuff just works and you don't have to pull your hair out trawling through documentation and looking through bugs and spending days on things that don't work, the easier and the more enjoyable your experience is the more likely you’re going to pursue this, do it more, do some side projects, enjoy your work more. And I think this was embodied very nicely and immortalized in the new Netlify video that we released. 

PH [laughter] Oh, nice work! Nice work.

CF I like that!

CW Look at that marketing! 

SAN A tale of two universes. If you've seen that, and we can probably link to it. 

CW We'll link to it in the show notes.

SAN I have been in that position where it's taken me days to be able to actually develop something and code something on my local machine if I've started a new job. The archaic systems that Jamstack has taken us away from has empowered us and made our lives pretty peachy to be honest. Am I allowed to say that?

CF Yeah. I think Jamstack has a special place in my heart because, I've talked about this several times on the podcast before, I am a huge fan of the developer happy path, and I think that finding that happy path, especially when you're first starting out, is really important although it's nearly impossible. But for me, any tools or stacks or whatever you want to call it that can make that happy path as easy as possible for newer developers to find, I'm automatically going to be a fan. And I started out dabbling in the front end by getting involved in Jamstack and the Jamstack community and all that kind of stuff. So everything you're saying resonates with me 100%. And I think it's cool that you get to genuinely work on something as a developer experience engineer, as a developer advocate, that you know is actually helping developers and actually legitimately making their jobs easier at large. That must be a really good feeling to have at the end of the day when you finish your work.

SAN I like to try and give people what I needed when I was starting out and what I didn't have, and that makes me feel really happy. I've been through the nonsense, I've been through the bugs, I have pulled my hair out a bit, but you don't need to anymore so you go run free and write your code and enjoy your life and I will revel in your glory and your efforts. 

PH I will revel in your glory, if that isn’t a pull quote for the episode then I don’t know what is. 

CW It reminds me of when there was a point where I was showing a friend of mine Jamstack style web development, which we should probably define that more, but I was showing her how to build it and how to deploy it and everything. And she shipped her website and it was live, and she said, “Wait, that was it?” And I said, “Yeah, that's it.” She said, “Why did I get a computer science degree? This is so easy compared to what I've been learning my whole life.” It was very funny.

PH The nice aspect of that, the “Why did I get a computer computer science degree?” is not to say that once these challenges get out of your way it's like, “Oh, well now it's easy.” I mean, we kind of need to get these challenges out of the way because front end development is hard. I mean, it's easy to do something, but it's a huge world that you open up. So doing the right thing and doing the right thing the right way can be incredibly complex and it's one of those things that just never stops. It's always expanding, it's always evolving. And also, what was the expression? There's probably a proper quote from a sensible person that I should be able to reference, but I just say, “I heard once.” I heard web development being described as the most hostile environment for your code to run, because you don't know what device it's on, what conditions it's in, what lighting conditions it's in, all the rest of it, the capabilities of the person using it. There are so many unknowns. So if you can work on that part of the craft which is ever-expanding and not need to care about some of the kind of fundamental, “How do I serve it in the first place?” If you can abstract some of that away then you can concentrate on the other stuff. And there are a million other specialties and skills that you can focus on just within the front end I think, so that makes me very excited, the fact that people can become real experts in so many aspects of the craft. It’s very cool to see the results.

CW Yeah. Now speaking of all the things evolving and changing and growing, the term Jamstack has evolved a lot over the past year, but also in the past few years. And then there's this concept of the edge which I think many people might think is the internet browser, but no, there's other things. Could you explain how Jamstack has evolved and what the edge is for those who are getting deeper into this end of web development? 

SAN So the term Jamstack was coined quite a few years ago around 2018. I can’t remember the exact date.

PH 2015. 

SAN 2015. It came about from using the combination of JavaScript – J, APIs – A, and Markup – M, to build websites and host it on Netlify at the time. And when the whole concept of serverless and the cloud entered the mainstream webspace things started changing. Serverless functions came to be, so you could spin up little backends and run backend stuff with your site on the Jamstack, and things started expanding exponentially all the different things that you could do with a Jamstack site. And throughout that evolution, we got rid of the J-A-M capital, JavaScript, APIs, and Markup, to just be Jamstack to kind of demonstrate that shift so that it's not just about JavaScript, APIs, and Markup. And to be honest, the core of Jamstack is an architectural approach that's just about serving static assets from a CDN, which is a content delivery network, which is distributed all around the world. So when you request a site that is on the Jamstack, you request a Jamstack site that's on a CDN, you get delivered a cached, static, pre-built bit of HTML asset that is at the closest server node to you. And so that's the original kind of edge, the content delivery network of delivering static assets. And now as the Jamstack has evolved even more and changed even more and brought so many other things into this ecosystem, now we have the edge. And you can compute at the edge, you can run backends at the edge, much like you can do serverless function stuff at the edge, they are in fixed locations. But now the edge, serverless functions at the edge, is what's really even more exponentially growing the concept of the Jamstack architecture. And I like to call these things, and I know Phil does as well, I'm going to put words in your mouth, Phil likes to call these types of things around the core concept of the Jamstack architecture, we like to call them adjacent technologies. Whereas you can harness those technologies when you're using the Jamstack but they're not really part of the core of what we mean when we are delivering static assets from the Jamstack. And what's great about this is that so many different frameworks and static site generators and other tools in the ecosystem are adopting this edge stuff, serverless stuff. Everything is kind of growing to increase the capabilities of dynamic delivery on the Jamstack and things like that. I can't remember what I was about to say, but the Jamstack is an ecosystem centered around the core architectural principles of serving a static asset. And I'm looking at one of the questions on the list you gave us about what annoys you about the Jamstack and actually that's one of the things. It's so blurry and it's really hard to describe this to newcomers and beginners and people who are new to this whole concept because there is so much noise around all the different tools. 

PH Yeah. And I think it's a reasonable criticism that's come our way as well. It's like, as people who advocate for the Jamstack, is this definition a bit blurry? What's going on there? And that's fair, and I think the reason that's happened is because the web has evolved so much. And at its inception, Jamstack was really created to give us a vocabulary to talk about this kind of approach that Salma was just laying out about kind of pre-rendering things and then serving them from whatever infrastructure was convenient to you. And the fact that there was build automation and all this tooling to make that happen all the more efficiently, great, that kind of gave rise to its popularity and what have you. But I remember once giving a talk about Jamstack and one of the questions that came from the audience was, “Is serverless Jamstack?” And I was completely thrown by that because, well, not really, but it is the perfect, as Salma says, kind of adjacent technology. Because the thing that excites me about building things this way and this Jamstack architecture is that I don't need to care about a server. So I think about a build server and getting things out to hosting infrastructure, but I don't need to think about maintaining a server. And that is very much true of serverless functions as well. It functions as a service that we know will execute in infrastructure that we don't care about in the same way that we don't need to care about the CDN, the content delivery network, that's serving our assets. So it kind of fits really nicely and is a perfect extension for that. And now, as Salma was saying, it's now even more exciting that we can not just have things running at request time and serverless functions where we don't need to worry about a server, but we can have those happening at those edge nodes that Salma alluded to close to wherever the user is, and start to even say, “Well, we might know some things about the user based on the fact that it's coming from a node close to them. So we know things about their location, we know things about the time of day,” we can do all kinds of things. That means that we can be very dynamic in the kind of ways that we respond to that. So it kind of unlocks some of the capabilities that we once thought of as being only in the domain of a server side, server rendered thing but without having to have a server. So I kind of think of it as no-server hosting. I'm not going to introduce another term, serverless is already another term, but it's like delivering sites without ever needing to care about a server, even though you can do stuff ‘server side’ thanks to edge compute and serverless. 

SAN I always find it really difficult to talk about Jamstack without talking about the alternative and the old kind of original way that the web was built. Because you could say, “Oh yeah, Jamstack. It's this architecture about serving pre-rendered assets.” But if someone is new to development, they don't actually know what the alternative is and what the problems were in the past, like what you were saying Phil, about servers. With Jamstack, you don't manage your own servers, a web platform takes care of that for you. But back in the day before this whole thing came about, you would have to manage your own servers, scale them up when your traffic increased, security patches, all that other difficult stuff. And so it's really hard to give a definition of the Jamstack because you have to contrast it with the alternative to show the benefits that it gives you as a developer. 

CF Yeah. I'm really glad that you brought that up because I think this is something that maybe a lot of people who work in developer experience and developer advocacy might have to run into, because the whole goal is to make whatever technology you're dealing with as approachable as possible, meaning that someone new to development should be able to immediately understand what you're talking about. And I ran into this same issue when I was working with ApolloGraphQL and GraphQL. Because normally with GraphQL, to explain why it's beneficial, you talk about Rest, but if you're completely new to development, you may not have even ever worked with Rest. So it becomes a question of how do you make this thing approachable for anyone from day one without having to give a whole history lesson. Should you have to give a whole history up history lesson? Is that necessarily a bad thing? I think now because of the kinds of tools that are available, a lot of people want to get up and running immediately. I want to sit down at my desk at my computer and be able to build something without having to know a ton about it. But is that necessarily the best way to do things? I'm asking a couple of questions in one right now, but at the end of it all, I basically really want to hear how you as developer experience engineers deal with this specific problem. How do you tackle that in a way that makes you feel satisfied with the solution, if that makes sense. 

SAN It depends. To quote Cassidy, “It depends.” It's probably entirely personal to that audience, to that situation, to that project. I tried really hard just now not to give all the history, but I kind of felt like I had to in case any people are hearing the term Jamstack for the first time on this podcast. But there are plenty of places that you can go to find out more about the Jamstack if this word is new to you. And they'll be linked somewhere, hopefully? 

CW Yeah! We'll have some very fleshed out show notes. 

PH Can I add one last thought to that also? Yeah, this idea of having an easy on-ramp into starting to build stuff is critical, right? So I really care about helping people find their way to an experience that means that they can start creating and start building things. And lots of services and tools that are around in this kind of ecosystem are centered around that so it’s I think really exciting. The flip side to that is you want people to be able to achieve what they need to achieve as rapidly and easily as possible, but I think there is a core understanding that's important as well. So the more magic and abstraction we introduce, the greater the developer experience can be, but we should always try and keep in sight, ultimately that's in service of user experience. So coming back to that perennial “it depends,” the tools you choose should always depend on the thing that you're trying to create and the users you're trying to create for. I know Salma does a lot of talking about choosing the right tool for the job and what have you. So I think that's where the tension and the kind of craft comes in. It's like, get going and learn as fast as possible and feel productive. Wonderful. But supplementing that with understanding the choices you’re making and some of the things that underly it, that's a really valuable thing too. 

CW Well said.

CF Yeah, absolutely. Both of you, that was two very good answers to the question. And I think one thing that I've tried to do in the past is offer the information if the reader or the learner wants it. So if you are like me and you feel like you need to know everything about whatever it is that you're learning, here's this. If you want to get straight to building and go right on that happy path and just follow the tutorial, then continue ahead. I hope that is satisfactory for people who are consuming my content online but that's a whole other conversation. 

CW Well, that being said, this has been really, really fun. Thank you Phil and Salma so much. 

[music plays]

CW I'd like to award a lifeboat. A lifeboat badge is a badge that is given to an answer score of 20 or more to a question score of -3 or less that goes on to receive a score of 3 or more. The badge can be awarded multiple times. Today's is awarded to Anton vBR, “What's the function of dedent() in Python?” We'll throw that in the show notes. That being said, thank you again so much to our guests. I've been Cassidy Williams. You can find me @Cassidoo on most things. I do developer experience at Remote and OSS Capital. Where can people find you on the internet, Salma and Phil? 

SAN My name's Salma. You might also know me as whitep4nth3r. I'm @whitep4nth3r everywhere on the internet, whitep4nth3r.com, et cetera. And I stream regularly twice a week on Twitch live-coding. 

PH And I'm Phil Hawksworth. My Twitter handle is @PhilHawksworth. I don't have the creativity of people on this podcast it seems. You can find me @PhilHawksworth on most things or hawksworx.com is my website. Sounds like a radio station when I spell it. I hadn’t realized that. And thanks so much for having us. It's been great. 

SAN Yes, thank you.

CF Yeah! And my name is Ceora Ford. I'm a future Developer Advocate at Auth0. You can find me on Twitter. My username there is @Ceeoreo_.

CW All right, thanks everybody. Bye! 

PH Thanks so much. Bye!

CF Bye!

[outro music plays]