Subscribe
Share
Share
Embed
Anna Spysz offers a different perspective, coming from communications first and engineering second. In this episode, she describes the hybrid model employed at Stackery for developing cloud applications that can save time and frustration, plus she’s got a few tips for liberal arts majors looking to get into tech.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Speaker 1: Hello, and welcome to Screaming in the Cloud with your host, cloud economist Corey Quinn. This weekly show features conversations with people during 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.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this way by Anna Spysz, a software engineer from Stackery. Welcome to the show, Anna.
Anna: Thank you.
Corey: You're one of those people with a fascinating and "non-traditional" path into tech. What did you do before you were a software engineer?
Anna: Well, a lot of things. 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.
Corey: 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 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 non-traditional background into this world of technology you bring things from alternate fields that really tend to shed a light on things. How do you notice that your background has impacted what you do?
Anna: 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. Even as a freelance writer, I was still coding my own website and just hacking enough together CSS and HTML to make things work. You know, make little sites for friend's bands and stuff like that. I had a GeoCities page, not to date myself, back when I was a teenager.
Corey: I remember those days. Whatever happened to those?
Anna: Right? I know. I believe there's a little thing called the internet archive that might help you with that, but yeah, so I feel like it's totally possible to go from 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 that'll work in the long term. But if there's a hint of interest for a long time, I think that at least from what I've seen in the colleagues, they'll be a better indicator of long term success in this field.
Okay, that was diatribe on that. What was your actual question?
Corey: No, I like the diatribe. Let's stick with that for a minute. I think that's ... The problem that I had with that approach and ... 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 hears 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 most absolutely be in love with technology. Oh, you work a 40 hour a week job doing software development. Cool. Awesome. What get out 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.
Anna: Yeah. I completely agree. I think I'm very lucky at Stackery. Half of us ... Half the people there have kids and work/life balance is very important. And 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 taking a hike on the weekend or watching Game of Thrones. You know, having a life.
Corey: 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?
Anna: 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 successful to as many people as possible, how to have somebody come in 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.
Corey: 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 … from Jordan Sissel, the author of Logstash, which later became part of the ELK Stack. 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.
Anna: Aw, thank you. At least traditionally, it feels like most documentation was written by engineers and the traditional computer science degree engineers you spoke of earlier and it kind of shows because it's ... Well, I won't mention some certain cloud giants who make a possibly deliberate puzzle of their documentation, but yeah, it's not intuitive. It doesn't tell a story. It doesn't guide you from one step to the other. It's very, 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.
Corey: Yeah, well one ... 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 there 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.
Anna: 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 that's ... I don't think that's the correct approach.
Corey: 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, you know, whenever you hit a bit somewhere in a software program or 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 wound 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 your building that. Or you discover there's a bug either in the code or in the documentation, more often.
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?
Anna: Yeah. Yeah. It's just simple neglect and it makes sense in startups where there's five people and they're working really hard just to build the thing. But I think, yeah, how it fix it is put a priority on that and hire people who are not just engineers for the documentation. You almost need this combination of somebody with some sort of communication background that also understands the technical aspects of the product.
Corey: 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.
Anna: Okay. Yes. This is a pretty exciting thing we've been working on at Stackery. It stems from this problem that Serverless changes local development. So, in a traditional workflow you had your code, ran local hosts, you did your thing, send it off to DevOps when it's ready to be deployed. But in Serverless it's very different because you have cloud resources that are 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 so ...
Corey: To throw my own bias out there, and I'm absolutely not contradicting you, your company, et cetera, 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 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 work flows. Can you help me get there?
Anna: Okay. It's about speed, basically. So, yeah, like he said, mocking ... First of all, it takes time. You have to mock out all your services, get the events, et cetera. And it's not faithful to your actual cloud of resources. Your permissions probably won't match, you know? You have to hard code your environment parameters and that also takes time.
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 the waiting to deploy ... Waiting for your deployment is then you waiting to compile, so that's also wasteful.
Our solution is-
Corey: I consider that my coffee time.
Anna: Well, true, but if you're doing that 10 times a day then that's not-
Corey: Oh, yeah. I start shaking around two in the afternoon.
Anna: Yeah. And you get distracted and you open your email and you're like oh, that thing's ready. What was I doing? 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 some 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 Dynamo or whatever your using. And it's out there.
We've got a command on our CLI that just came out called Stackery 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.
I mean, in my own workflow I've been testing this extensively for the past few weeks, just building my own pet apps at work for our change log and stuff. And it just ... It's a game changer. 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 a bracket. It's a huge thing for me, anyway.
Corey: 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 I've ever heard the term before-
Anna: Yeah.
Corey: -Please don't tell me I just coined that.
Anna: You probably didn't but you may have.
Corey: 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/DevOps/test admins/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 want to be able to build all this stuff on my laptop when I'm on a plane and there's no Wifi. Cool. That's the use case people bring up and I understand and respect that, but I fly 110 thousand miles a year. I don't find myself mid-air without Wifi 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 your describing does, to my understanding, require access to the internet.
Anna: Yes. Yeah. Very much so. And that's the thing. 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.
Corey: Absolutely. Or everyone has a plane drink. Mine has always lately been the gin and tonic out of a-
Anna: Yes.
Corey: -Mistaken belief it will 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 it makes it better.
Anna: Oh, yeah. Yeah. I mean, especially on overseas flights. Just keep the red wine coming and that's it.
Corey: Exactly. And it's great because it leads to some hilarious commit messages right around drink four.
Anna: Yeah. And that's probably not the optimal way to work on your app. I just want to put that out there.
Corey: You'd think that. I get incoherent but my code gets better. To be fair, it's my code.
Anna: Really?
Corey: There's really nowhere for it to go but up. But usually baseline is it's hit rock bottom and started to drill.
Anna: Well, I mean ... It's like ... Was it Hemingway said, "Write drunk. Edit sober." So, as long as your code reviewer is sober you're probably good.
Corey: That's a whole separate argument for another time. I guess from ... What you're describing is local development is invariably done on your laptop? Or, I guess to some extent for what I've been doing lately, I've been having the "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 "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?
Anna: Well, I mean one way or another you're committing to git all your stuff somewhere safe hopefully. Yeah. If you're committing the git then you can drop your laptop in the ocean and it will still be there. 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 correct; that you're able to interact with the resources you need in the same way you would in a production environment.
Yeah. No, what you said about hybrid is completely accurate. 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.
Granted, I have not tried your EC2 method but it sounds a little bit more complicated; just going to throw that out there.
Corey: Sort of. I mean, not to be prescriptive. I think everyone has a development workflow. But, again, I come from a grumpy sysadmin background when we call sysadmin because there isn't really 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 a full 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 to let's say model, I'd use something like an Amazon Workspace over a tool 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.
Anna: Yeah. No, that makes perfect sense. Like, I am a VS Code girl. I like my IDE. I like having all my folders neatly organized, et cetera. I like being ... I'm also a very visual person. I just like seeing everything running in the terminal along with my code. I think that's why prefer 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 an RDS behind a VPC, right? How are you going to interact with that? You need to run a tunnel most likely. It can get more complicated for sure. But that's also doable.
Corey: Yeah. I 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 un-learn a whole bunch of habits for that to start being something that I use at 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.
Anna: Yeah, that would be sweet.
Corey: 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 Tmux panes or a bunch of deep-dive VIM configurations.
Again, I do not care prescriptively what editing environment someone uses. One of the worst interview questions I ever heard was 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. Some of the best developers I've ever known have used JOE, which is an ancient code editor that goes way back or Nano, which everyone likes to make fun off because it's just a what you see is what you get, more or less. And everyone likes to taunt these folks. It's like 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.
Maybe judging people by the tools they use isn't necessarily the best path forward, particularly in a career context.
Anna: For sure. For sure. And there's also the context ... Like I would think most current CS grads and definitely code school grads, at least from everybody I've met that went through code school, they're probably going to use an IDE. It might be VS Code, it might be Webstorm or something high term, 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, it's going the way of the dinosaur maybe.
Corey: The one 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 quit. And it feels like 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 bucks or 100 bucks for the editor for a year. At which point I just sort of stared at them. What are you planning on paying this person, buddy? They're going to embezzle more than that in office supplies because all of us do and the coffee budget will be multiple times of that. Are you sure you're focusing on the right part of this story?
It's weird having these conversations with people who just don't seem to get the larger picture.
Anna: 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 it in a few days.
Corey: Right. 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 an okay, are you actually going to do any work? But if you're trying to judge people, for example, how quickly they can type that has never been the 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.
Anna: Yeah. For sure.
Corey: Before we go, is there ... I guess, do you have any words of wisdom for folks who might find themselves teetering on the brink, shall we say, of coming from liberal arts or writing background who want to wound up potentially dipping a toe into tech? What advice would you give them?
Anna: Sure. Well, 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, et cetera, online courses for three, four years off and on. Getting the basics of HTML, CSS, JavaScript down. I feel like by the time I decided on code school ... It's also a perfect turn of events that I finished a big contract job. I had a cushion. 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 over me saying do your stuff but also just people I can ask questions of when I get stuck. So, that's when I decided on a code camp. But, yeah. I would say before you spend a whole bunch of money on some sort of a 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 making yourself get there? Because then maybe it's not for you or maybe there's some sort of tech-adjacent role. Maybe you want to work at a startup but in a different role than an actual engineer.
Yeah. That would be my advice. 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. Go through some sort of course. If you're the kind of person who needs in the 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 mind. But then you can only grow and keep learning.
Corey: If people want to hear or possibly read more about how you view these things, where can they find you?
Anna: I occasionally contribute to Stackery's blog. I have a Medium. I can't remember the link to it.
Corey: We will throw a link to it in the show notes.
Anna: 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, sure.
Corey: Exactly. Yes. Reason this is a good ... English classes years from now will look at documentation as an example of the modern era.
Anna: Oh, God. I hope not.
Corey: Anna, thank you so much for taking the time to speak with me today.
Anna: All right. Thank you, Corey.
Corey: Anna Spysz, software engineer at Stackery. I'm Corey Quinn. This is Screaming in the Cloud.
Speaker: 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.