[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron. And today, we’re talking about the clouds with Erica Windisch, Principal Engineer at New Relic and Founder of IOpipe.

[00:00:19] EW: It’s very interesting to see how radically different these clouds are based on the types of companies that they are and the decisions that they make as a result of that.

[00:00:30] SY: In this episode, Erica talks about some of the history of the cloud, some of the major cloud providers, and what things as a newbie you might want to consider when deciding to use the cloud after this.

[MUSIC BREAK]

[00:00:51] SY: Thanks so much for being here.

[00:00:53] EW: Thank you for having me.

[00:00:54] SY: So we’re going to really dive deep into clouds. But before we do all of that, tell us about your personal coding journey.

[00:01:02] EW: Yes. So fairly long ago, I am kind of the Oregon Trail Generation. So we had Apple II computers with Oregon Trail and Number Munchers and all the MECC games. What was really great was with that Push for STEM that we had in those late ‘80s and early ‘90s was that math textbooks, and I don’t know if they still do this today, which is like programming examples. So in the back of chapters in my math book, they would have examples of how you could write a program that would do something like solve Pythagorean Theorem or squaring numbers, for instance. So it gave examples of not only how you would do these things on paper and do your exercises in class, but how you can write programs on the computer to do those things. And while I didn’t really have a computer and the only computer I had was in school and they’ve made us play educational games, I still had access to those examples and I would read through them and found them really interesting.

[00:02:06] SY: And what was your first coding job? How did that happen?

[00:02:09] EW: So my first job in tech wasn’t even a coding job. It was assistance administration position. I had just quit school. I went for one year to a university in Florida, Florida Institute of Technology. And I left there with really no plans and I was looking for a job and kind of struggling to find something. And out of nowhere, a company up in Scranton, Pennsylvania of all places reaches out and they were building a data center or web hosting, and they were basically building what would now be potentially considered a cloud. And they even had a lot of automation around that through an application called cPanel. So I came on as a systems administrator as do a combination of support, actual system administration, keep the systems up and running, keep them operating, building new systems, both the hardware and the software side of those things. So I did a lot of things. So I did stuff everywhere from understanding power constraints of those servers and physically building them out and helping plan the power architecture for those data centers and then network architecture, but also like the applications that were running on them and the security of customer applications that ran on those machines.

[00:03:35] SY: So let’s start off with some basics. Let’s define just what the cloud even is. How would you describe it?

[00:03:41] EW: I think I’ve heard it the sky before as running on somebody else’s computer, right? You want to be able to take your applications and run them somewhere else. I think that we’ve seen a lot of evolution of that concept over time. When I first started in what we call it at the time web hosting, we wanted to meet developers where they were. And this is the interesting thing about what cloud development and evolution kind of is, is that as companies providing products to users, you have to meet those users where they are. So in 2001, we didn’t have virtualization, not the way that we do now. We didn’t have a lot of the same access controls and security mechanisms between processes on a machine. We didn’t have containers for instance, back in 2001. So at the time though, I could argue it was cloud from some degree, especially once we started adding automation. And this was when they started using the term “cloud” was when we were able to have programmatic access APIs for creating those resources to have a place to run your application, have a place to store your data, to do that programmatically. And this is why things like iCloud have always been kind of controversial within like the cloud type space of… If those really give a user defined level API, if it’s not something that developers are really building around, it’s a cloud. There’s been lots of debates around this. It’s really hard to fight the marketing machines for a company like Apple, when they make something like iCloud. And I think that that has created a lot of confusion in the market. But originally, cloud was defined as programmatic infrastructure or your applications. And another really key aspect to this because early in cloud or late pre-cloud, however we define it, we had combinations of us. We have companies where you could access the billing via API, but not the infrastructure. Right? It would trigger like a request order to get a server created and then there were still physical or manual aspects of that creation. You had things where you could programmatically do some things through the API and not others. And the billing aspect is a really key part of this because it’s not just being able to create those things programmatically, but to be able to have those things affect billing programmatically as well and the ever increasing granularity of time. So we’re at a point now where AWS can bill you for resources by the millisecond. And when EC2 first launched, I believe it was by the hour, right? So they would round you up to the nearest hour and then they would around you up to the nearest minute and then they were rounding you up to the nearest hundred milliseconds.

[00:06:41] SY: Wow! Yeah.

[00:06:42] EW: So this has been decreasing over time. And I don’t know if the definition of cloud is a moving target as far as that’s concerned, but I think that if we were to define a free cloud that was kind of where it was still developing, it’s still getting to a point where you can programmatically do that, an early cloud again was like an hour of granularity maybe where now it’s milliseconds, and I think that’s pretty key though to considering something as cloud. But inside of an organization, there’s a whole another factor, which is that when you deploy to the cloud as an individual developer or team member, you may not even have access or visibility to billing and whether or not you’re building applications in a way that auto scales, in a way that automatically grows and scalable. Because if you’re not able to scale your application at a granularity of hours or milliseconds, are you building is cloud application or not? Because we used to call this the pets versus cattle conversation, building applications that are not just running on a cloud or that are cloud native, that these applications are built and designed to take advantage of the cloud, right? It’s like building an application for a single machine that takes advantage of a single process or a multiprocessor, right? To be able to build that multithreaded parallelized design that supports distributed computing, semantics, and concepts is a skill in and of itself and it’s this other kind of dividing line in terms of what it’s called, because you can run things on the cloud that are not really cloud native or not designed for cloud.

[00:08:27] SY: You know, I’ve heard the definition of the cloud being, as you said, it’s just being on someone else’s machine. Why would I want to do that? Why would I want to do my stuff, run my processes on someone else’s machine?

[00:08:39] EW: Mostly capital expenditures, like that’s the business answer. Businesses have wanted to move to cloud computing largely because it changes something on the budget from a capital expenditure, which is going to be purchasing a server for one year, two years, three years, five years, and moving that to a rental-based model where you use those things as needed. And there’s a number of reasons for this. Early on, it was simply a fiduciary budgetary matter. But as cloud has become adopted and as the granularity of billing has become more accessible with smaller timeframes and as APIs have developed and become more advanced and developers have learned to how to take advantage of these and we have tools, like advanced CI/CD systems that we didn’t have in the 2000s or like ‘90s that can deploy these things, that can auto scale these things. We have things like serverless that automatically grow and shrink according to your load that the way we can build applications has changed because having a capital expenditure to have a machine and add capacity and plan out the capacity in that growth for two years, three years, four years, and then saying, “We’re going to have this amount of growth and then we’re going to buy new machines every six months or whatever to keep up with that growth.” There’s a lot of overhead that you’re removing. Right? But you’re also just being able to be super dynamic. Right? When you have like a Black Friday event, you don’t need to buy machines in September, set them up and build them so you can handle that load. So you can then sell them on the secondary market in December, right? Which is what companies have done in the past, right? Or there would be purposes, machines for other tasks. All of those problems kind of go away. You need less staffing, you need less operations, at least in those places. You’re able to potentially put those resources in other places or use them in other ways. And developers have been so much enabled by having these tools and being able to grow things that scale rather than spending months or years also planning the growth and scaling of these applications when you can put that into the architecture and design to make sure that it builds and scales, but it does that much more automatically than it used to.

[00:11:16] SY: So another word that comes up a lot when we’re dealing with the cloud, and you mentioned it as well, is the word serverless. What does serverless mean and what’s the relationship between that and the cloud?

[00:11:25] EW: So serverless is the concept of rather than renting access to a host machine, running an operating system, like normally you would get a virtual machine and that virtual machine runs an operating system. It can run Windows. It can run Linux. They could theoretically run the Android. But you would have to then take that machine, install the operating system, install software on that operating system, and that software includes things like your dependencies and your actual application, and then you have to operate a manage that operating system. So you need to monitor it and observe it, understand if it’s having problems. With the model I was describing earlier with the cloud, the cloud native applications, with this scalability and developer in DevOps and through CI/CD, we have gotten to a point where sometimes it’s easier now to just shut down the machine than to really have the observability of that machine. However, serverless takes us a step further and says, “Give us your application, give us your code, and we’re going to run it.” And it really hearkens back earlier to the web hosting that I did, like 2001. We are developers, back then we didn’t give them virtual machines. We gave them an account to put their application code onset. They would take their code from CVS or Bitbucket or any of these other non-Git-based code repositories because we didn’t have Git at the time and they would take that code and they would upload it to a server, usually from FTP, which is File Transfer Protocol, and extract those files and run them out on a shared web hosting server like Apache. And now what you might do instead with a host, and this was a really difficult transformational time that I went through in like 2004 through 2006, and for some organizations probably as late as 2010, of going from that model of uploading just your code in your application to having to help build out an operating system and install Apache or other web servers. So it became a much bigger problem, right? To give developers more control and more power, what we did was we said, “Well, don’t just give us your application then. Give us the whole machine.” But it turns out building a whole machine is more difficult, right? It requires more effort, it requires more engineers, more scale, and serverless kind of turns around again and says, “Well, what if we kind of go back originally to that old model, but we give you the API, we give you the auto scaling, we give you all of those things that you wanted but also you don’t need to give us the operating system?” That’s pretty powerful and it kind of gives you the best of all the worlds in some regards with, of course, the fact that because you’re not uploading your full operating system, you do have some constraints that you don’t have like on a microservices type Docker-based system or a virtual machine-based system.

[MUSIC BREAK]

[00:14:51] SY: So now I want to look at some typical choices that developers either may have heard of or may be considering in terms of a cloud provider. I think the big one we’ve probably all heard of is AWS, Amazon Web Services. Can you talk a little bit about what AWS is and why it’s such a dominant player in the field?

[00:15:11] EW: I guess the most obvious answer is Amazon. Right?

[00:15:17] SY: But it’s interesting because Amazon, I still think it is weird that Amazon is in cloud. Amazon is not supposed to be in cloud. Right? It’s supposed to be books and toilet paper, two-day delivery or sometimes next day delivery. So the fact that it even got into this field and got into cloud is just still fascinating to me.

[00:15:38] EW: Yeah. I kind of love Amazon in some ways as solving logistics problems, inventory problems. They’re managing all that inventory. They’re managing all of these resources and providing an infrastructure for all of those things, even to the point that they even have their own delivery services. And the cloud in some ways is that kind of infrastructure for all businesses, the build. It almost seems more strange to me that Google and Microsoft are doing these things. Maybe not so much Microsoft. I think it actually makes a lot of sense that Microsoft is doing it, but it’s very interesting to see how radically different these clouds are based on types of companies that they are and the decisions that they make as a result of that. Amazon has become almost a warehouse for all sorts of different technologies. And I think Google and Microsoft have done a much better job at kind of focusing on, “This isn’t the way that you build an application,” especially Google, I think has been really, this is the way that you build an application and here are tools to build applications in this specific way. And Amazon is much more of a warehouse of all sorts of tools in your toolbox and a lot more of those tools overlap and there isn’t necessarily one best way to build your application on Amazon. It is, “Here are all the tools. Go build a house. Good luck.” There are advantages to that, right? Because when you have all sorts of different houses that you want or all sorts of different buildings that you want to build, because maybe it turns out you’re not building a house, maybe it turns out that you are building an office building, right? You’re building a skyscraper or you’re building a shed. And Amazon really does have arguably the widest set of tools to build any sort of application that you’re looking to build.

[00:17:38] SY: Are these options, when it comes to cloud computing, are we talking about a tool, a place where it really is for advanced developers, it’s really for our intermediate, more senior folks? Or is there a place for beginners, for newbies to use cloud? Does it even make sense to enter this domain?

[00:18:00] EW: I think that it is necessary for, well, maybe not for all developers. I can make an argument that it’s not really necessary for mobile developers. It’s not necessary for embedded developers. It’s not necessary even for a lot of front-end developers. Although I think that for front-end developers, it is a very strongly desirable skill. You need to at least be able to know things like S3. And when you are starting to move into backend services and full-stack development is where you start to say, “Well, I need to be able to run my application.” Because if you’re a mobile developer, for instance, you’re going to deploy your application at people’s phones. If you are a backend developer, you’re going to deploy the application to the cloud. That’s just where your applications run if you’re a back-end systems developer. But sure, I mean, people who develop desktop applications, applications embedded, et cetera, that you don’t necessarily need to have these skills, they can become very useful that as soon as you need any sort of back-end service architecture, where you need something like centralized database for many users or an organization or across multiple organizations, and honestly, even for just smaller teams. Although if you’re building a small application for just a few users, depending on where you’re using it and how you’re using it, you can sometimes even get away with using Google Sheets as your API and your database. Right?

[00:19:32] SY: Yeah.

[00:19:32] EW: I’ve done it. I’ve done it in New Relic. Not for a customer data and for our product, but when we are building and shipping applications and we’re doing early access programs, we can keep track of certain information related to product development and project management inside of Google Spreadsheets and then we can automate some of our operations processes based on those spreadsheets during those early access programs. And then when we go live with those programs, those tools become available to everybody and they just become part of the standard databases and so forth and authorizations and access for all customers. But we can manage some of those things. There are things as simple as a Google Sheet when you have literally a dozen.

[00:20:18] SY: So there is a place for newbies to kind of get into cloud of the top cloud providers, of AWS. We have Google Cloud, Gatsby Cloud, Azure and Netlify, these are some of the top ones. Do you have a recommendation of which one is…? Is there one that’s a little bit more newbie-friendly that has maybe an easier get started process?

[00:20:38] EW: I think it really depends on what you’re shipping. For instance, I heard Gatsby and Netlify, those are very much focused primarily on deploying front-end resources, which are going to be static web hosting, HTML files, et cetera, JavaScript files, CSS files, just static assets. Those providers make a lot of sense for those resources. But when you’re thinking about things like databases, for instance, you start to become much more restricted. So as soon as you need to start doing things like stream processing, databases, you have to start thinking, “Well, where am I going to run this and how am I going to run this?” DigitalOcean is kind of famous for being a very easy to access and use cloud that offers you virtual machines, and even now places the right containers where if you can build a container or a virtual machine, you can go and ship it and run it on DigitalOcean with not too much trouble. I don’t know where they are with databases, for instance, if they even have any, and maybe they do, but I imagine it’s probably fewer options than you have at AWS. The old-fashioned way of doing this might be, like, let’s say you’re on DigitalOcean, you would spin up a virtual machine running MySQL, but now you have to operate and maintain and worry about this MySQL instance that is running on top of a virtual machine or even a container on top of a virtual machine. On DigitalOcean, you have to maintain all of those things, and there’s a lot of advantages to going into AWS and spinning up an RDS cluster for MySQL. Maybe paying a little bit more, paying a little bit of a tax there for having a fully managed service, but you can then buy MySQL Endpoint and you largely don’t have to manage it. They even have tools for doing backups and restores and all those things. So depending on what you’re deploying, it can be really advantageous to choose a provider that maybe isn’t the most convenient or easy, but has the things that are actually going to make things easier for you in the long term. Or doing a little bit of a hybrid approach. There’s definitely lots of companies that use like a Netlify or a Gatsby cloud with DigitalOcean and AWS. I would say those are probably more smaller organizations or individuals because as you get larger, most companies want to really try and standardize on one of the big clouds. And of course, the behemoth here is AWS and most employers are going to one AWS experience or what used to build AWS experience once you’re on a job.

[00:23:27] SY: Why is that? Why is it AWS so popular? Why is it number one?

[00:23:31] EW: Again, it comes a lot down to the tools that are available to you on that cloud. They just have such a wide set of tools available for you to use. They also have a really great set of access controls. They have FedRAMP compliance and GovCloud access for those that are doing federal work in any capacity. The thing about AWS cloud is that is arguably the hardest of those clouds to use. It is the least user-friendly. There have been a lot of improvements to that over time, but it is kind of for better or worse the de facto standard, I think. Certainly there are organizations that use the other clouds, but most organizations are going to use AWS. And I would say it’s worth getting to know if you’re going to be doing any sort of back-end development, and that includes what I would personally would consider a full-stack development.

[00:24:32] SY: So if I am a newbie developer, I’m going to test the cloud out for the first time, my first step into this venture, what should I consider? What are the questions maybe I should ask myself to help me decide which tool to use as my first tool?

[00:24:47] EW: So what I’d like to do is figure out, first of all, what it is that I’m building and what are the requirements for the thing that I’m building. For instance, let’s say you’re building a front-end website and it’s going to talk to a back-end application. You’re going to want to have an API for that. And actually this probably applies also if you’re building a mobile application in talks about back end is you want to have an API service. That may be your only way of interfacing with that service. It may be just everything is kind of a cloud interface and that is like create, read, update and delete, CRUD through an API where you store that data. Right? A database has a CRUD API, not necessarily HTTP, but databases have those sorts of APIs, but you maybe want to do things on top of that database. You want to do things to the data. Some of your applications might have data ingested through another mechanism. In New Relic, we do a lot of APIs where the data comes from another source. So for instance, customers send us telemetry data through their application and then our application talks to our APIs to retrieve the data that came from the customer’s application, right? So we have this whole ingest layer and streaming processing that puts data into the databases and then our applications are built on top of that API as mostly a read to really retrieve that information and display it. When you’re doing that, you have to think about things like, for instance, performance. There are lots of statistics on how quickly users want data back when you load a page. And that can be very contextual, right? Because when you go through like a process where you click a submit button and you put in a bunch of search parameters, it’s usually acceptable it will be a little slower. But when you look at even things like Google, Google has a huge database, lots of data, and they have very quick results. There are definitely lots of architectures that would not support a Google search use-case because they would not have the kind of performance that you need. And in fact, that kind of use case is probably very multilayered in terms of what kind of results can it return and what kind of speed and on which page of results are you on, et cetera. In something like New Relic, we can say that if you’re looking for data from a month ago, It’s probably more acceptable for the customer to wait more seconds than they want to wait for the last 60 minutes of data where we want to return last 60 minutes a data very quickly and data from a month ago, we’re willing to take some compromises on how quickly return that data. So you have to come up with data architecture. And this is where I think this can certainly become a specialization and a job in its own and building an architecting data storage. In the teams I work with, there’s usually only one or two engineers that really understand deeply those sorts of problems and can build those solutions and not everybody does. Right? That’s a great opportunity for some of the newer developers or developers that are maybe not so new but just don’t have the domain expertise to learn from their coworkers or learn from those projects. But it basically comes down to requirements like what are performance, what are the costs diff because costs like on AWS, I mean, I’ve come up with two different architectures and they can just be very, very different in terms of costs. And sometimes you have to just pay the money.

[00:28:26] SY: So what are the big differences between the big providers from doing something very basic that doesn’t require some type of ridiculous customization, that’s pretty straightforward? Is there much of a difference between the big cloud providers? I mean, it feels like they mostly do the same thing or maybe not. What do you think?

[00:28:46] EW: I think that Google has probably a really fantastic core set of services that you could build anything on top of. However, you may need to roll more of it on your own than you would on AWS. Like for instance there might be database choices that AWS has that Google doesn’t have. These still run those databases on Google, but you’re going to have to install those databases in an operating system and an operating system on a virtual machine and build, operate, deploy that, manage all of that within your organization. There’s conveniences to not having to do those things. But I think Google provides all of the primitives that you need to do the things. You might need a roll more of it on your end. What they do have is very user-friendly. Of course, there are exceptions, but I think that there is a happy path for Google Cloud where things kind of work and you can get the core of what you need. And I think it’s designed with a lot of thought. And I just really enjoy using Google Cloud versus some of the others. I think DigitalOcean is another one that is also very convenient and easy to use, but maybe not as large. Finally, maybe not finally, but Microsoft is the other really big one. And Microsoft really focuses a lot on how they can have enterprise contracts, how they can solve problems for IT departments rather than application developers. And the other side of it is for developers that Microsoft has really put a lot of thought into integrating Azure Cloud in with the developer tools. So if you’re using VS Code or you’re using Virtual Studio and increasingly even potentially GitHub, which is now a Microsoft product, that these products are going to integrate well together. They’re going to try and make it easy to move from one of these products to the other. And a lot of developers use these tools, right? VS Code, Virtual Studio, and GitHub, a very popular product. When we talk about Microsoft Cloud, I think that it isn't completely unfair to even consider GitHub and GitHub’s version of CI/CD, which is GitHub Actions, arguably as cloud services. I think there’s a lot of use for these services, especially as they integrate. And Microsoft has a fairly decent set of things that they saw, but they also do tend to… they support Linux, but a lot of things do lean towards Windows and they lean towards a lot of these IT operations sort of problems and enterprise contracts. A lot of what they do is try and really go around and solve your billing problems more so than your technical problems. So a lot of times I see that Microsoft is chosen for billing reasons, for cost reasons and not necessarily for technical reasons or developer happiness.

[00:32:02] SY: Coming up next, Erica talks about what she thinks the future of the cloud might look like after this.

[MUSIC BREAK]

[00:32:20] SY: So I’m curious what you think the future of cloud computing is going to be. What’s the next version of the cloud?

[00:32:28] EW: Yeah. AI-assisted development is going to become more prevalent and I think that AI-assisted operations and management and observability is really going to be important. I think that the companies in that space were just touching the beginning of that, right? GPT-3 itself and the new GitHub service, Copilot, for instance, is just the really beginning of that iceberg. And I’m really excited to see where that goes. It isn’t cloud exactly. I think that what we need from the cloud, and I might regret saying this, but I feel like what we need from the cloud is kind of there. I mean, arguably even what we have in EC2 was mostly enough. Right? We started adding on layers. We added on higher level abstractions. We went from EC2 to containers, to serverless. I don’t think that there is going to be a more serverless, serverless. I mean, there’ll be improvements and it’s going to become more optimized and so forth. But I don’t think that we’re going to have like a huge, huge net change from that. I think that building and deploying those things is going to change because, remember, this whole journey is about getting your developers to write better code faster, write more code, better code, faster, speeding up the development cycle. I mean, that’s what companies want. It’s what developers kind of like, kind of don’t. One of the big barriers to this is that when I started IOpipe, we actually were looking at GPT-3 like algorithms for building applications. That was the original pitch. And what we found, the reason we didn’t go down that path, we went down observability, was that we found that developers want to write code. They don’t care about machines running code for them. They want to write code. I think that what GitHub has done is interesting in that machines are writing code for you, but also you’re still writing code yourself. Right? They’re assisting you. They’re speeding up that process.

[00:34:41] SY: Right, they’re helping, they’re not taking it over.

[00:34:43] EW: Exactly. And I think it’s going to be a really interesting thing when we start to see aspects of development being taken over because I think that’s going to happen. And I think it’s going to be a scary time for developers, just in the same way that DevOps was very scary for a lot of developers. A lot of developers were really scared that they were going to have to do any sorts of operations. And I think that it’s even scarier to think that aspects of your job might go away with machines taking over. Right? And it’s going to be very limited at first. But over time, it’s going to increase slowly by surely. I don’t know where we’re going to end up and I don’t know how quickly it’s going to happen, but we’re kind of here and I think that’s the next step. A lot of things are going to, again, come down to like… architecture is not going to go away. Developers making decisions is not going to go away. Prog managers making decisions, design is not going away. And again, software development is not going away, but little tiny aspects of it, little tunings of it, certainly I think machines will be able to do in a short-term timeframe, things like make this ball roll in a game. Maybe there is already a library for it, make things roll. You don’t need to necessarily Google for a library for something to roll. Maybe it’s kind of in your tools that already.

[00:36:20] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Erica, are you ready to fill in the blanks?

[00:36:27] EW: I’ll try.

[00:36:29] SY: Number one, worst advice I’ve ever received is?

[00:36:32] EW: So I think when I was younger I have a lot of people telling me that I wasn’t valued while others were making because of what I was making. Right? The amount that you were making was a reflection of your ability rather than a reflection of your ability to negotiate or even your geographic location or because of other factors. I was paid under market for some time and I did not really get a lot of great support and people telling me, “Oh, yeah, you can go out and get that money.” Like, “Yes, you’re being underpaid.” I instead have people telling me that, “Well, that’s just what you’re worth because that is what you’re making.” And I really wish I had better access to people who were successful in tech, who were willing to be transparent about salary is, willing to be transparent around compensation and titles and things like that in this industry.

[00:37:33] SY: Number two, best advice I’ve ever received is?

[00:37:37] EW: So yeah. Unfortunately, I have the memory of a goldfish, which is almost better at recording memories. So what I can maybe do is offer my own advice.

[00:37:45] SY: Okay. Sure. Go for it.

[00:37:48] EW: So I think it’s important that you continue to learn and grow, especially about systems and architecture, but also how to navigate your job, right? How do I communicate across teams, to coworkers, to your manager? And if you are a manager to reports and to make sure that you’re getting the right titles and compensation. These are things that I learned very late into my career. I was probably closer to 15 years into my career before I really understood these things appropriately. You also need to understand equity, especially if you’re ever going to work, well, really just in tech, you should be getting equity. And if you’re not, you’re probably at the wrong employer or you’re at Netflix, and at which case, you’re getting compensated for instead. Right? But unless you’re getting Netflix compensation, you should be getting equity and you need to understand equity and what that means, because RSUs are significantly different than startup equity. I invested close to $50,000 into Docker between the cost of exercise and the taxation of that. And that’s the money I saved up for years because I was not getting paid correctly to market for a long time. So that was a lot of money for me and I lost all of it. And Docker is by many measures of success, right? So even when you think that you have a startup or a product that is doing well, you’d be thinking of a lot of potential. When you have a valuation, when you a dollar and it goes to $10 and you’re like, “This is a short bet,” it isn’t. I would be extraordinarily careful. And honestly, probably the best advice I can get is not to work for a startup and to actually work for one of these large corporations right now that are just handing out RSUs, which is not completely guaranteed, but it’s fairly safe, much more than taking a pay cut to work for a startup and then getting startup equity that’s not going to be worth anything. It wasn’t until later that I realized a lot of people that take those jobs were people that were coming from more affluent situations where they can take those rests where I was thinking that I was bootstrapping.

[00:39:59] SY: Number three, my first coding project was about?

[00:40:02] EW: My first one was a run box for launching applications from a window manager called FVWM, and that was back in around ’97. So it’s a very simple application and it just popped up a window and it had a text box in it and you could type in the name of an application on your computer or a command, and then there’s a button for a run and it would run the application for you. Super simple, super basic. It was a really great introductory application to develop. But it was also something that I needed because back then desktop environments for Linux, at least, were not all encompassing things that did everything, that have all the tools and things that you needed. So something as simple as a run box was not something that was actually necessarily provided by my operating system. And it was a very simple utility that I actually had a need for. So that’s why I read it.

[00:40:53] SY: Number four, one thing I wish I knew when I first started to code is?

[00:40:58] EW: How much I would always rely on the references and documentation. I do not remember all of the syntax and all of the standard libraries for all the languages that I have ever learned. In fact, there are absolutely languages that I have learned, forgotten, learned again, and forgotten again. I'm sure that there are people that do memorize these things, and I’ve had periods where I was deeply engaged on a project and was writing code daily and got into a rhythm and didn’t have to check those reference materials as often. However, I have always checked those reference materials, even in those times for all sorts of things. And I think that starting new programming languages is always a shift, returning to programming languages is a shift, starting new projects where you have to do something new, whether it’s talking to a new database or using an old database and a new way or anything else, you’re going to have to look up those things, you’re going to have to do some more learning and more research, and you’re going to have to reconnect the dots, and I think that’s normal.

[00:42:05] SY: Absolutely. Well, thank you again so much, Erica, for joining us.

[00:42:09] EW: Sure. Thank you.

[00:42:16] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.