EPISODE 1655

[EPISODE]

[0:00:00] ANNOUNCER: Netlify is a popular hosting platform that provides build, deploy, and serverless backend services for web apps. The platform enables deployment directly from source files stored in a version control system like GitHub.

Erica Pisani is a Senior Software Engineer at Netlify. She joins the show to talk about how she got started at Netlify, edge computing, edge functions, private integrations, and more. This episode is hosted by Josh Goldberg, an independent full-time open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ESLint, the tooling that enables ESLint and Prettier to run on TypeScript code.

Josh is also the author of the O'Reilly learning TypeScript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch. Find Josh on Bluesky, Mastodon, Twitter, Twitch, YouTube, and dot com as Joshua K. Goldberg.

[INTERVIEW]

[0:01:10] JG: With me today is Erica Pisani, Senior Software Engineer at Netlify. Erica, welcome to Software Engineering Daily. How's it going?

[0:01:17] EP: It's going great. Thank you so much for having me on today.

[0:01:20] JG: It's my pleasure. I have to note, we will talk about this at the end of the interview. But I'm on your About page on your website, and there is significantly more space dedicated to your dog, Ada, than anything else on that page. That's great.

[0:01:32] EP: Thank you. Thank you. Yes, I feel like of Ada and I, Ada is obviously the one people want to see when they visit my website. So, I made sure to feature her very prominently as much as I could. 

[0:01:41] JG: She's doing great on there. Props to the dog. But let's talk about you for a little bit. You're a software developer, how did that come to be?

[0:01:48] EP: Honestly, it was a little bit of a roundabout journey. I was definitely that kid growing up that likes hearing the clickety-clack of keyboards and I loved playing video games. So, at one point early on, I remember thinking, "Yes, I'm going to be like a lot of developers I imagined. Yes, I'm going to work on video games. It's going to be great." Then, somewhere around high school, I ended up thinking that I think I took like a general tech course in high school, did a bit of programming, and felt like it wasn't for me.

So, I ended up deciding to not continue with it, and instead decided to focus on history, because I just love that subject. A bit of time later, it was like maybe two years after, this would have been like the 11th grade, so I don't know how that translates to 16, 17. I was trying to get courses to work out my schedule the workout, and there was a bit of a clash, and I needed to pick a course to fill this last slot. And it was either hair and makeup styling, which is, if anyone knows me for more than 10 minutes, you know that it's definitely not my jam, or retaking programming.

I had a bunch of friends that were in that class. So, I was like, "Sure. I used to dream of maybe being a video game programmer. I'll take the class again. I'm sure it'll be fine." Around that time, my mom was actually in the middle of a career change. She was going back to school to be a teacher and she was going through teacher's colleges, so that final year in Ontario, where you're doing placements and stuff, and she was like, "Unless you are really set on, like you love history so much, and you really liked the idea of teaching, this might not be for you. So, you might want to consider something else." Because she was just having a really hard time with it.

I never pictured myself being a math whiz. That's kind of the picture I grew up, I guess of software engineers, is you had to be really good at math. You had to be good at stats. You had to be living and breathing code throughout high school, and then you go into college or university, continuing to program. Fortunately for me, honestly, half of my career is just a lucky set of coincidences where I spoke to the right person at the right time.

But I had a classmate that actually was like, "Erica, you're actually pretty decent at this. You should consider studying it and pursuing it as a career." And if you don't like it, you can always go back to studying history." That's what I did. I ended up like going into programming and university, and then there are a few times I almost dropped out like in my second year of university, I almost quit and switched things because I found it not my style. Again, I ended up that - so in Canada, we have this concept of coops. I think they're paid internships in the US, and I had this fantastic coop with this amazing team and they kept me sticking with it and I had these incredible mentors. Then, yes, just one after the next. I ended up in these amazing jobs with amazing mentors and they kept pushing me and helping me be better and got me excited about tech. That kind of stuck with me and here I am today, still describing myself as maybe not the typical programmer, because I identify more as a humanities kid than a science KID. But I still really love technology and all the things that you can do with it.

[0:05:01] JG: There is something kind of funny about the large number of people who achieve titles such as Senior Software Engineer in Netlify, who are still on the fence of whether they compare themselves to a comp sci person. Was there ever a moment in your career when you really started to think more of yourself as comp sci and humanities, rather than just pure humanities?

[0:05:20] EP: Oh, that's a good question. I think, I can't cite a specific moment per se, but I remember when I became more aware of the so-called soft skills actually being very helpful and impactful in my day-to-day job. Especially, fast forward to now, where a lot of us are working in a remote world, things like being a good written and verbal communicator, being able to take these concepts and break it down, and change the language depending on who you're chatting with. Whether that's marketing products, fellow engineers. Even I would argue, and this is my geeky little theory, I think that one of the things I enjoyed about history was seeing how all these various pieces tied together into certain events. I think that, that kind of mindset for me really applies well, in software engineering, as well.

So, when I started realizing these kinds of parallels, I felt more comfortable identifying as a software engineer, instead of being more exclusively like this humanities kid that just managed to sneak in with the cool software engineers.

[0:06:25] JG: For sure. It almost feels on the nose to compare history to software, because we do so much archeological digging within software. But I think you're absolutely right, that a lot of the core skills of explaining, of researching, of learning why, are really applicable in day-to-day development.

[0:06:39] EP: I love that. At least when I was still visiting my old university often and talking with other students that were looking for their paid internships, and some folks had maybe taken computer science as a minor or as a side thing, and they were thinking of transitioning and not feeling it was for them. I think when I highlighted these parallels between whatever humanities or even a science that maybe wasn't - it didn't seem directly related to computer science, but showing how it could be, I think, got more people excited about the potential of working in technology, maybe not necessarily their full-time careers. But being aware of the possibilities that they can bring that into their fields of study.

[0:07:20] JG: Do you have any one particular piece of advice that you would want to impart on anyone who is like you many years ago, now listening to the podcast?

[0:07:28] EP: Oh, I would probably say like, don't feel like you need - this isn't going to be like a very succinct piece of advice. But don't feel like you need to focus really hard on the latest frameworks or the latest technologies. Instead, keep an open mind and stay curious and maybe follow your instincts of what interests you. Because you honestly will never know what thing you're interested in, how that might tie into technology, and you will be that person who is uniquely positioned to be able to draw that relationship together and maybe be able to do something no one else can do. I think that's the best thing I can give us. Just stay curious, stay - just enjoy what you're looking into. Because careers are long, and tech is changing so quickly, and I think just being exposed to so many things is only good for you.

[0:08:13] JG: That's absolutely true. I think it's doubly true, given your career history. Have you ever actually gotten into games? Because it looks like you've had quite a few areas of tech. Everything except that, that original website.

[0:08:23] EP: Never games. No. I briefly dabbled with the idea of as a side project doing a - I always love the game Snake in high school, like on the older cell phones. That's one of the few games that you can have and I love the idea of building a little Nintendo version of Snake where Yoshi is the head of the snake and the eggs pop out. So, that was my only idea of like, "Oh, I can make a game." But after hearing about some of the challenges of working in the gaming industry, I think when I was like in university, GamerGate had happened, and just seeing not just the culture of it, but also just the amount of hours that people are working there. I didn't want to dedicate my life to games. I didn't love it that much, unfortunately. I have nothing against people who love it, like good for you. But I knew that that wasn't my path. So yes, I just never ended up working in the gaming industry.

[0:09:17] JG: So, you worked previous companies, Lever, BenchSci, Way Financial. What's the journey that you've taken? And how did you end up at Netlify?

[0:09:23] EP: Yes. So, I did that in reverse order. I started with small business software because that's at the time when I joined, that was kind of my "area of expertise", because I'd worked at another competitor to Way Financial actually based in Toronto called Fresh Books early on in my career. The reason I jumped a little bit in different domains is a little bit because I like just exploring all these different problem domains. I like just learning new things. When I started my career, I wanted to be truly full stack. I really liked the idea of jumping all over the place. I love that there's so many different problems in both the frontend and the backend. And I felt early on in my career that based on what was needed in my various teams, it tended full stack, tended to mean more frontend.

So, my first two roles at Way Financial and BenchSci kind of gravitated toward that, even though there was a little bit of backend development. But at the point where I joined Lever, I really wanted to do more backend development. It was kind of a sticking point for me that my next role at that time was going to be backend-focused, and that's how I ended up on the API integrations team at Lever. Then, while I was there, I remember feeling like in a way, I was kind of still somewhat doing the same problems over and over again. It was always like the same - I imagine a lot of listeners who have a few years under their belts working in software. You start noticing that you're solving the same problem over and over again, for the same types of customers.

I was telling a friend about this one day, and he was like, "You know what you should try and do, you should maybe look at like the developer tooling space, because that's very different. That's not going to be the stuff you've been dealing with so far. You're going to be working with a lot of people that are like you, and you'll end up learning a lot more than maybe you feel like you're learning right now. That's very different." That's when I started looking into that space. Fortunately for me, Netlify was hiring at the time. Here I am today, almost two years later.

[0:11:10] JG: That's great. How has Netlify been for you? Enjoying it?

[0:11:13] EP: Oh, it's been really great. I'm not saying this, because I currently work there. It has been one of the best places I've worked at. I find that the people that I'm working with are - there's so many experts in different domains that I - especially the first eight months, I felt like such a dummy, where I was like, "Yes, I'm coming in as a senior engineer." And then there's these people who have been like reverse engineering frameworks for how long like Matt Kane, and some people who had worked, like they just know the ins and outs of how like CD ends work, and all this other low-level stuff that I just took for granted about building on the web.

So, it was very humbling when I joined, because I was learning all these things that I just did not think about that are like fundamental building blocks of web development. I don't know of many other places that would be as supportive as Netlify has been, with allowing me to pursue things that I've always wanted to pursue. But they took a bit of time, like conference speaking, which is how you and I met, Josh. So, being able to do that last year was an incredible opportunity and I'm forever grateful that Netlify let me do that, and then just the problems that I'm solving there, I've been able to work in so many different areas that it feels like it's a constant challenge every day, and I haven't been bored since I joined.

[0:12:26] JG: Well, there we go. Your problem was solved.

[0:12:27] EP: Yes.

[0:12:28] JG: I want to jump into one of those areas a bit, because you've given talks quite a few talks, in fact, about the edge. For some, the edge is still kind of a nebulous term. Could you define for us what the edge is when it comes to computing?

[0:12:42] EP: So, I'm happy to give you my definition of and it's the best one I was able to come up with, but also give the one that I've seen floating around the Internet. So, the one floating around on the internet that I've seen before, it's been around since about the eighties, and the edge is sometimes referred to as the network edge. For those who work in an enterprise space, the network edge is probably a term that you're familiar with, and that's where enterprise networks connect to third-party services.

It's still a valid use of the term today. But when we're talking about the edge in its modern context, and we're seeing Netlify edge functions and Vercel edge functions and Cloudflare workers come into the conversation, they're referring to code and locations that are executed much closer to users than they may have historically been. I like to joke that on-premise, becoming a little bit fashionable, again, in the form of edge. That's not entirely accurate. But to some extent, it's a little bit true. Because the edge is entirely context-dependent. The edge, depending on your use case, could be the phone that you hold in your hand for a mobile application, where the application is maybe running some code or storing some data on your phone, as opposed to just storing everything in a server far away. Or it could be a webpage that is caching stuff at servers that are located by cell towers instead of at a very distant server farm in North Virginia or in Montreal, Canada. So, it is a very nebulous term. The best way I can describe it is whatever is closest to your user depending on the problem that you're solving, or the use case that you're dealing with.

[0:14:15] JG: We have the umbrella term for edge, which is as you're describing, putting the logic, putting the code in locations much closer to users. You've listed a few those locations. The phone, the network edge, closer to say, the cell tower, or perhaps the daily compute, if it's actually necessary to be near there. If I were a large enterprise with 9,001 different types of data and compute that need to happen. How do I know which place to put which part of my stack or part of my logic?

[0:14:45] EP: Oh, that's a great question. I hate to be that senior software engineer. It really depends. So, in my research for this, I've read about larger enterprises like FedEx and Walmart, the edge being their own warehouses and them running operations for there. I'm not exactly sure what those operations are unnecessarily, but that is like one example of it. If you're looking at something like, let's say, you have a web application, and you're modifying requests or response headers or applying, let's say, geofencing, like you don't want to allow some people in certain areas of the world to access some content because of licensing agreements. Then you might be looking at data centers that are run by your cloud provider of choice, whether that's AWS, Google Cloud Platform, or Microsoft Azure.

So, yes. If you've got like 9,001 data points, it's hard to say necessarily what that looks like for you, because it depends on the industry that you're working in. Heck, I even remember speaking with someone from a telecom company in Australia that are talking to farmers and there's like edge related to that. I wish I got a chance to talk to that person before I hopped on this call, because I'm very fascinated. But you can imagine that the edge for them might be the various vehicles. It could be the warehouses that they're storing stuff in. It could be a lot of things.

[0:16:06] JG: I think one of the really common use cases that gets brought up is edge functions. Can you describe or define for us what an edge function is, in terms of, say Netlify or typical web apps and websites?

[0:16:18] EP: Yes, sure. So, edge functions are you just imagine your standard, I guess, serverless function, but rather than having it run at a data center in an availability zone, which is what you imagined being the stereotypical data server farms. These are functions that are run at servers that are optimized to run your code very, very quickly. They tend to have much more constrained hardware capabilities than the standard serverless function, but they are run physically much closer to your users than you imagine running that same function in a distance server far away.

[0:16:55] JG: So, from an end-user perspective, what is actually different or behaviorally different about these edge servers compared to say, traditional Azure, or AWS, Google cloud-hosted cloud solutions? 

[0:17:06] EP: Well, as far as developers that are building stuff on the edge, a lot feels the same. There are some constraints that are applied that involve let's say, like, more limited memory, lower CPU time, which is - and I always need to refresh my memory. When I look up CPU time versus wall time, CPU time, referring to the number of operations you can do, as opposed to like literally seconds ticking away on a clock.

So, there are some hardware constraints. But generally speaking, unless you're doing something particularly intensive, moving functionality to the edge generally feels the same as if you were just writing normal functionality in a data center, whether that's like normal serverless functions or an edge function.

[0:17:46] JG: Walk me through an example use case then. Suppose that I want to change some text on the page for AB experiments, and I want it to be very, very fast. And in theory, stretch goal, it would be lovely, if I could base that AB split for people, if they are logged in, not anonymous on their user data in my old user data surface. How would that start to look like in these new edge environments?

[0:18:11] EP: That's a great question. So, assuming that the user is already logged in, and you're rendering, I guess, custom content to this person, what that might look like is, and the example I like to use is, let's say transitioning from a server-side rendered page, because I work in the web space. That's what I'm familiar with. So, you have a server side rendered page that previously would maybe take the data that you needed conditionally render the content and send it back to the user, and maybe you cache that on the user's browser. When you use the edge, what you can do instead is you could take the common elements of that page and make it static. Now, you can cache that at the CDN. So, in a way, the CDN is the edge which is focused on storage, whereas the edge is storage and compute capabilities.

You've got the static value. Then, at the edge, what you can do is based on whatever conditions you need to apply, so using that user, as an example, you want to show a certain piece of content or certain promotional item, or whatever your use case is. What you can do is you can take the response, the static response, and rewrite the HTML, maybe update props, if you're using a React framework, or whatever the equivalent is in your framework of choice. Then, you can return that response to the user. What's also great, and as I mentioned before, the edge also allows you to cache stuff at the edge as well. So, you can cache that response going forward as well for even faster response times going forward.

[0:19:39] JG: If I were to try to make that caching key dynamic, could I then make a completely cached for all anonymous users for speed sake?

[0:19:48] EP: You could, yes. If we're talking something generalized, like a homepage, that's very straightforward to do. If you're doing something that is highly personalisable, let's say, you can cache it, but your cache might not be as long lived as you would maybe ideally want it to be. Just because the cache size available at the edge is much smaller than maybe what you might have available in an AZ. 

That being said, there's ways around that. The talk that you mentioned before, I've referenced that there are regional edge caches available, which they give you a little bit of wiggle room so that you can refer to these edge caches before you have to go all the way to a distant AZ. So, there's that available to you. But generally speaking, yes, you can cache the personal life stuff at the edge by just be warned, it might not be as long-lived as you would hope it would be.

[0:20:40] JG: Sure. That's cool. That makes sense. I want to switch topics a little bit, because you mentioned working on a feature a bit back and that feature is of interest. Private integrations. What are private integrations when it comes to Netlify?

[0:20:54] EP: Yes, sure. So, Netlify has always had, or they've had for a very long time, this concept of integrations. And it's mainly focused on hooking into the build system. What private integrations is, is it's not only - so we're trying to allow folks to do much more on the Netlify platform than just hooking into build events. We're trying to make it easier for external developers to maybe create custom tooling that leverages more of Netlify's products, including Netlify functions, to build events, or to build hooks that I mentioned before, and maybe going forward other stuff as well.

Private integrations allows folks to package whatever custom repeatable things that they need for their sites, make it integration that is available only to their team, and be able to distribute it to all users that use their Netlify team. Yes, we think it's going to be pretty exciting for folks that maybe just have stuff that they're sick and tired of everyone having to just run a PMI for this one specific package. Updates are just rolled out a lot more easily with the use of something like private integrations.

[0:21:56] JG: Do you have an example of an update or a set of things that someone would want to package into an integration?

[0:22:02] EP: Yes. So, the first integrations that we've - so, this is a public integration, not private. But one of the first things that we switched over was Sentry. We had like two different Sentry integrations, and we package them into one. But something that like where, let's say someone wanted to extend that further, let's say there's like another feature of Sentry that's not available in there, and they don't want to wait, and they also have some extra stuff that they're doing on the side, maybe because they're doing a migration between BugSnag and Sentry. Someone could package a private integration that maybe sends events that they need to send to both parties while they're in the middle of that transition, and then allow people to install it on their sites as they need it.

[0:22:43] JG: I can see this being the big timesaver, as you mentioned, especially for larger teams, where their entire teams or sections have dedicated to helping other teams spin up new products or services.

[0:22:52] EP: Yes. That's the hope, anyway, just kind of remove a lot of the toil that we sometimes deal with.

[0:22:58] JG: Let's hone in on that, in the general sense. The industry we're in, programming, always has these cycles come through that, in retrospect, seem obvious, but in foresight are hard to detect. We keep making things that were difficult, easier. We're automating, we're finding better ways to do things. And we've already touched on two points for that. The edge, which makes it easier to put stuff closer to users and have more finely tuned computing. Then, the things like integration. So, which quite a few companies are doing something, like the ability to package little reusable chunks of logic or code. Do you have any other particular areas in Netlify you're excited about on that trend of making things easier for people?

[0:23:35] EP: Personally, and I know this isn't like a Netlify roadmap item. But for me, personally, I want to make it really easy for folks to create more environmentally conscious software. It's the best way I can describe it. I saw Sara Bergman do a talk at QCon London, I think it was last year, and she talked about the Green Software Foundation and what they're pushing. And there were other talks like it, but I got really motivated when I realized that I work in a space where developers are interacting with us all the time, and we're helping them build software, ideally faster, easier, more bug-free. At least for me, I'm now having kind of like, I've seen the light a little bit where it's like, "Yes, this is huge problem." I'm trying my best to keep my eye out for opportunities where I can highlight some of the things people can do to improve, I guess, almost the energy efficiency of their software, or at least highlight things for people to be mindful of as they're building software so that we can try and reduce the carbon footprint of the things that we build, and that people are using every day.

[0:24:45] JG: Do you have an example of a good technique that can help folks build more efficient green software?

[0:24:50] EP: Well, I'm going to sell the edge on this right away. The edge is one area where people can look to adopt it for maybe some high traffic, but very focused pieces of functionality. So, I mentioned before about setting request and response headers, AB split testing is another great example, setting session cookies. They're all things that we do on thousands, hundreds of thousands, sometimes millions of requests. Even just like small little things that move to the edge, and if you're caching very popular requests at the edge, the reduced energy that's consumed from transmitting that data can add up to something really meaningful.

I know generally, measuring these in more concrete terms can be a bit challenging, because you've got geographic considerations, you've got the machines that people are using to make the requests, you've got cloud providers that have various pieces of hardware running that all tie into this. So, I know the hard data is sometimes a little bit hard to come by. But generally speaking, it's safe to say that the most environmentally friendly thing is to not run things, if you can at all, avoid it, or reduce the amount of machines that you're running. If you have to run these things, make sure that they're fulfilling it as fast as possible, or reduce the amount of machines needed to fulfill that overall request. So, that's where the edge can be kind of helpful as it can reduce that need, maybe, for bigger databases, potentially, on your use case. Reducing the distance that the request has to travel, which means not just better performance for your users, but a reduced environmental footprint, because the resources that are making requests aren't waiting idly for as long and consuming electricity just waiting for a response to come back.

That's the two little things, but I think that's one thing that people can do to at least start moving in that direction. And, hey, you get better performance out of it, which is win-win all around.

[0:26:34] JG: That's a win for the users, win for whoever has to foot the bill for your servers.

[0:26:39] EP: Exactly.

[0:26:40] JG: It's funny, there's been a lot of talk about accessibility, about how there's a concept of this electronic curb cut. Things that were maybe originally intended for one segment of users, for physical curbs, that was folks in wheelchairs, and are actually also very beneficial for other segments, such as people with a lot of shopping carts or wheel strollers. Then, what you just brought up strikes me as a parallel to that, where one avenue of exploration could be tried to make more green software for the very noble good cause of destroying the planet slightly less.

But also, there is the really strong business use case of paying less for servers and giving a better experience for users. It's kind of fortuitous that those all kind of blends together and work well.

[0:27:19] EP: Yes. I think it's worth calling out too, just from an accessibility standpoint. I think one thing that we do need to notice, especially, for bigger companies that are operating in different places all over the world. I think one thing that, especially, folks like me living in North America with pretty reliable Internet access, it's not always true for a lot of people, and something like the edge where you focus on running things as close to the user as possible, in a way that they don't need to rely on constant Internet access for the functionality that they need to work reliably. I think that that's something that is worth keeping in mind.

Because yes, depending on who your users are, your business product may fail if your users are folks that live in areas with unreliable Internet. So, I think the edge can help at least make some software much more accessible than it has been previously.

[0:28:11] JG: Let's talk about that a little bit. Suppose I'm in rural farmland or a city with overworked overloaded ISPs. What about the edge makes it so that I would be able to better use a company's services, and ideally, also pay for those services as a user?

[0:28:26] EP: Yeah, so there are some design patterns out there that leverage this a little bit, and there's also some products out there that they are a form of cloud computing on the edge, but they're targeted toward people that aren't entirely remote. Talking about the design pattern first, I saw this in a talk, his name was [inaudible 0:28:44]. I think if I pronounced his name right. If you're if you're listening, Carl, that talks about offline first architectures. So, the idea being that you have this device or you have the server that all these other, I guess, nodes, so other applications, other machines are making requests to, that or updating data. And the requests aren't immediately going to the remotes or to the AZ data center that's storing the majority of data. Instead, it happens every so often, or when the network becomes available again.

That is one approach where the edge can help keep things accessible, in let's say, your overloaded ISP example, where you just wait until something becomes available, you try a few times, and then eventually it gets going. But at least the people that need a response now are able to continue what they need to be doing.

The other bit with hardware, then this like blew my mind when I found out about it. I didn't even know about it until someone that I used to work with, who worked at AWS briefly told me about it. There's devices out there that in this case, AWS Snowball, that it gets shipped to you and you just like hook it up to your servers and it gives you cloud computes right on site. So, you can keep it around to run cloud compute functionality, but you can also use it in situations where you maybe need to migrate a lot of data and you're a bit constrained by the bandwidth and being able to upload the data fast enough, given your intermittence, or non-existent Internet access.

So, in such a case, you would just load it onto the device, ship it back, and it gets uploaded to the cloud for you. Then, there's much more like scaled-up versions of that storage thing. I think the one that most people know about is snowmobile or something, with the giant transport truck that gets driven out. But Snowball gives you compute capabilities, not just storage.

[0:30:29] JG: It's UPS for your data?

[0:30:30] EP: Basically. I know there's some joke on the Internet around like NASA and cassettes and a station wagon or something, that it's kind of that problem.

[0:30:38] JG: That's the funniest thing. We've gotten so advanced at storing our data that we can now ship exabytes of it manually to your needs.

[0:30:46] EP: Exactly.

[0:30:48] JG: I love it. So, green software, highly efficient software, sustainable software. This is a relatively newer area, at least public discourse. Although, I know quite a few folks have been working on this for a while. Is there some kind of sustainability guideline from a larger consortium that we can refer to for how to build this kind of software?

[0:31:05] EP: Yes. I actually found a - I think it was in last September, the W3C published these web sustainability guidelines that people can refer to, and they cover sustainability from a number of different angles. Accessibility is one of those components, environmental is another, social equity is another. That doesn't cover the whole list, obviously. But that's one document that's pretty easy to digest. It's not when I read it, it wasn't overly dry. I know some specifications can go on for a bit. But these were very shortened to the point and very helpful. Although, it's not a spec, I would encourage people to maybe take a look at the Green Software Foundation that I mentioned earlier, because they do have design patterns and resources that people can refer to, that also can help guide people toward making more efficient software, that also will end up reducing your spend, more than likely.

[0:31:54] JG: That's great. I want to end the interview with a few fun questions. We started talking about your dog. Could you just give us a little more information on your dog?

[0:32:05] EP: Oh, yes, I would love to. So, her name is Ada. She is not quite two years old yet, and she's one of those poodle mixes. I know they're quite popular. She's Bernese Mountain Dog Poodle mix. Honestly, she looks all poodle. She's got legs for days. Yes, she is a joy. She likes to sit at my desk when I'm programming and somehow get involved in all my meetings. She's just in general, a very happy being. If folks want me to post more pictures on Twitter, you're going to have to pay me for them. But she also has her own Instagram, if people really, if they want to follow her. It's like ada.beanz.

[0:32:41] JG: Completely or mostly unrelated, you have something called the 418. What is the 418?

[0:32:49] EP: So happy you have asked me about this. The 418, and for the folks who are very familiar with the HTTP status codes, is like that teapot. One, which I thought was a nice fun one to name a zine, which is what this is after. The 418 came out of this idea that I've been kicking around in the back of my head early last year that I told a friend of mine, Christina Berger, who was my co-founder in this, about this idea where I wanted to capture that excited, inspired feeling that I was getting from interacting with so many awesome people at conferences, where we're not just trading ideas about what cool things technology is doing in our lives. But also, just the fun hobbies that we were having, and how they may be - whether or not they tied into technology, but just generally just having fellow tech people that we just were excited about different things in life.

In general, it tied into this feeling too, where the traditional tech meetups didn't really feel like my place. I just never felt like I fit in. I pitched this idea to Christina like, "Hey, what if we take a page out of this playbook that goes back to the, at least, minor exposure of - it was the nineties with the riot girl movement. I had read a book a few years ago about how zines were part of that culture, with trading ideas, and art, and building a community across geographic distances. And why don't we do essentially a tech version of that, and the 418 was born.

So, we're actually really, really close to putting out our first issue. We got a couple of features from some fantastic people in the industry. We also added a few fun things in there. I even built a crossword puzzle for this, which I was like so excited to do, and I hope that the people who do, do it, have a good time with it.

[0:34:36] JG: Sorry, I think we need to clarify. What is a zine? And is it not pronounced design?

[0:34:41] EP: I'm going to say zine. I'm not going to get into that holy war of whether it's a zine or zine. But a zine a much more - so, you imagine a magazine, it's super glossy, it's professional. It's got like a team of 20 people or so working on it. A zine is a much more small-scale, homespun version of that. It's often people who are artists, that are maybe trying to show a story or something and they're drawing it out themselves, or way back in the day, some people would like cut out magazine things, glue stick them on paper, and then Xerox it and send it off to people.

They also have some routes exchanging really ambitious ideas, stuff that maybe wouldn't get published in mainstream publications. They have a really fascinating history to them where I think they date back like as early as the 1940s, and they provide a picture for people that do study history of what life is like in different communities, because this was the way that they communicated, was maybe through the circulation of zines. Yes, they're everything from art projects, to political statements, to just sharing a love of a particular niche interests like gardening. It can be so many things. So honestly, if people wanted, like, just a sense of just how many there are in the world go to like Etsy zine category, because there's so many different things out there, and that's just touching the surface.

[0:36:00] JG: So, the 418 is a zine about tech and adjacent areas?

[0:36:05] EP: Yes. So, I guess our slogan on is like thoughts on tea and tech, although we don't focus too much on tea. But our general theme is, what are the things that we would talk about with our friends over tea? What would make us excited? What would we have fun doing with our friends? That could be talking about this new recipe we're trying, or working on a puzzle together, which I think that might be a very Canadian thing. I don't know. There's like this trope of people who - I don't have a cottage. But for people who do have cottages. They go up in the summer, and they have this big newspaper crossword that everyone works on over the course of a weekend.

So, I don't want to spoil too much of what we've gotten there. But it's meant to be things that you would do with friends and exchanging ideas that we get really excited about with tech, that keeps us excited about all the things that are happening in the industry. Because it's not necessarily the newest framework, but it could be how tech is being applied in that particular area of our lives.

[0:37:04] JG: Well, that might have invalidated my next and last area of questioning, but I want to talk to you a little bit about that, what's coming next in tech area. You've looked at and worked with a few different areas, more recently Netlify, edge private integrations, and we've talked a bit about the how things are making it easier for folks to develop. What excites you about the next 5 to 10 years in tech? And where do you see your personal areas going with that?

[0:37:26] EP: Oh, well, that's a hard question. I sometimes don't even know what I'm doing next year, sometimes in tech, because it changes so quickly. I think, at least, I can't speak to 10 years, but at least for the next 5 years, I am really excited to see the focus on the impact of software that we're starting to see. Just like with AI and things being able to run much closer to people, on much more powerful hardware. I can't even imagine the different things that are going to come out as a result of all that power, basically, being available to us. At least for me, I'd love to continue working with developers and chase my newfound passion to figuring out how to maybe push green tech-forward, because I think it's super important, especially, right now. Yes, I hope I get the chance to make an impact there over the coming years.

[0:38:24] JG: Well, that's an excellent note to close out on. Erica, this has been fun. Is there anything else you would want to cover or mention before we hang up?

[0:38:30] EP: No. I think that's it. Thank you so much again for having me on the show. It's been a pleasure chatting with you.

[0:38:36] JG: Cool. With that, this is Josh with Software Engineering Daily. Thanks, folks. Bye.

[0:38:40] EP: Bye.

[END]
SED 1655		Transcript

	(c) 2024 Software Engineering Daily