[00:00:00] (Music) 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 quality engineering. (Music) Rocio is an an engineer with a specialty in quality. 

[00:00:24] RM: Hi, my name is Rocio Montes, and I am a staff software engineer at Intuit. And I create beautiful experiences for our customers. 

 [00:00:32] SY: If you've heard of quality assurance or testing, that's the kind of stuff Rocio knows really well. And as a feature-building software developer at Intuit, she's learned a ton about building products and making sure they work really well for the user. She takes us through the world of quality engineering. After this. 

[00:00:53] Flatiron School teaches you how to code from anywhere. They've got an awesome community of career-changers and a number of different options for you to pick from to become a software engineer. They've got full-time in-person courses, self-directed introductory courses and a remote online web developer program. They even have a free 75-hour online prep course where you can learn Javascript, Ruby and do some interview prep. Go to flatironschool.com/podcast to learn more. That's flatironschool.com/podcast. Link is in your show notes. 

[00:01:27] One of the best parts of being a coder is finally being able to bring your passions to life. You have the skills to design, to code, to create the thing you're excited about and share that passion with the world. And Hover can help you with the first step of sharing your passion with the world: getting your domain name. They've got a really beautiful and easy-to-use interface where you can find and register your new domain name in just a few steps. And to give you full control, they separate your domain name from your hosting so you're never stuck with one service. They keep your domain name safe while giving you the flexibility to use whatever hosting service is best for you. They also give you free WHOIS privacy, so your personal information is safe, too. To get started, go over to hover.com/newbie to save 10% off your first purchase. That's hover.com/newbie. Link is in the show notes.

[00:02:15] DigitalOcean provides the easiest cloud platform to deploy, manage and scale applications of any size. They remove infrastructure friction and provide predictability so you can spend more time building what you love. Try DigitalOcean for free by going to do.co/codenewbie and get $100 of infrastructure (Music) credit. Link is in your show notes. 

[00:02:39] SY: So when I think of building software for something like that, something that deals with money and finances—that sounds really serious. (Laughter) It sounds very hardcore. Yeah.

[00:02:53] RM: It is for sure very serious and we take it very seriously, right? There's no room for mistake in taxes or in your finances. We treat every piece of customer data with the utmost seriousness. And the main mission of Intuit is to power prosperity. So we wanna do that for all of our clients. 

[00:03:11] SY: And what I find so interesting about your background is that you're not just a software engineer, you're a software engineer with a focus on quality. What does quality mean in the software tech context? 

[00:03:27] RM: Quality really is—I think it's like the craft of making sure that, again, the experiences and the applications that we put out for our customers are flawless and are accurate and precise, right? Because again like, for example, for TurboTax, we file taxes to the IRS so we need to make sure that the application is robust and, again, that there's no room for mistakes. So in quality engineering, what we do is we create automated processes for us to check the quality of the application every time there is a new code check in. And there can be functional tests. There can be performance test. There can be unit test. So pretty much as you know, it's the craft of testing your application to a point that you are confident. 

[00:04:15] SY: Ok, so when I hear test, as a Ruby developer, I'm thinking RSpec.

[00:04:20] RM: Ok. 

[00:04:21] SY: Like that's what I think of as testing, specifically my code and making sure, you know, I didn't introduce bugs—well as, you know, as best as I can test for those things. Is that the same thing as quality engineering? Or is quality engineering outside of that? 

[00:04:35] RM: It is pretty much that at the, pretty much at the root, right? When we talk about quality engineering, right, like an abstract is saying, "yeah, we need to make sure that the application is flawless." But when you actually get to the ground and, you know, you start implementing what quality is, it's actually—yes, it's having tests. I believe you're referring to actually unit tests...

 [00:04:55] SY: Yes. 

[00:04:55] RM: ...where you actually test every piece of function that you have in your code, every method. And we call that unit testing. After that, there is also a process of testing that we call functional testing, and it's where we start testing more of an end-to-end experience, right? We're just not gonna test certain functions of method, we're gonna start testing something that we call test cases. And a test case is pretty much what a customer would do with your application. There are different technologies that you can use for that whether you are programming on the back end or on the front end, you can find different technologies for each one of these pieces. There's also performance testing that you do to make sure that your application can undertake a big amount of customers. As you can imagine, that is a very vital thing in TurboTax because April 15 we need to be (Laughter) able to support all those procrastinators (Laughter) and make sure that we can be there for them. And we're not going to crash, right? We get over forty million customers. So... 

 [00:05:57] SY: Wow. 

[00:05:58] RM: ...it's really important that we, that we stay stable and we stay available for them. 

[00:06:02] SY: Ok, so I wanna revisit the functional tests. 

[00:06:07] RM: Ok.

 [00:06:07] SY: Because when you said what users can do with your product, what came to my mind was whenever I'm, I build a new feature—as I mentioned I do my own unit tests and, you know, I usually do test room development so on the core, on the code level I feel pretty good, you know? I feel like I've, I've thought about things. But then I will hand it over to my amazing husband (Laughter) and he, you know, if there's an input field, he will literally just press zero and just hold zero (Laughter) for like a minute, you know? And then press enter and of course, it'll break for some strange reason. And I'm just like, "ugh, that is not what a user would do." And he's like, "you never know." (Laughter) So I assume... 

[00:06:47] RM: Right. 

[00:06:47] SY: ...you're not doing, you're not doing that are you? 

[00:06:49] RM: Well I am not doing that, but I am thinking of that when I start doing my functional cases. So pretty much when you do functional testing, you wanna test edge cases. You wanna test a negative cases. You wanna test any, you know, scripts that they might put in your inputs or any database statements that they can put, right? You can go really deep into the test cases that you wanna do, but you're also thinking about what a user might do. If you're testing a UI application, you need to test, for example, that a user might not really go to a feature in the same route that you thought that or that developers thought that a client would go to a feature, right? So you need to really abstract yourself and take out your engineering mind and just try to think like a regular customer that is using, for example, the app for the first time. 

[00:07:39] SY: Yeah. So how do you do that? Because, you know, I can think of, you know, maybe I—I'll just pretend this button is in here, and I don't know how to get to it. Like I feel like I can kind of create scenarios like that. But for the most part, I feel like it'd be really difficult to not know how the app works and not know, you know, how do you... or do you just get real users to do it? Like how do you manage that? 

[00:08:02] RM: It's a muscle that as who's specializing in quality engineering that we exercise, right? We think about scenarios that most people don't or that most engineers don't just because we deal with the application as a whole and not just with a small subset of the features that probably a developer is doing when they, you know, when they create a feature. We think about the end-to-end and the overall product. Also to your second statement about whether we, we see customers, we actually learn a lot from our customers. We do follow-me-homes, we do.. 

[00:08:34] SY: Wait, wait, what's that? That sounds like fun or creepy. I don't, I don't know. (Laughter)

[00:08:38] RM: It is not creepy, it's actually very fun. We sit down with customers, and we try and see how the customers use the applications on their environment, right? So we go to their house. We make them, you know, sit down on their own desk, on their own computer. 

[00:08:54] SY: Wow. 

[00:08:54] RM: And we see how they interact with the product, right?

[00:08:57] SY: That's so cool. 

08:57 [00:04:15] RM: So this is part of "D for D," which is Design for Delight. And this is a methodology that the founder of Intuit, Scott Cook, instill in all of us. And makes us put the customer in the center of everything that we develop here at Intuit. So we sit down with the customer, we see how they use certain features, we see what labels don't work, we see what buttons don't make sense. So that's why I was telling you a little bit before, right? We see how customers go on completely different routes...

[00:09:26] SY: Yeah

[00:09:27] RM: ...that we actually thought. So we gain customer empathy, and we see exactly what, how they use our products. 

[00:09:33] SY: So I'm thinking of the follow-me-home scenario, and I'm trying to imagine being the person who is in the home watching the user use the product. I'm trying to figure out... what would I write down? You know, what notes am I taking? Because I imagine there's so many different variables that I'm witnessing. (Laughter)

[00:09:51] RM: Right. 

[00:09:51] SY: Because it's not as simple as, you know, "I'm gonna run this line of code and see what, you know, where it breaks." It's like, "well the person, you know, took two seconds longer than I expected." Is that a thing? You know, is that a note that you would write down? Is it just purely broken functionality? You know, like how do you, how do you even know what to pay attention to when there's so many variables when you're interacting with a user? 

[00:10:10] RM: So we take a look at their behavior and how, how exactly they understand the product, right? So for example, if I tell them that I want them to go to Turbo, which is the app that I currently work on, I give them a task. I say, "can you please update your income?" And that's all I say. I don't tell them, "hey, go to your profile, click here and edit your income." 

[00:10:33] SY: Uh huh. Ok. 

[00:10:33] RM: So I just present them with a login screen, and I will see how they can figure out whether they're gonna create a new account, where are they gonna click, if the wording makes sense. I'll see how they get to do that task. 

 [00:10:47] SY: Ok. that makes a lot more sense. That's a lot more structured than, than what I imagined. 

[00:10:51] RM: Yeah. No, definitely. Yeah. And then obviously another big part of quality engineering is definitely the technology, right? Using the right set of tools to actually automate our processes. We here at Intuit have a very developed release pipeline, right? We call it the automated pipeline. And pretty much we have automation at every stage of our development. So whenever an engineer makes a "check in," we run unit tests and functional tests as part of that pull request. Then whenever we automatically deploy to a pre-production environment. And at that pre-production environment, we again run another set of functional tests. And if those tests are successful, then we move on to deploy—to production. And it's all automated, and the fact that we have these automated checks actually gives us the confidence that we can push that change all the way to production. And our goal is to push this change in less than an hour. 

[00:11:52] SY: Ok, so when I'm thinking about the skills of a quality engineer, what are the things that you need to know and what are the things that you need to be able to do? Like the actual skills, you know? 

[00:12:08] RM: We definitely are software engineers first. I graduated from RIT from a software engineering degree. And then switched to quality engineering. I know that there are roles in quality, for example, quality analysts, and they don't necessarily have an engineering background, but as quality engineers, we definitely need to have that developing skill, right? 'Cause we wanna know how to integrate tools. We need to write test cases. We need to write automation, and writing automation you use the same programming languages that you use when you are developing features. So you definitely need to know how to program if you wanna write automation, right? 

[00:12:53] SY: Ok, so when I'm, I'm trying to position the quality world in somewhere in the tech world. So would you say it's a subset of software engineering? Is it like a specialty? Or does it sit outside of it in any way? 

[00:13:07] RM: It used to be that it was a subset, and there used to be special quality organizations. There is now this new way of doing things in development, and it's actually called shift left. And this shift has shifted quality to the left because you wanna start now doing quality all the way when you are thinking about requirements; when you are, you know, designing the app; when you are obviously developing. You just don't wanna leave the quality at the end after the feature has been already done. So this is a, actually a pretty common practice nowadays in the industry, and Intuit has already onboarded to that. We didn't get rid of our quality engineers, we are just now—all the quality engineers now at Intuit do both development of features and do quality. So now quality's owned by the whole team. The whole development team owns quality. And the idea behind this is that the more we think about quality, the more instilled in our day-to-day processes, the better it is for the product.  

[00:14:14] SY: Yeah. 

[00:14:14] RM: So a regular day for, for an engineer and now how my regular days are is, you know, I get a task, and I have to develop that feature, and I have to test it. And I have to make sure that if it's a front-end feature, I am testing compatibility, I am testing layouts, I am doing my functional testing, my unit testing. And then I submit that, that code. And same for services, right? If I'm writing backend services, I need to make sure that I'm writing again unit, the functional and maybe I'm doing performance testing, if there are any configuration changes. Each engineer is responsible for the whole quality of their feature. And of course, because we have that automated pipeline that I explained before, we have the confidence that that automated pipeline it is gonna check for us the quality (Music) as it moves through these different environments that we have before it gets to production. 

[00:15:12] SY: Coming up next, Rocio talks about the future of quality engineering as an industry and how you can start a career focused on quality. She also shares her thoughts on the value of a computer science degree. After this. 

[00:15:26] When I learned to code, I was so excited to finally bring my passions to life. I could build things that I really cared about and share them with the world. And the first step in sharing is getting a great domain name. That's where Hover comes in. They've got a really slick east-to-use interface. They've got awesome domain names to pick from and they separate your domain from your hosting so you have full control and flexibility over your online identity. So go to hover.com/newbie to save 10% off your first purchase. That's hover.com/newbie. Link is in the show notes. 

[00:15:58] You want to get serious about learning to code, but where do you start? Flatiron School's got the perfect thing. They're offering their free 75-hour online prep course, where you dig into Javascript, Ruby and more. If you're not sure where to start, start there. And when you're done, you can keep learning with their self-directed introductory courses, remote online web developer program or full-time in-person courses. Whatever your schedule, they've got options to help you reach your coding goals. To learn more, go to flatironschool.com/podcast. That's flatironschool.com/podcast. Link is in your show notes.

[00:16:35] DigitalOcean is the easiest way to deploy, manage and scale your application. Everything about it was built with simplicity at the forefront. Setting, deploying, even billing. Their support is amazing. They've got hundreds of detailed documentation and tutorials, so if it's your first time deploying an app, they've got great tools and community to make it nice and easy. Try DigitalOcean for free by going to do.co/codenewbie and get $100 of infrastructure (Music) credit. Link is in your show notes. 

[00:17:07] SY: Ok. So “shift left” is the—would you call it a career path I guess? A development path where quality engineers become... well I guess they were always engineers, but they become feature-building developers but now all the developers are focusing on quality from start to finish.

[00:17:26] RM: Yeah, definitely. It's a practice, right? It's a practice that—it's a new practice in the industry that now everyone owns quality. And we want to go as far as, you know, even the product managers. We want them to care about the quality. We are actually building tools. We, we actually have tools right now that enable non-engineers to create test cases that can be plugged in into the automation.

 [00:17:52] SY: Yeah.

[00:17:52] RM: So we wanna enable product managers. We wanna enable, you know, designers even to write these test cases that generate a script and we can plug in into an automates, into our automated pipeline. And that gives everyone the accountability for the product. Of course, there needs to be a quality engineering center organization, right? Because they need to enable the tools. They need to enable the metrics and the processes, right? They need to keep us up to date with the latest technology and they're thought leaders of that will let us know what are the best practices and where should we go with all of this. And those are the ones that, you know, enable all the technology for the automated pipeline and the tools that we use. 

[00:18:37] SY: So if you are a developer and you are interested in getting into quality, or quality engineering, where would you start?

[00:18:46] RM: There are different technologies that you can use, you know, based on where you're actually developing. So if you're developing for the back end and using Java, for example, a very great tool for testing services is REST Assured. And it's a tool that we use here, and it's—it makes it very easy for you to test REST API calls. Then if you are developing code for the front end, you might want to take a look at WebdriverIO, which is a wrapper for Selenium. So that will automate UI testing, and of course we use Mocha and Chai also for assertions. 

[00:19:19] SY: So what was the learning curve for you having done qual—how long have you been in quality by the way?

[00:19:25] RM: I would say probably seven to eight years. 

[00:19:28] SY: That, that's a good amount of time. 

[00:19:30] RM: Yeah. Yeah. 

 [00:19:30] SY: That's solid. What was it like for you to go from that to feature-building? 

[00:19:35] RM: Ok, so it was interesting. So I—when I first started my career right out of college, when you start as a new engineer, you pretty much are just head down writing code. And, you know, you don't have that much dynamic relationship with your teammates or with different other teams, which was killing me because my personality is outgoing. I wanted to be talking here and there to people. And I noticed that the quality engineer got to do that because they need to talk with product owners. They need to talk with developers, the front end, the back end to create these end-to-end test cases. So that's how I made the switch into quality. And unfortunately, they don't teach you about any of these tools in college, right? It's very rare. If they teach you about quality, they at most teach you about unit tests. So you pretty much learn about all these tools when you start working. And then once you know one tool, and you might not like it. So you kind of have to research on your own what are the better options out there. But again, right, you are developing, you are writing code. You are writing automation. So, you know, that engineering muscle is still there. And you still have to create frameworks and, you know, create all these, you know, infrastructure for your testing. Then moving now back to feature developing, I can tell you that it has been easy because, you know, they're different muscles. You are first trying to rip things apart and trying to see how things get, they get together and how they organize each other versus—in quality—versus in developing, you actually have to create them and put them, you know, together. You know, it's a muscle that I'm, again, you know, starting to exercise 'cause I've always been a software engineer, but it's been fun, you know? And Intuit has been really supportive. For example, they, they allowed us to take multiple trainings, so I've taken a bunch of those. I'm actually going to one for iOS. So I'm exploring, again, where, where my passions are, you know, in feature developing. 

[00:21:38] SY: Yeah. 

[00:21:38] RM: I started with front end. Now I'm working on iOS, which I really, really like so I think that's where my passion lies. 

[00:21:46] SY: Nice. Oh, very cool. Do you think you'll ever go back to quality? 

[00:21:49] RM: I think I would. I think I would, you know, if, if again the industry changes, I might just go. But I, I don't think I will ever leave my, my passion for quality. And you know, a great advice that I got from one of our VPs here at Intuit, Jack Tam. He was like, my idea was, "ok well I have to leave my quality side aside just to focus on being a great software developer, right? Developing features and focusing on that." And he told me to not do that. He said, "you already have the quality part done and ready and you aced that. Why don't you become the best at both worlds, right? You can be a great feature developer, software developer, and you also have that quality side. So at that point, I can be like the best combo ever. (Laughter)

 [00:22:36] SY: Yeah. 

[00:22:37] RM: Right. 

 [00:22:38] SY: So when you were talking about how all of these quality engineers are now becoming feature-building developers, and really it becomes everybody's job to do quality—one of the things I was wondering is what happens to the quality engineering industry? Does it become less valuable? Less marketable? Does it become kind of like watered down? Or is it seen as more valuable and more important because everyone's now responsible for it? You know, I kind of see like both things might happen. What's your, what's your take on that? 

[00:23:11] RM: Well, I don't think that it's gonna become, you know, obsolete. Like I mentioned before, there is still a quality organization, right? It's not as big, but there still exists that quality organization that enables all this automation and infrastructure. I still think is highly valued. But here at Intuit, for example, we, we had been in a journey of hiring quality engineers that were software engineers, right? So it's something that we—it was, it was not day and night. It was a journey, and we tried to hire people that had software engineering skills. So when this transition happened, they just became part of the team. And it's not that we, we just don't think about quality of—those skills are not needed because I can tell you her in my team, I specialize—I am the one person who specialized in quality. So any questions around that I'm still the main point of contact, right? So we still need those people that have passion for quality. But of course, they do need to have that programming side as well. 

[00:24:20] SY: Yeah. So one of the things that you called out, which I didn't really think of it that way is you said that quality engineering is very social. It's naturally a very social job because you have to talk to users, and you have to be in their homes and see what they do and find out what they're thinking and why didn't they see that big button? And so it makes me wonder if you are just starting out—if you're a code newbie and you're thinking about what path to go down, would you recommend quality engineering as a possible pathway? Or do you think that it's important to be an engineer first and then go into quality? Is quality like a—is it a viable starting point? 

[00:25:04] RM: Well I think that it has, it—I don't think it has never been a standalone thing, right? I think you had always had to be a software engineer first to understand technology to be able to write automation to be able to understand the code, right? It doesn't matter how well you know the product from the outside, you do need to understand the code and the loopholes and what, what is wrongly designed. So I would always say that you first need to be a software engineer. And then if your passion lies in quality, then you can be the one person that contributes on the team about quality that comes up with tooling for testing that suggests the best tools for testing. So I still think that it is a field that can hold a lot of skills. And if you, if you like it and you're passionate about it like I am, there will always be room for you to be the expert on, on quality. 

[00:26:03] SY: Ok. So if you really want to get into quality engineering, definitely invest in your own engineering skills, your development skills and then see it as a specialty. 

[00:26:11] RM: Absolutely. 

[00:26:12] SY: Ok. Makes sense. So there aren't really—and I, I thought I had heard of software quality—maybe quality assurance is something different? How do you compare QA with quality engineering? 

[00:26:24] RM: You know, I think those are just terms. 

 [00:26:26] SY: Ok.

[00:26:27] RM: Well quality assurance, quality engineering like I said, I know that there are some quality analysts that don't necessarily have the background of quality engineering or of engineering, I'm sorry. Right? They don't have the background on engineering, and they do test the product from the outside, you know, seeing, actually doing manual testing and sometimes...

 [00:26:48] SY: Right. 

[00:26:48] RM: ...they do help out with automation. I think unfortunately, that's not where the, where the industry is moving. And let me say this though. There's a caveat I think because bigger companies—like Inuit or Google or Facebook—they rely on engineering a lot and on technologies and on automation, but I do think that some small companies and even start-ups, right? They might not have the resources to invest that much in automation. So there there might be a niche for quality analysts to gain expertise there and to be valuable, right, doing manual testing and doing a certain, a certain level of automation based on whatever skill sets they have. So, you know, I think there is still room for that in certain companies. 

[00:27:37] SY: Ok, got it. So if I wanna do quality engineering, start with the engineering part, but there might be room to do QA doing the path that does not require engineering but that may or may not lead to a longer term career in tech. 

[00:27:52] RM: Totally, totally. And I think, you know, nowadays, everything starts with technology. 

[00:27:57] SY: Yeah. 

[00:27:57] RM: And I think that it is such—it's so valuable always to have an engineering background or, you know, know how to program and code. 

[00:28:06] SY: So for you, you specifically not only know how to code, but you have a CS degree. How valuable was that degree to the things you do on a day-to-day basis, but even just the fact that you have the career that you do now? 

[00:28:22] RM: Obviously it was, you know, very important because not only was I able to contribute on the team for, you know, like my skills on you know, analysis of test cases and, you know, finding those edge and negative cases. But I was actually able to contribute on the automation. And I'm proud of this, but I'm always, you know, the first adopter for new tools and new processes. And I'm always quick to bring them to my team and implement that for us. So obviously having a, an engineering degree has helped me, you know, move along, right? And, and get to, to the level of staff that I am now. 

[00:29:02] SY: How much of the degree do you—or at least in the beginning did you use on a day-to-day basis, and how much of, especially those early jobs, did you have to kind of figure out just by doing the job? 

[00:29:15] RM: On the software engineering degree, they teach you how to program, and they teach you, you know, how to figure things out for new technologies, right? 'Cause everything is new pretty much every two or three years. When I switched to the first job in quality, I did have to write automation that is writing code. I used that engineering degree from the first, from the first time. 

[00:29:36] SY: So tell me about the funniest most interesting most surprising thing that you've seen a user do. 

[00:29:44] RM: Oh my gosh. So last year, we had to do follow-me-homes, and I think this was my mistake because I should have known better. I actually asked my friends for me to to do a follow-me-home to one of my friends. And you know, like people sharing their salary—not everyone is just so comfortable with that. And even though we're good friends, you just don't wanna, you know, share that information. So at some point she actually, she was like, "oh yes, because when I go to TurboTax, I do this and that." And she was actually like showing me her account. And at one point, you know, the W2 came up, and she was like, "oh, no I don't wanna see this." And she was trying to close her laptop. The whole laptop fell off the table, and it was like this whole shenanigans, and—(Laughter) yeah. We were both just laughing, but I was like oh my God, this is why I (Laughter) shouldn't have have asked one of my friends, but you know, it was a funny moment. 

[00:30:36] SY: Oh no. 

[00:30:37] RM: But, yeah. 

[00:30:37] SY: Was it broken? Did it break? 

[00:30:39] RM: It did not break, thank God. 

[00:30:40] SY: Oh, ok. 

[00:30:40] RM: But it was just so funny like her desperation to like, (Laughter) you know, not share that data. And, you know, I learned from that. I do learn from that because then when we go back, and we think about, you know, adding a social element to, you know, TurboTax or to Turbo about finances, we know that even though, even if you have close friends, you don't necessarily want to share that much of your finances. You know, that much of the information, so you know, you learn every time. No matter what it is you always learn from customers. Yeah. 

[00:31:11] SY: Great. So now let's do some fill-in-the-blanks. Are you ready?

[00:31:15] RM: Yes. 

[00:31:16] SY: Number one: worst advice I've ever received is...

[00:31:18] RM: The worst advice I've ever gotten was that I was gonna be recognized just for doing good work. I—that has proven to be super wrong because in order for you to be recognized, you know, you are in charge of your career, and you have, truly have to influence how other people see you and you have to promote yourself. 

[00:31:38] SY: That is so, so true. The whole...

[00:31:41] RM: Oh, yes. 

[00:31:41] SY: ...keep your head down and do your work. That does, that does not work. 

[00:31:45] RM: Yeah. 

[00:31:45] SY: It might work a little bit later in your career when you have, you know, a really impressive resume and you already have a good network and good connections. You know, maybe then you don't have to be as, as vocal, but especially in the beginning? Oh my goodness. You really have to... 

[00:31:58] RM: No, yeah. 

[00:31:59] SY: Yep. You gotta put yourself out there. Make sure people know, people know what you're doing. 

[00:32:02] RM: Exactly. And sadly, most of us learn that the hard way, right? Because you just sat there waiting and thinking you were doing an amazing job. And even though people say, "oh yeah, you're doing great," that doesn't necessarily mean that you will get recognized or that you will get the opportunities. 

[00:32:17] SY: Absolutely. Number two: my first coding project was about... 

[00:32:22] RM: It was about... it was this website about farmers who grew potatoes. And it was a college assignment. And we lived off the fact that we designed the best-looking website on the group. And the teacher would just love the design, and even though we were just learning how to code on this new language, just because the design was so good, we just kept going off of (Laughter) that for like the longest time, but it was great. I learned a lot. 

[00:32:51] SY: Was it like a, like a documentary? Like a news report of actual farmers? 

[00:32:57] RM: No, it was actually... It was, it was actually a website for potato farmers to input... 

[00:33:03] SY: To help them. 

[00:33:03] RM: Yeah, to help them input how much they were growing, and how many like sacks they were developing. Yeah, this was in Peru where I actually grew up. I did my first three years of college in Peru. 

[00:33:17] SY: Ok. So I don't know anything about Peru. (Laughter) Is there a big potato farm community?

[00:33:23] RM: Well, yeah. We actually have... 

[00:33:24] SY: Ok. 

[00:33:24] RM: ...a thousand varieties of potatoes. 

[00:33:26] SY: Woah. 

[00:33:27] RM: (Laughter) Yes. 

[00:33:28] SY: Oh my goodness. 

[00:33:28] RM: It's actually really great. (Laughter) Yep. 

[00:33:31] SY: Like what's the... is it just different colors? 

[00:33:34] RM: It's different colors, sizes, tastes...

[00:33:37] SY: Wow. 

[00:33:37] RM: ...taste. It's because of the, the different altitudes and regions that we have in Peru. We are able to grow completely different varieties of potatoes. 

[00:33:47] SY: Wow. 

[00:33:47] RM: All the farmers obviously they just don't use much technology. They don't have the resources to use that. So we were trying to make something very simple and very easy for them to keep up with their finances and keep up with their, with, you know, their accounts. So... 

[00:34:03] SY: Yeah. 

[00:34:04] RM: So we did something, something like that and again... 

[00:34:05] SY: Oh, cool. 

[00:34:06] RM: ...it was the most beautiful design, (Laughter) but yeah. 

[00:34:11] SY: Very nice. 

[00:34:11] RM: It was fun. 

[00:34:12] SY: Did farmers actually use it? 

[00:34:13] RM: They did. They did. We actually—'cause we, we won the contest, and we got actually got to go visit them and implement the project in their farms. 

[00:34:21] SY: That's so cool. Number three: one thing I wish I knew when I first started to code is... 

[00:34:27] RM: To be full stack. It's so important to be, to be full stack and know how to code the frontend, the backend, know how to do, you know, deal with databases and do SQL statements. I am actually very impressed with the engineers that are actually full stack and they do get a lot of respect, so I wish I had known that earlier. 

[00:34:46] SY: Yeah. 

[00:34:47] RM: So that I could, yeah, get that more going in my career. 

[00:34:50] SY: And that's one of those things that it's, it's tricky because especially when you're new, when you're a beginner, there's just so much to learn. It's really hard to focus. It's really hard to get even, you know, good at one thing 'cause you feel like you're missing out on the next thing you have to learn. So when you think about doing full stack, how would you recommend taking that on? 

[00:35:08] RM: You obviously are not gonna be able to be a specialist in both areas. Like you're not gonna be the best in front end and the best in back end. But knowing a little bit of each area is really helpful. So I would say if you're in a big company to just volunteer yourself to go into different teams, right? It doesn't have to be an official assignment to a team. You just go and try and figure out the code. Or, you know, you go ahead and create an app. And that's the best way to actually you are (Music) gonna have to do the front end and the back end, you know? So it's pretty much just getting yourself immersed and not being afraid of, you know, learning new things. 

[00:35:46] SY: Yeah. Cool. Well thank you so much for being on the show. You wanna say goodbye? 

[00:35:50] RM: Yeah. Thank you everybody for listening, and thank you very much for having me. 

[00:35:54] SY: And that's the end of the episode. Let me know what you think. Tweet me @CodeNewbies or send me an email hello@codenewbie.org. Make sure to check out our local CodeNewbie meetup groups. We've got community coding sessions and awesome events each month. So if you're looking for real-life human coding interaction, look us up on meetup.com. For more info on the podcast, check out www.codenewbie.org/podcast. And join us for our weekly Twitter chats—we've got our Wednesday chats at 9PM EST and our weekly coding check-in every Sunday at 2PM EST. Thanks for listening. See you next week.