[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 how you develop a CI/CD workflow with Victoria Lo, Technical Blogger and Solutions Engineer at PayPal.

[00:00:22] VL: The reason why we have continuous integration is because it is important for code to always be stable and error-free at any point.

[00:00:30] SY: In this episode, Victoria talks about transitioning from pursuing business and finance to web development, how her personal coding blog was key to landing her job at PayPal and understanding CI/CD DevOps after this.

[MUSIC BREAK]

[00:00:55] SY: Thank you so much for being here.

[00:00:56] VL: Thank you. Thank you, Saron. It’s nice to meet you.

[00:00:58] SY: Nice to meet you as well. So tell us about how you first got into coding.

[00:01:02] VL: I first got into coding when I was a teenager. I was about 15 years old and I took my first computer science course in high school. And that’s when I got introduced. And since then, I really fell in love with it. And I’ve been just doing my own side projects ever since.

[00:01:17] SY: So you ended up pursuing it in college or not so much?

[00:01:20] VL: No, actually in undergraduate, at that time, I wasn’t really sure what I want to do. So my parents kind of encouraged me to go into business. So I actually got into a business school instead, but even so I still like coding. So I always just do it as a hobby and I never thought it could be somewhat a career because I just never thought that I’m at that level. So it’s always just been kind of like a hobby and a passion of mine.

[00:01:48] SY: So what kinds of things were you building? What were you tinkering with?

[00:01:51] VL: So I’m actually really passionate about video games. I like to play all kinds of games. So naturally, the aspect of coding that I'm quite inclined to is game development. So actually I taught myself Unity. From there, I just continued to just try developing my own games and just having fun with drawing characters and designing and coding, like programming the games in general.

[00:02:15] SY: And I also understand you did some freelance projects. Is that right?

[00:02:19] VL: Yes. So I was also freelancing for small local businesses. So I also built websites and some web apps for businesses while I was still in school.

[00:02:29] SY: And I also heard that you have a really or you had a really…

[00:02:34] VL: Yeah. So actually my very first client is someone who I met for the first time. And her business was struggling at that time because it was when the pandemic just started. And she reached out for anyone, like in a form for anyone who can help her build her website for her business, because she’s trying to shift it to online presence. And then at the time, I was not really confident about my skills as a web developer because I’ve only been making games and the language was different. It was JavaScript. Whereas for Unity, I’ve been making it in C#. So at the time, I was still very, very new in JavaScript. I barely built any websites at the time. Maybe just a few for myself, like static websites, but she really encouraged me and I also wanted to help her business in some way. So that was a very important step in building my confidence. I think ever since I got my first client, I realized that even though you might think you’re a beginner, but as long as you believe in yourself and have that confidence, definitely people will appreciate your efforts. And I remember I built my very first full stack website for her, and she was very proud and ever since then her business grew and a year later I got a job at PayPal and then I talked with her. I reached out to her and just want to thank her for giving me that very first opportunity. And she told me that, “Hey, you know what? From the very beginning, I already know you can do it.” Like believed in me from the beginning.

[00:04:04] SY: Oh, that’s nice.

[00:04:05] VL: Yeah. It’s really an amazing opportunity for me. And I think since then, my journey has been very surreal, thanks to her.

[00:04:14] SY: So you went to undergrad for business. You’re doing coding on the side. You’re freelancing. What made you decide to pursue coding as a career and kind of get away from the business path?

[00:04:25] VL: So actually, when I was in business school, I just don’t feel like it’s me. I do like the courses. I do enjoy learning all the aspects about business and how corporations work. But at the end of the day, I felt that it wasn’t something I want to do for the rest of my life or at least like after I graduate. I don’t think that it’s something that I’m passionate about because I heard all my classmates, they’re talking about, “Oh, I can’t wait to graduate. I want to work at this bank or I want to work at this marketing company.” But I don’t feel the same kind of passion as them. So I looked at my resume and I’m like, “Is this really what I want to do? Is this my identity?” And instead of doing my assignments, I always just find myself just getting lost in the code and just keep building site projects, even though I have sometimes other priorities to do. And that’s when I realized that maybe this is what I truly want to do. Even though I was scared, I was anxious, I was afraid that I probably wouldn’t catch up because those who had formal computer science background would probably get a job right away, and I would be maybe after undergraduate outweighs two or three years studying myself. But I felt like if those two or three years is worth it and it helps really make me feel comfortable with myself and make me feel happy, I think that’s worth it. So after graduating, I made the hard decision to just not really apply to any jobs and just stay at home in my parents’ house and just to learn, to learn by myself. And I think at the end of the day, it’s really worth it, as long as you’re satisfied with what you’re doing and you feel like it’s you. So I feel like it’s me and it suits my personality as well as my interests. So yeah, that’s how I switched careers.

[00:06:15] SY: And how did your parents feel about your decision?

[00:06:19] VL: Yeah. My parents are like the typical kind of Asian parents who are like they kind of pin a lot of hopes and expectations from me and they kind of imagined after I graduate to be in this finance business because I specialize in finance. So they thought, oh, yes, I’m going to be an investment banker or something like that.

[00:06:38] SY: Right.

[00:06:39] VL: Yeah. And to be honest, at that time, I didn’t tell them what I’m doing. I just kind of shut myself in my room to learn. They were quite worried to be honest, but they’re not the type that really pushed me so hard. And at the end of the day, I kind of tell them that this is what I want to do. And even till today, they were quite apprehensive about it, but they don’t chase me to please change or anything. They were quite understanding in that sense, but I can tell that they still have quite leftover regrets for me because that’s not what they expect me to become. I think ultimately, I didn’t really care about what they think.

[00:07:21] SY: Good for you.

[00:07:22] VL: Yeah. Yeah. I'm just like, “Oh, too bad, I’m not what you expect me to become. Who cares?” So yeah.

[00:07:28] SY: So tell me a little bit more about that transition from finance to tech. Do you feel like there was much of a crossover between those two? I know a lot of people listening are transitioning from one career that’s totally not related and getting into tech right now. Did you find any overlap, any crossover between those two industries?

[00:07:48] VL: I do find one overlap, which is when I was taking this FinTech course, they asked me to make an algorithm for a trading bot. And I had some visual, basic knowledge at that time. So I actually made a very successful trading bot. Of course, it’s only a market simulation. So it’s really basic, but I was proud that I get to make that, whereas a lot of my classmates struggled because number one, the professor also doesn’t know coding. So he kind of just gave us that assignment, like as a very difficult challenge, but I kind of stood out in the sense that I managed to build my own bot, whereas my whole class kind of probably copied code from online sources even though there’s work…

[00:08:31] SY: And use it yourself.

[00:08:33] VL: Yeah. So in that sense, I was quite proud of it. But other than that, there’s not much like coding related in finance, because finance is very theory and analytical as well. In terms of quantitative, yes, we work with numbers, but coding is also not just about numbers and math. Right?

[00:08:52] SY: Right. Right.

[00:08:52] VL: So there’s not much overlap. And I remember the struggle I had when I was transitioning is that the logic is different because I have to learn computer science concepts, like object-oriented programming and networking, and these concepts are non-existent in finance. In finance, the concepts we learn are very market-based, theory-based. It’s like this is the theory, like this is the best formula to predict a stock price, for example. It’s called the Black-Scholes formula. So something like that. It's very formula based and you just plug in numbers to calculate. Whereas in computer science, it’s also very strong in concept. You need to have good foundations of the concepts in order to be able to code yourself. I understand that when I first started at least learning JavaScript, I kept visiting and revisiting tutorials and I never got to make my own website because I was not confident. And I think a lot of beginners also, they get stuck in this tutorial hell because they just keep watching and following tutorials, but without ever making their own projects. Like I just keep copying and copying other projects, like how to make a weather app. Okay. I copied exactly this person’s code and I thought I could make a weather app, but if someone just gives me a test and says, “Make a weather app by yourself without looking at someone’s code,” then I’m not confident I can do it.

[00:10:15] SY: So you were freelancing, learning, and then a year later you ended up at PayPal. Is that right?

[00:10:21] VL: Yes.

[00:10:22] SY: Tell me about that. What was it like to interview at PayPal?

[00:10:25] VL: It’s a very surreal process actually because first I was contacted by a recruiter and she actually discovered me through my blog.

[00:10:35] SY: Oh, cool!

[00:10:35] VL: At that time, I was writing very consistently, like every week, I would write two or three articles. Now it has reduced to one article per week because I’m busy, but I’m still very consistent in writing my blog. So she’s seen my content and she saw a lot of potential and she also saw that with your consistency for one year and all that, I can tell that you have a very good work ethic. And so she’s like, “I want you to come in for an interview, at least just try.” And at the time, I was like, “Really? Can I really do it?” And then she’s like, “Yeah, of course. Just try.” And I was like, “Okay.” So the interview process was straightforward and there was like a behavioral interview. There’s the managerial interview and then two technical interviews. So I will have to say that it’s really amazing that I get to meet everyone at PayPal. They’re just so nice and so welcoming. And during the interview, I actually asked a lot more questions than the interviewer asked me because I was just so curious about the role, like solutions engineer. What is that like? It’s kind of different from software engineer. So I had a lot of questions about new role and I just keep asking my interviewer who is my future manager all about this rule. And then at the end of the session, she told me like, “Well, this interview session has been fun since I’ve been the one being interviewed by you.” Yeah. It was a very amazing process and it was pretty smooth at that time. And they asked me when I can start working. I said like, “As soon as possible would be nice.” So I went in December 14 last year and now it’s almost been one year.

[00:12:20] SY: So tell me a little bit more about this tech blog. Why did you start it? What kinds of topics did you write about? Tell me a little bit more about that.

[00:12:28] VL: So actually when I made the decision to switch careers, there was a lot of uncertainty about where should I start first. I think a lot of people who don't have a formal background in computer science, they don’t know what is the roadmap and where to start or what’s the syllabus. There’s just no structure there. I just keep jumping from one module to another, but I don’t know if it’s the right one. So I started with like just Java, I don’t know why, and then Python and then after that JavaScript again. So it was really a mess and it just had new structure. I feel like I wasn’t progressing like the way I wanted because I don’t know how to progress. And there was no mentor. There’s no one around me that can say like, “Oh, you have to learn this first or that first.” I didn’t know. So at the time, I feel like my skills have stagnated and I still feel like zero confidence in terms of just building a full stack website by myself. I still feel like I need to go back to that tutorial video one more time. I try to memorize the code. I thought that’s the best way to learn. There was just so much struggling. Then I went into Tech Twitter and then I saw that a lot of people are sharing, learning in public and I’m like, “Oh, maybe this is something I can do.” Right? Before, I was living in a cave. I have zero social media presence and I don’t know how Twitter works before. I kind of secluded myself. I’m not really a social media person, but I thought, “Oh, recording my learnings as well as learning in public. I think that’s a good way for me to really, um, grow in terms of my skills. And plus, I can get to share my knowledge, grow the community as well.” I opened up a medium blog and that’s when I started blogging. So it was primarily for me to record my learnings, but then slowly I realized I got more and more readers who were inspired by my content. I wrote mostly in JavaScript. So web development, ReactJS, so front-end libraries. So yeah, mostly around web development topics. So anything from frameworks to libraries, to new tools that I discovered. So I kept sharing those contents and slowly I noticed my reader base group and they were asking me for more advice and more content around nontechnical related topics. So it was kind of like, “How do you deal with burnt-out or imposter syndrome?” So I also like to explore like the nontechnical part in the tech industry. So I also wrote a few articles on that. That’s my technical blog journey.

[00:15:03] SY: That’s awesome. That’s so inspiring. I mean, we tell people all the time like blog, share your knowledge, learn in public. We highly encourage those kinds of activities. And it’s really cool to know that that was a reason, a big reason why the recruiter reached out to you and you’re able to leverage that into a job. So kudos to you, setting an awesome example. So that’s really cool.

[MUSIC BREAK]

[00:15:45] SY: So tell us a bit about your role at PayPal. You said a little bit earlier that being a software engineer and a solutions engineer are different. Tell us about the differences.

[00:15:56] VL: So yeah. I think the main difference between solutions and software is that for solutions, you’re talking a lot more to people, you’re communicating a lot more. As a software engineer, you receive tickets and then you do them throughout the day. I have a friend who’s a software engineer and I saw her lifestyle. Maybe she talked to her team once a day. They give her a ticket. This is what you’re supposed to do by the end of the day. And then she’d do them. She’ll code for the rest of the day and do them. Whereas for my job, solutions engineer, we’re also talking to the clients. So we’re also figuring out what they want to do. So that’s a lot more communication. And I think actually my business degree helped me a lot for that because before I took business, I guess I was really this shy girl. I can barely hold a conversation. I was quite shy and I think that’s why I never regretted it, even though many people ask me like, “Oh, would you have taken a computer science major instead?” Then I say, “I could, but I would not be me right now.” So I don’t regret taking business in a sense. And because of that, I really like this job, because not only can I communicate like directly to the clients and really figure out their needs, their requirements, but I also get to do what I love, which is coding and also communicating with my team members. So yeah, I would say that’s the main difference is that solutions, there’s definitely more communication compared to software.

[00:17:24] SY: So let’s dive into continuous integration, continuous deployment, CI/CDs, which incidentally is how we found out about you because you wrote about it. You wrote about it earlier this year on your blog. And we were like, “Man, this is a topic that we’d love to get into, introduce people to.” So tell us what is CI and CD? What do those initials mean?

[00:17:46] VL: Sure. So before I maybe give you what it stands for, maybe I can tell you that this is DevOps, it’s a DevOps term. DevOps stands for development and operations. So as the name suggests, it’s something that has to do with streamlining operations in terms of like app development. So software development and web development also. So yeah, DevOps is something that a lot of companies they put in place these DevOps practices, help them to really automate and just help them make their software development processes just more efficient in general. So CI/CD is a DevOps practice, and CI stands for Continuous Integration. So what that means is that you’re continuously integrating your code branches, merging them into one main branch. It includes different steps, basically, like building it, testing it, and then finally merging it into the main branch. So in order to perform continuous integration well, every member of the team needs to have good code and commit good code after all the testing has been done into the main branch. The reason why we have continuous integration is because it is important for code to always be stable and error-free at any point in time. If let’s say you make so many changes, you edit five or six features and then finally you committed and merge it to the main branch and a lot of errors appear, then you’re in trouble because if the company just needs to release like an update as quickly as possible, it’s just very difficult to debug everything because it’s many months of work, of errors as well, and also plus maybe it’s not well integrated to the current code base. So there’s just a lot of those issues around it. So continuous integration encourages the practice of continuously integrating and merging the code back into the main branch as frequently as possible. Therefore, the code remains stable and error-free. That is CI. For CD, continuous deployment is the process where every single step of the DevOps cycle is automated. So from building to testing, to deploying, so even deploying the app to public servers. So all of that is completely automated and that is very hard to achieve, especially in bigger apps, because there’s a lot of things to take into consideration. So continuous deployment is basically a hundred percent automated. There’s no manual intervention in that process.

[00:20:24] SY: So before continuous integration and continuous deployment, what was there? What other systems did people use? Or even today, people who don’t do CI and CD, what do they use instead?

[00:20:35] VL: At least for what I know, most of them, they just use at least some form of automated testing, but it’s not yet to the point of like CI. CI would be the first step in like at least showing that your company does follow DevOps practices. But if it’s just automated testing alone, that’s not called CI. Right? So I think most people, at least like companies who don’t have CI, they would just have like a very simple automated testing workflow, which is in the right direction, but not yet to CI. So that would be the step before CI. So same goes for CD, continuous deployment. So before it’s fully a hundred percent automated, there’s another term called “Continuous Delivery”. So that part, there’s some manual intervention. So basically after all the code, the tests and everything is merged into one, there’s someone who manually checks and then making sure everything lines up and then manually process the big deploy button and then the app would go to the public for the public to use. So that is continuous delivery. And a lot of teams, at least the ones that I know, they are currently at the continuous delivery stage because they just want to make sure that there’s someone there monitoring and just making sure that the code makes sense before. So it’s difficult, to be honest, it’s very difficult to get to continuous deployment. So that’s why, I would say, most companies would be at continuous delivery, which is already a very admirable way of implementing DevOps into the processes.

[00:22:15] SY: So what are the tools that developers might encounter that implement CI and CD?

[00:22:22] VL: I think the most popular one is like Jenkins or Travis or even Cypress. So those are very useful tools to automate your automated testing and just helping you build automatically your apps. So I think those are the three most popular tools. The one that I wrote in my article is GitHub Actions as well as Buddy.

[00:22:46] SY: Yes.

[00:22:47] VL: So I do like to use these tools because I think they’re more beginner-friendly and because my blog is targeted for beginners. I believe these are also just as powerful as the ones I mentioned. For GitHub Actions, at least, it’s automating the workflow. So it’s more in the context of like the repository, which is also something similar to Buddy, but Buddy is like a tool that you use outside of GitHub, right? It’s like you connect the tool to GitHub. Same goes for the other tools like Travis or Jenkins. You also connect the tool to a repository. So like GitHub or Bitbucket, something like that. Whereas GitHub Actions, you’re working with the repo directly because you’re writing the workflow code directly in GitHub. So I think in that sense, it’s easier to work with and you can definitely develop an automated CI/CD workflow using just GitHub Actions. That’s why I wrote a series on that. Because I think it’s really easy to use, especially for beginners or even smaller projects, because again, DevOps is mainly for really big and complex apps. However, I also believe that it’s always good to strengthen even like your site projects with a good CI/CD workflow. So yeah, I think this one is also better for smaller apps because it’s not something like you have to set up the tool on it. For GitHub Actions, you are really just writing a YAML file, like in a few lines and YAML is pretty much like English. So it’s very easy.

[00:24:24] SY: Very easy to read and write.

[00:24:26] VL: Yeah.

[00:24:27] SY: Okay. So I think we’re getting the picture in terms of theoretical how it works and how it’s put together and what it’s useful for where it comes in handy. I want to make it a little bit more visual, I guess. Let’s walk through a simple kind of app. You mentioned building a weather app earlier. If we were building a weather app, when we wanted to use GitHub Actions, we wanted to be continuous in all the ways. How would it work? What would we do?

[00:24:53] VL: So the first thing I can assume that this app is, for example, a Node.js app. Right? So the first step in a CI is building the app because you need to first build the app in order to test it. So I would have a GitHub Action that runs a Node.js build command. So in GitHub Actions, you can have steps and these steps will execute in order. So I would write a step that says, “Okay, NPM install.” So I’ll install all the packages needed to build. And then after the NPM is built, so I would build the app. And then after that, I would run the test. So I’m assuming that this app, like the developer already wrote some good tests for this app under the test command. So I would then run NPM test. So those 1, 2, 3 NPM installed build and then test, those would be under one job. So GitHub Action works by jobs. So each job has these steps, right? So basically, this build job will contain this install, build, and then test steps. So that is the build job. And then the second job, which is under the build job, it will execute right after the build job is ready, would be the deploy job. So the deploy job, so after assuming the build job works very well, all the tree steps are done, it works perfectly, the deploy job would run. And then this deploy job would have steps under that job, and those steps would be deploying this app to, for example, Heroku or something. And GitHub Actions, what’s very good about it is that a lot of people in the community, they create and they make their own actions to run. So there’s a Heroku deploy action in GitHub Marketplace where you can just use it for free. So it’s kind of like NPM. If you’re familiar with NPM, there’s a lot of packages that people just make for free. So this one is the same thing. GitHub marketplace, there’s a lot of actions people make for free. So these actions can be run in the steps. So for example, in the deploy job, for the weather app, it would be a step that would run this Heroku deployment action. So this step runs it and then the app would be deployed. And so in GitHub Actions, you can specify when do you want this workflow to trigger. So in order to make this a CI/CD automated workflow, I would make this workflow trigger whenever someone pushes to the master branch. So I can put a property there, trigger on push. And then every time when someone pushed to the master branch, this whole entire job and steps that I described would flow and would run accordingly. So imagine someone says, “Okay, I’ve made some changes into this weather app. Okay. I’m going to push.” So I commit to the main branch. So once that commit is received, the workflow would trigger and they would run, “Okay, NPM install.” I installed all the packages, NPM build, I built the app. NPM test, I test, I run some tests. Okay. They’re all good. Next job, deployment job. I would run the Heroku, deploy to Heroku action and then done.

[00:28:06] SY: Got you.

[00:28:06] VL: So that would be the complete workflow. All the developer needs to do is to push the code and everything else, the GitHub Action would run.

[00:28:13] SY: All of this stuff happens.

[00:28:15] VL: Yeah. So it’s the magic.

[00:28:15] SY: That’s so cool.

[00:28:16] VL: Yeah.

[00:28:17] SY: So did we just do continuous integration, continuous deployment or both? It sounds like we did both.

[00:28:23] VL: Yes, we did both. It’s like fully automated, right? Like I didn’t even have manual intervention. So that is what we call a CI/CD workflow, a completed one.

[00:28:45] SY: Coming up next, Victoria talks about when in your coding journey learning CI/CD is most important after this.

[MUSIC BREAK]

[00:29:05] SY: Okay. So we mentioned earlier at the beginning of this episode that CI and CD is usually a part of DevOps and DevOps usually comes in when there’s a big code base, a lot of developers, everyone’s pushing features, maybe you’re at enterprise scale, you’ve got a ton of users and you’re trying to kind of manage the systems and get them all ordered and well-organized. Does it make sense to understand these concepts and these tools when you’re an early career developer, when you’re kind of just getting started?

[00:29:36] VL: So I would say it’s not like complete compulsory knowledge to know, because if you get a job in let’s say a company, you will naturally learn these things. However, I think it’s a huge plus. Fortunately, for me, I was contacted early on by this DevOps company. And so I started to read a lot about it, even though I didn't end up accepting their offer, but because of that, I read a lot about it and I realized how important it is. And so I want to also let my readers know about this concept.

[00:30:08] SY: So when in your career is this important to know?

[00:30:13] VL: There’s no exactly a point in time where you need to learn it. It will be natural. So when you come into the company, if they somehow have DevOps and CI/CD integrated into their standard workflow, then you’ll naturally learn it. So it’s not really like when to learn it, but I would say if you want to learn it independently, then I would say go for it because it’s always better to know something than not. But I also have friends who like never knew it their entire lives. Their companies are quite small, so they never had it for like five years. And then suddenly, when they shift to a different company, then they started learning it. So again, it depends. There’s no right time to learn it. I would say it just comes whenever you need it. It’s good to know.

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

[00:31:11] VL: Okay. Yes.

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

[00:31:17] VL: So this is pretty much a parent’s thing. So basically they always advise me to compare myself to my siblings or my cousins. And they say like, “Look at your sister. Look at you.” I think that’s really a very, very bad advice because number one, it can ruin your self-esteem because if someone’s like way better than you or in something, it really can make you feel like a bad person, like not a growing person. So I never liked that. They advised me to do that. And I also think we are all individuals and we’re all very different people. We’re not even comparable from the beginning. So I don’t know what gives them the idea to advise them, but I think it’s something they always believed in. They think it’s good motivation. If you see someone better than you, you would want to be naturally better. And I think there’s some truth to that, but you’re not supposed to compare them one-to-one. I don't think that’s something that’s really true.

[00:32:17] SY: Not productive.

[00:32:18] VL: Yeah.

[00:32:18] SY: Yeah.

[00:32:19] VL: At the end of the day, I think you need to just focus on yourself and if you want to improve on your skills, then you should just compare to yourself, like to yourself in the past or something. You’re not supposed to compare with other people. Right? And I’ve seen time and time again, like my readers, they would like reach out to me and they’ll say like, “Oh, Victoria, I have imposter syndrome.” And then I’ll be like, “Why is that so?” And a lot of them would say, “Well, because this girl that I knew in the Tech Twitter, she’s doing so well, whereas me, I'm still in the beginning.” And I tell her like, “Well, a lot of people share what they know on Twitter, but there’s probably a lot of things that you don’t know that she doesn’t know. So that’s why you’re not supposed to just assume everyone on Twitter knows a lot of things more than you.” That’s how I think most people get imposter syndrome because they try to compare themselves to others. And that’s how they feel like they don’t belong and they don’t achieve as much as the people that they see on the internet or on social media.

[00:33:17] SY: Yeah, I totally get that. Number two, best advice I’ve ever received is?

[00:33:23] VL: I think the best advice is something I give to myself. So I haven’t really received like a very, very eye-widening advice, but I remember my high school teacher at that time, he asked me, “What do I want to do? Which college, which university are you applying for?” And then I told him, “Well, my parents wanted me to go to the business. So I’m applying for that.” And then he’s like, “What? But you love to program, you love coding.” And he told me at that time like, “You should do what makes you happy.” But I, at that time, kind of just wanted to please my parents. So I didn’t take that advice to heart. Looking back, I should have. I think it was a great advice, to do what makes you happy and not for others to be happy. So I think at the end of the day, everything that you want to do, it has to feel like you really want to do it or else over time, you’re just not going to like it. So I really love my job now because it’s exactly what I want to do. If let’s say I did take like a finance job, I don’t think I’ll be as happy as I am now. So it’s a very simple advice, but a lot of people struggle to kind of follow it, maybe for many reasons, and I understand that. But at the end of the day, I think it’s a really great advice to keep doing what makes you happy.

[00:34:47] SY: Number three, my first coding project was about?

[00:34:50] VL: It was like my computer science course and I made like a quiz app. I used Visual Basic. It was actually my very first coding language that I learned is Visual Basic and we had to make a quiz app. So I made like this very small, very cute science quiz app. I was just reviewing my chemistry at the same time, it was high school chemistry. So I just made that quiz app as a review. So yeah, that was my first coding project and it was quite fun.

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

[00:35:26] VL: Is don’t rush too much. I set very high standards for myself and I feel like I have this big, huge deadline I have to meet. And actually, it’s really arbitrary, but I just feel like, “Oh, since now I’m starting from scratch again. I have to keep up with my peers or something.” So I give myself like this timeline. Like, “Oh, I have to learn in six months or something.” And I put so much pressure on myself to get started with HTML, CSS, JavaScript, just so that I can get the web development basics down. But at the end of the day, if you rush it, you really won’t learn as much because I thought the best way is to just memorize. So I try to memorize code. I try to memorize a lot of things. And in coding, that’s not how it works. It’s more like you need to apply what you know then you can explore apps that you want to make and that you can have creative freedom on. If you’re just copying and memorizing code, then there’s no way you can make a website that’s truly yours. So I think that is one thing that I would tell myself, if I can go back, is not to rush yourself and really get the foundations down. So really understanding concepts first before coding. So a lot of people, they just get started, “Okay, I’m going to learn this language Python or something, I’m going to learn Java,” but they don’t know the concept of object-oriented programming or they do know the concept of functional programming. So they don’t know all these concepts. It will be very difficult for them to kind of make their own algorithms. It will be kind of hard for them to write their own code without these foundations down. So I think foundations is definitely important and having solid foundations is very important. So yeah, I would go back and I would start with data structures, algorithms. I’ll start with object-oriented programming first before jumping into just JavaScript.

[00:37:25] SY: Yeah. Great advice. Well, thank you again so much Victoria for joining us.

[00:37:29] VL: Thank you so much for inviting me. It’s been such an honor.

[00:37:38] 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.