Screaming in the Cloud - Episode 62: Serverless Storytelling with Anna Spysz

Episode Date: May 29, 2019

About Anna SpyszAnna Spysz is a writer turned software engineer at Stackery in Portland. When not software engineering, she likes to travel, play music, and kung fu fight for fun and profit.Links Referenced: https://www.stackery.iohttps://medium.com/@annaspies

Hello and welcome to Screaming in the Cloud with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode of Screaming in the Cloud is sponsored by N2WS. There are a number of backup solutions that are available in AWS, including the recently announced AWS Backup. Well, AWS backed the f*** up.

Backups are incredibly easy. Restores, however, are absolutely not. You want to find out that your backups work well in advance instead of the way that most of us do, when they don't work quite right immediately after you really, really, really needed them to work correctly. Check them out at n2ws.com. That's n2ws.com. Thanks to them for supporting this ridiculous podcast. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Anna Spies, a software engineer from Stackery. Welcome to the show, Anna.

Thank you. So you're one of those people with a fascinating and quote-unquote non-traditional paths into tech. What did you do before you were a software engineer? Well, a lot of things. So I started my career mostly in the sphere of writing and journalism with some translation on the side. I was a liberal arts major, and you know how well that pays. So I did a few stints as a journalist. I went freelance for a long time, which was nice, but it was a hustle. It was very much a hustle. And the last actual job I had, I would say, was as a tech journalist. And that kind of brought me in the sphere of startups and tech and all of that. It's interesting watching people who have come from alternative backgrounds, namely the liberal arts seem to be a terrific breeding ground for this,

where you don't have the same exposure in many cases of the, I guess, traditional paths for startup software engineer types, such as, which usually looks something a lot like, well, I got my first computer when I was five years old. I was always playing around with that. I went to an important, impressive college everyone has heard of,

because I've mentioned it three times in this sentence already. I went to an impressive college everyone has heard of because I've mentioned it three times in this sentence already. I've studied computer science because of course I did. And that's why after all of this, I'm making the world a better place now at Twitter for pets. And it's a common story to the point where we almost start to think that's the only way to get there. Where if you didn't have that background and, oh, you didn't start using a computer until you were in your teens or your 20s, oh, forget it. You're never going to be a success. And that is very clearly not true. More to the point, something I've always seen is that when you come from a nontraditional background into this world of technology,

you bring things from alternate fields that really tend to shine a light on things. How do you notice that your background has impacted what you do? Well, first, I kind of want to add on to that because while I completely agree, I feel like I've always been a little tech adjacent. I was, even as a freelance writer I was still like coding my own website and just hacking enough together CSS and HTML to make things work I would you know make little sites for friends bands and stuff like that I had a GeoCities page not to date myself back when I was you know a teenager i remember those days whatever happened to those i know um i believe there's a little thing called the internet archive that

might help you with that but um yeah so i feel like it's totally possible to go from um a non-technical background to a career in tech, but I also feel like that interest has to be there. Like if you're doing it just for the money, just because you're like, oh, developers get paid well, I want to be a developer. I don't think they'll work in the longterm, but if there's like a hint of interest for a long time, I think that at least from what I've seen in colleagues, I think they'll be a better indicator of long-term success in this field. So, okay, that was my diatribe on that. What was your actual question? No, I like the diatribe.

Let's stick with that for a minute. I think that's the problem that I've had with that approach. And at first, I don't think you're wrong. I think there has to be some kind of affinity for technology or you're not likely to go very far in this regardless of who you are. If you don't have a passion for it, you don't enjoy it, and you just show up and drag yourself in front of a computer for 40 hours a week because, hey, I hear it pays well. It doesn't go super well.

You want people to have an interest and a passion for this. The challenge I see is when that starts translating into job requirements, where it's, you must absolutely be in love with technology. Oh, you work a 40-hour-a-week job doing software development. Cool, awesome. What GitHub projects are you doing on the weekends? And that isn't something that's particularly fair to folks with, I don't know, families in my case or lives in other people's cases. And it just seems that it turns very quickly into something that's not particularly pleasant.

Yeah, I completely agree. I think I'm very lucky at Stackery. Like half of us, you know, have people there, have kids. And work-life balance is very important. And I, yeah, if I code on the weekend, it's for some pet project that I'm really excited about and feel like doing. But most of the time, I'm just like taking a hike on the weekend or watching Game of Thrones, you know, having a life. I think you're right. There's an awful lot of value to having interests that go beyond tech,

which brings us back around to the question of how do you find that having a non-tech professional background has impacted what you're doing professionally now? So I think the most significant part of my background is being having been a professional communicator it definitely helps in what I've been doing a lot of what I've been doing is on the documentation side of things as well as actually writing code for our app part of this is because we're still a small startup. There's not that many people. It's something I fell into. And I feel like I have a passion for communicating how to actually use the things that we're working so hard on, how to make it as accessible that might be new to tech and be able to read a tutorial

and actually succeed at the thing they're trying to do rather than spend hours fumbling through the docs, trying to find the one thing they're trying to do. And it's something so absurdly simple that the person writing the docs didn't even put it in there because they're like, oh, everybody knows that. But it turns out not everybody knows everything about your app like you think they do. So yeah, I think it's definitely helped in that just being able to talk about the product, being able to make tutorials and communicate what we're doing in a way that brings people in.

Once upon a time, back in the year of our Lord, 2012, I watched a conference talk that was borderline transformative. It was before I was on the speaking circuit myself. It was about, it was from Jordan Sissel, the author of Logstash, which later became part of the Elkstack. He works at Elastic now. But that was one of the inspirational talks for me that made me think, wow, I'm not super good at computers, but maybe I could learn to give talks one of these days. Because his entire theme of his talk wasn't about, this is how the code works, this is what it does under the hood, look at how clever I am. His thesis instead was if a new user has a bad experience, that's a bug. Your documentation is at least as important as your code.

And I was sitting there and my first response was holy crap, that's transformative, that's important, that goes beyond any individual technical implementation. And secondly, right on the heels of that was, holy crap, again, I'm not a moron. This stuff is just badly documented. And once you start seeing that, it's almost impossible to not see it. And generally speaking, in the modern cloud ecosystem,

that is getting better. But I don't think it's there yet. And I still see there are things that wind up not quite getting where it needs to be. I will say when looking through Stackery's documentation, it's very well written. Your impact is felt. Well, thank you. At least traditionally, it feels like most documentation was written by engineers. um the you know traditional computer science degree engineers you spoke of earlier and it kind of shows because it's um uh well i won't mention some uh certain cloud giants who make a uh possibly deliberate puzzle of their documentation. But yeah, it's just, it's not intuitive.

It's not, it doesn't tell a story. It doesn't guide you from one step to the other. It's very like, oh, here's how we do this thing that we know all about and you know nothing about, but here's just some raw data. Yeah, well, I will throw stones at a large cloud provider where recently AWS, recently last year, AWS dropped all of its documentation into a bunch of GitHub repositories and said, hey, if you find a bug in the docs, you're welcome to fix them, which I'm conflicted on.

Because on the one hand, that feels like an awesome way of opening things up and letting us actually get things that annoy us fixed. On the other, your company keeps flirting with a trillion dollar market cap, and you're asking me to volunteer for you? What? It feels like they're almost, and I don't think this is their intent, to be very clear, but it does feel in some ways like they're trying to put the burden of good documentation onto the community rather than hiring people who are themselves excellent writers. Right. I mean, I think it's not just them. I think it's just docs are an afterthought. Let's build our thing and then eventually we'll teach people to use it

maybe or they'll figure it out. But I don't think that's the correct approach. Once upon a time, because I have many sins and I was forced to pay for them, I was heavily involved with the Freenode IRC network. I was volunteer staff for about a decade, which pro tip, don't do that. It was fun. It was enjoyable in ways, but it also had challenges that came with it. But as a part of that, I learned to ask questions in textual formats pretty effectively because no, whenever you hit a bug somewhere in a software program where you get stuck, no one has the context of everything you've been working on in your head and spending four hours getting them up to speed on that context just isn't going to happen.

So stripping it down to a skeleton case of I'm trying to do X, I'm seeing Y. When I look at the documentation, this thing should be happening, and oh dear, I found a bug. And by framing the question that way, you either wind up realizing that you misread something, and more often than not, in my case anyway, and you were wrong, and you never have to ask question that way, you either wind up realizing that you misread something, and more often than not, in my case anyway, and you were wrong,

and you never have to ask anyone that question as you're building that, or you discover that there's a bug, either in the code or in the documentation more often. So once you keep running into that, it's easy to assume malice, where people are writing crappy documentation because they want to be exclusive keepers of the fire, I guess. And I don't think that's ever been anyone's intention. I think instead it's largely been around just, you're right, it's an afterthought. How do we fix that? Yeah, it's just simple neglect.

It makes sense in startups when, you know, there's five people and they're working really hard just to build the thing. But I think, yeah, how to fix it is put a priority on that and hire people who are not just engineers for the documentation. Like you almost need this combination of somebody with some sort of communication background that also understands the technical aspects of the product. That seems like a good point for us to segue. As important as documentation is and having a background where you can speak to folks who do not themselves come from a steeped in code background where all they speak is in ones and zeros. Let's talk about actual software development for a minute here. You've been working lately, to my understanding, on the idea of local development, particularly for serverless. Tell me a little bit about that. Okay, yes. on the idea of local development, particularly for serverless.

Tell me a little bit about that. Okay, yes. So this is a pretty exciting thing we've been working on at Stackery. So it stems from this problem that serverless changes local development. So like in a traditional workflow, you had your code, ran local host, you did your thing, sent it off to DevOps when it was ready to be deployed. But in serverless, it's very different because you have cloud resources that are a part of your application. You have to run your code against those managed services.

So this is the problem we've been trying to solve lately. And it's something we've run into ourselves because we're a serverless shop. Well, just to throw my own bias out there, and I'm absolutely not contradicting you, your company, etc. But my approach has always been that local development for me has been largely a bit of a boondoggle when it comes to anything that approaches cloud. Because you're going to wind up first building like crappy versions of whatever those cloud services endpoints look like. There's going to be inconsistencies that creep in.

It turns out that I'm super good at mocking cloud services in a sarcasm sense, as opposed to doing it in code. That misunderstanding led to my entire current career path. But what I don't understand, personally, is the value of local development for most workflows. Can you help me get there? Okay, so it's about speed, basically. So yeah, like you said, like mocking, first of all, it takes time. You have to mock out all your services, get the events, etc. And it's not faithful to your actual cloud resources. Your permissions probably won't match.

You know, you have to hard code your environment parameters, and that also takes time. So the other option is just to code and deploy, code and deploy, but that takes a few minutes between every deploy, and it's like, you know, the waiting to deploy, waiting for your deployment is the new waiting to compile, you know? And so that's also wasteful. So our solution... I consider that my coffee time. Well, true.

But if you're doing that, you know, 10 times a day... Oh, yeah. I start shaking by about two in the afternoon. Yeah. And you get distracted and you open your email and you're like, oh, the thing's ready. What was I doing? So no, so our solution to that right now is you have your local machine. You have your Lambda code running on that.

And it is actually interacting with deployed cloud services. So say you're working on a new app, right? You first architect it. You get, say, an API gateway going to a Lambda, going to a Dynamo table. And you architect that, you push it up to the cloud, you deploy it out. It's on AWS. You have the endpoints, right? You have all the permissions set in your template.yaml or whatever you're using, and it's out there. So we've got a command on our CLI that just came out called stacky local invoke. And when you run that, you are testing your actual code on your local machine against those cloud resources. So you can read data from your table. You can write data to said table.

You can trigger events from that endpoint. And what you're doing is iterating and then running against those resources with the same permissions, same environment variables in real time, and it's like a three- to seven-second delay rather than a few minutes for every deploy. So, I mean, in my own workflow, I've been testing this extensively for the past few weeks, just like building my own pet apps at work for like our change log and stuff. And it's just, it's a game changer.

Like I can actually see what I'm doing, interacting with the cloud. I can catch like, oh, I missed a, I forgot to close my brackets and the whole thing crashed and I didn't have to deploy this out just to find out I forgot to close my brackets and the whole thing crashed and I didn't have to deploy this out just to find out. I forgot to close a bracket. It's a huge thing for me anyway. This is probably going to wade into territory

where I start getting angry emails, but it sounds almost like this is not as much local development as it is almost hybrid development, which I don't know if I've ever heard the term before. Please don't tell me I just coined that. Yeah, you probably didn't, but you may have. Uh-oh. It feels like whenever I talk to people historically about, well, I'm not a big believer in local

development. I prefer remote development, especially given that I tend to travel with an iPad. I tend to do all kinds of different things. And we all talk in the SRE devop slash sysadmin slash whatever world we're calling it this week about you don't want cattle you want pets but your laptop is the most precious pet of all because your development environment takes four days to build then okay so i i want to be able to build all this stuff on my laptop when i'm on a plane and there's no wi-fi cool that that's the use case people bring up, and I understand

and respect that, but I fly 110,000 miles a year. I don't find myself mid-air without Wi-Fi needing to write and deploy code all that often. It feels like that's happened maybe once in the last three years, and admittedly, I'm not a software developer as a primary function, but it is something that strikes me as a bit of a constrained use case. So what you're describing does, to my understanding, require access to the internet. Yes. Yeah, very much so. And that's the thing, like, this speeds things up to the point where hopefully you finish what you're working on before you ever get on the plane, and then you can enjoy your in-flight movie, you know. Absolutely. Or everyone has a plane drink. Mine has always lately been the gin and tonic out of a mistaken belief.

It'll protect me from whatever the rest of the mouth breathers on that plane are infected with. It doesn't work, but I pretend it does. And that makes it better. Oh, yeah. I mean, especially on overseas flights, you know, I just keep the red wine coming and that's it. Exactly. And it's great. It leads to some hilarious commit messages right around drink four.

Yeah, and that's probably not the optimal way to work on your app. You'd think that. I get incoherent, but my code gets better. To be fair, it's my code. There's really nowhere for it to go but up. Usually baseline is it's hit rock bottom and started to drill. Well, I mean, it's like, you know, as Hemingway said, right trunk edits sober. So as long as your code reviewer is sober, you're probably good. That's a whole separate argument for another time. So I guess from what you're describing is local development is invariably on your done on your laptop,

or I mean, I guess to some extent for what I've been doing lately, I've been having the quote unquote local portion of that living on an EC2 instance, just because that's somewhere in a constrained environment. I don't have to worry about data leakage. I don't have to worry about dropping my laptop into the bay like the last time. And it gets to a point pretty easily where at that point it's quote unquote local development.

But even with a hybrid model, everything lives in the cloud somewhere else. Is there a use case where I want to go ahead and be able to do that, where something has to be run locally? Well, I mean, one way or another, like you're committing to get all your stuff somewhere safe, hopefully. Yeah, if you're committing to get, then you can drop your laptop in the ocean and it'll still be there. So, yeah, I don't see why you would want to go fully local when, at least when you're relying on managed services and you want to make sure not only your code works, but all the

permissions are okay, you know, that all the permissions are correct, that you're able to interact with the resources you need in the same way you want, you know, in the same way you would in a production environment. So, yeah, no, what you said about hybrid is completely accurate. Like, the actual code you're working on, the lambda you're writing, that is on your machine at the moment, but it's also in Git, so it's not fully on your machine. But everything else is in the cloud. And the only reason you have your Lambda code locally is just so you can iterate a lot faster. And granted, I have not tried your EC2 method, but it sounds a little bit more complicated.

Just going to throw that out there. Sort of. I mean, not to be prescriptive, I think everyone has a development workflow. But again, I come from a grumpy sysadmin background, which we call sysadmin because there really isn't a second kind. And my editor of choice for 15 years now

has been VI or Vim. And that's one of those things you can use anywhere. I would agree with you. If I were doing something like Visual Studio Code or something more complicated with an iPhone IDE that has a visual representation, yeah, that would be a living nightmare. I'd probably want to do something like run it on, if I wanted that same model, I'd use something like an Amazon workspace, like a virtual desktop that lives in the cloud. But for what I do and the way I do it, probably incorrectly for modern iterative purposes, but retraining me takes work and time. It doesn't matter. I need something that I can SSH into, and that's all I need for any form of development that I tend to do. I am absolutely not suggesting that that is a best practice.

I'm not suggesting that would necessarily work for other folks. But for me, at least, it seems to have worked out okay. Yeah, no, that makes perfect sense. Like, I am a VS Code girl. I like my IDE. I like having all my, you know, folders neatly organized, et cetera. I like, etc. I'm also a very visual person, I just like seeing everything running in the terminal along with my code. So I think that's why I prefer it this way. It also, I mean, to be fair, it's not as simple as I make it out to be in every case,

because say you have a RDS behind a VPC, right? Like, how are you going to interact with that? Like, you need to run a tunnel, most likely. You know, it can get more complicated for sure. But that's also doable. Yeah, I've started playing around in the last six months or so with Visual Studio Code. And oh my stars, this is one of those things that is, I can see how it has the potential to be transformative. I need to unlearn a whole bunch of habits for that to start being something that I use on an ongoing basis. And please, please, please, please, please,

if you work at Microsoft and you're listening to this, get me a version of this for the iPad. I know it's not going to be able to compile a bunch of stuff down locally. I mostly write in Python. I don't need it compiled. Sure, it's going to be limited, but it's so pretty and it's so much nicer. Please build that.

Yeah, that would be sweet. The more I use it, the more I'm starting to realize that there is a whole other world out there as far as using a tool like this that lets you have a bunch of things side by side, being able to take a look at exact runs without getting this all set up in a bunch of Tmox panes

or a bunch of deep dive Vim configurations. It's, again, I do not care prescriptively what editing environment someone uses one of the worst interview questions i've ever heard was yeah what editor what text editor do you prefer which is more or less an invitation to yeah let me either agree with you or call you a moron it doesn't work that way it some of the best developers i've ever known have used joe which is an ancient uh code editor that's uh that goes way back or nano which everyone likes to make fun of because it's it's just what you see is what you get more or less and everyone likes to taunt

these folks it's like so what do you what everybody what are you not good at computers what could you possibly build and the answer at one point was non-trivial parts of Google. Okay, then. It may be judging people by the tools they use isn't necessarily the best path forward, particularly in a career context. For sure. For sure. And there's also the context. I would think most current CS grads and definitely code school grads, at least from everybody

I've met that went through a code school, they're probably going to use an IDE. It might be VS Code, it might be WebStorm or something, PyCharm, whatever. But that's the way that I've seen that development is being taught these days. So it's probably becoming more and more common. And Vim, you know, if anybody ever figures out how to exit out of it, you know, it's going the way of the dinosaur, maybe. The line I've always used was that my wife uses Emacs and I use Vim. And we've been together a decade because neither one of us knows how to clean. And it feels like, yeah, there's a bit of truth to that. I did hear once that someone was debating whether they should hire someone

because that person used Sublime Text and everyone else used other stuff. And, well, Sublime, I think, was $75 or $100 for the editor for a year, at which point I just sort of stared at them. It's, what are you planning on paying this person, buddy? They're going to embezzle more than an office supplies because all of us do. And the coffee budget will be multiple times of that. And are you sure you're focusing on the right part of the story?

It's weird having these conversations with people who just don't seem to get the larger picture. Right. And it's like, you can change your workflow if everybody at the office uses WebStorm. Okay, that's fine. You're not used to it. You can learn in a few days. I don't care if your primary means of writing code is on a legal pad with a pen.

As long as you can solve the problem and deliver the value that you need to deliver, I don't care what the tool looks. At some point, it turns into a, okay, what, are you actually going to do any work? But if you're trying to judge people, for example, by how quickly they can type, that has never been a limiting factor of any developer I've ever known, or at least wanted to work with, because that's not writing code, that's data entry at some point. Yeah, for sure. So as we go, before we go, is there, I guess, do you have any words of wisdom for folks who might find themselves teetering on the brick, shall we say, of coming from liberal arts or writing background who want to wind up potentially dipping a toe into tech? What advice would you give them?

Sure. Well, so my journey was I went to A- code school about a year and a half ago now. But that was only after I had been doing stuff like free code camp and code academy, etc. Online courses for three, four years, just off and on, getting the basics of HTML, CSS, JavaScript down. So I feel like by the time I decided on CodeSchool, it was also like a perfect turn of events that I finished a big contract job. I had a cushion, like I could take three months

out of my life and not have a job and do this full time. But it was also the point where I realized, okay, I do enjoy this, I'm serious about it. And I'm the kind of person that needs a teacher, you know, teacher over me saying like, do your stuff, but also just like people I can ask questions to of when I get stuck so that's why I decided on a code camp but um yeah I would say before you spend a whole bunch of money on a some sort of a real in person course take the time to go through something like free code camp and see if this is actually what you want to do see if this interests you see if you keep going or are you just like you know uh making yourself get through it because then

maybe it's not for you or maybe um there's some sort of like tech adjacent role maybe you want to work at a startup but in a different role than an actual engineer so yeah that that would be my advice um make sure this is what you want to do and then when you do think that's where you want your career to go invest in it um go through some sort of course if you're the kind of person who needs in classroom instruction like I do, do it. It'll be worth it in the end. And yeah, the job hunt sucks at the very beginning. But once you get that first role and hopefully you'll get as lucky as I did in mine, then you can only grow and keep learning.

If people want to hear or possibly read more about how you view these things, where can they find you? I occasionally contribute to Stackery's blog. I have a medium. I can't remember the link to it. We will throw a link to it in the show notes. Yeah, that's fine. That's about it. And yeah, Stackery Docs.

There's a big chunk of my stuff in there. Do a tutorial just for the literary value, for sure. Exactly. Yes, we're using this as a good example. English classes years from now, we'll look at documentation as an example of the modern era. Oh, God, I hope not. Anna, thank you so much for taking the time to speak with me today.

All right. Thank you, Corey. Anna Spies, software engineer at Stackery. I'm Corey Quinn. This is Screaming in the Cloud. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever fine snark is sold. This has been a HumblePod production. Stay humble.