[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 quirks that come with being a developer with Tyler Hawkins, Senior Software Engineer at Workfront, and the author of the very fun and cheeky post, “I Wish I Never Learned to Code”.
[00:00:25] TH: I’ll be browsing on my phone or something and need to go to a website and it’s absolutely not mobile responsive. I'm like, “Man, this is gross. Who made this?”
[00:00:35] SY: If you have a question for Tyler after listening, don’t miss The Ask Me Anything Session he’s hosting on the CodeNewbie Community Forum. Just head to community.codenewbie.org and you’ll find his threat on our homepage and he’ll answer you directly in the comments. That’s community.codenewbie.org. In this episode, Tyler talks about how statistics led him to coding, the pros and cons of working in a silo versus working in a team, and some of the interesting traits that developers can develop after this.
[MUSIC BREAK]
[AD]
[00:01:14] Hey codenewbies, are you ready to take your skillset to the next level? Maybe you want to learn SQL or interested in building a new app. Sometimes taking that next step can be intimidating, but we have good news for you. Cockroach university is a free online learning platform that teaches you the core concepts behind SQL databases and how to build a sample application there's quizzes, tutorials, and prizes along the way.
Get started for free today@cockroachlabs.com slash COVID. Twilio quest is a desktop role-playing game for Mac, windows, and Linux. To teach you real world developer skills. Take up the tools of software development. Become an operator. Save the cloud, download and play Twilio quest for free at twilio.com/score.
Career karma helps code newbies with free career coaching and a community of peers and mentors. To help you learn to code and find a high paying job in tech in less than a year. Download the clear karma app and get started in live audio rooms, hosted by bootcamp grads who landed coveted jobs in tech like Netflix, Tesla, Twitter, and YouTube.
Be one of the over 300,000 people they've helped get started. Visit careerkarma.com/
[AD ENDS]
[00:02:13] SY: Thank you so much for being here.
[00:02:15] TH: Yeah. Thank you. Thanks for having me.
[00:02:16] SY: So let’s start with you telling us about your coding journey. Where did it all begin for you?
[00:02:21] TH: I first started getting into coding during college. I had started out as a psychology major and was pretty intent on finishing up my undergrad, getting a master’s degree and being a counselor. But about a couple of years into it, I realized I liked the more hard science a lot better than sort of the soft science and social science part of it. And I had taken a statistics class, like just a psychology stats class. I really loved that. So I got into statistics and changed my major to that. And at that point, I had to take a bunch of like stats computing type classes. So for instance, statisticians tend to use programming languages like R or SAS, or even just like SQL for database management. And so that was really my first introduction to programming. And at that point, like I realized if I were to look at the two between statistics and computer science, actually I liked the program a lot more than I liked the stats part of it. So I ended up graduating with a degree in statistics, but during that time, I just did a ton of learning on my own, did a lot of like Codecademy courses, freeCodeCamp. I watched a bunch of Pluralsight videos, a whole ton of HackerRank exercises. I even read through I think like 20 programming textbooks on like just JavaScript or HTML and just what’s building stuff, just trying to make little side projects and hack things together. And after I graduated from college, I landed my first programming job.
[00:03:43] SY: So what was it about that stats class and then getting into programming that resonated with you?
[00:03:49] TH: So I was taking R, the stats programming language R, and it was really amazing to me that we could like run simulations and experiments just with typing a few lines of code, right? We could run simulations of very simple things of like, “Let’s flip a coin a hundred times and see how many times it lands heads or tails.” Or even just like data visualization. Like we would have a dataset and using just a few lines of code, you could use like a stats package, like something like ggplot to create this beautiful chart. So that was really cool to me that you could like essentially build something out of basically nothing.
[00:04:26] SY: So after college, you landed your first dev job. What were you doing?
[00:04:30] TH: So I was working at Qualtrics in their professional services department, doing custom engineering projects for clients. Actually during college, I was working part-time there as a product specialist, so essentially doing tech support for them. And so it was a lot of good troubleshooting, problem solving there. And when I was getting ready to finish college, I basically asked them. I said, “Hey, I want to go into software engineering. Is that something that I can do at Qualtrics or do I need to start applying elsewhere?” Right? So I got an offer to be on a professional services team. So this was doing rather than like the core product of their software, these are more just like one-off implementations. So like special client projects that would usually take only one to two weeks per project. So it was a lot of fun, a lot of diversity, and a lot of kind of a quick pace in working on those.
[00:05:21] SY: So what was the environment like? Were you working solo, working on more of a big team? How did that play out?
[00:05:28] TH: So it was very much a solo kind of siloed environment. So we had a lot of different engineers on our professional services team, but it wasn’t like your typical development team where you have a group of engineers all working on the same product or project together. It was very much like you do your own thing and we would run the projects from start to finish. So for instance, like I would be on the calls with the sales rep and the client trying to scope out what is this custom work they need. I’d be writing up the statement of work and helping track down the legal part of it. I’d be doing the actual development. I’d be testing it myself, doing the QA, and then for these longer projects that were being used over years and years, I’d be doing the maintenance as updates needed to be made.
[00:06:14] SY: Yeah.
[00:06:14] TH: It was very much a siloed environment, which was interesting for a first time developer.
[00:06:20] SY: And what about your next job? Was it kind of the similar experience or was it different?
[00:06:23] TH: Yes. My next job was actually quite different. I was there at Qualtrics for about three and a half years. And when I got ready to move on, I was looking for more of a traditional product team, software engineering role, so I ended up moving over to company called Younique, and that was a total different experience from Qualtrics. So I was in like a normal development team where we’ve got sort of a full stack team where we have a couple of back-end developers, couple of front-end, to QA, a product owner, working in doing agile software development, doing Scrum. So it was really like a good introduction to what an actual software engineering job looks like, which was great.
[00:07:07] SY: Yeah, absolutely. And I’m trying to think, as a first job, is the silo a good thing or a bad thing? Because on the one hand working on a team is great. You get to socialize as a part of it. You get to learn from each other. You have support, someone to turn to. But I can imagine working in a siloed situation might kind of build some grit, kind of force you in the deep end and really make sure you can swim. I kind of feel like maybe that toughened you up a little bit. How did you see it? Do you feel like it was beneficial or do you rather had a different experience?
[00:07:40] TH: I mean there’s pros and cons, right? So I think you highlighted some of those pretty well. It’s almost a sink or swim type thing, right? Like a client has a customer request and essentially what they and the sales like want to know is can you do it. Oftentimes, as a new developer, my answer in my head would be, “Well, I don’t know. We’ll try to figure it out.”
[00:08:02] SY: “We’ll see.”
[00:08:03] TH: But that was actually really good. Right? It was a good growing experience. So in case you don’t know what Qualtrics is, they started out as essentially like a survey software company. So they built the software that clients could use to build their own surveys and do things like customer satisfaction surveys or research or whatever. So as part of my job on professional services, I was writing these kinds of custom JavaScript question types for clients. So we’d have a client say, “I want like a signature question type.” So something like a DocuSign where someone can sign off that they took the survey or whatever. Or, “I want like an audio recorder so that as we’re teaching students new language, they can submit audio responses. “Or a different client wanted like a Tinder swipe kind of experience where you could swipe left or right on different products that they showed you to see if you like them or not. So it was really interesting of like, “Well, I don’t know. How would you build it?” A swipe effect. Or how would you make an audio recorder that could take files and then upload them to our system? So it was a really cool growing experience of just like these really off the wall projects, as opposed to just like, I don’t know, working on the same thing for six months to get this new big feature out. But at the same time, like kind of the cons of being in this sort of environment is there definitely wasn’t as much like mentoring or just bouncing ideas off of your coworkers. Because in like a normal development environment, you’re all sort of working towards the same goal as you’re building a product. I’m sort of incentivized to help out my coworkers. Right? Because they’re on the same team. They’re building the same thing. We’re trying to get this thing done together. But being in a more siloed environment, like besides the incentive to kind of be a good person and help other people where you can, there’s really no incentive at all to go help someone with their own projects. It’s taking time away from your projects and your busy schedule. And so there’s, yeah, definitely a lot less feedback just in terms of even like code reviews or finding best practices or bouncing ideas off of each other, there really wasn’t a whole lot of that, which I think would have helped.
[00:10:05] SY: So what kind of things do you work on now at Workfront?
[00:10:08] TH: So at Workfront, some of my biggest sort of initiatives that I’m working on is helping with accessibility. So that’s one of my passions is making sure that our apps are able to be used, not just for able-bodied users, but also for people who use screen readers or have motor control disabilities or are colorblind or whatever. Right? So helping make the app more accessible is a big thing, that I'm working on.
[00:10:33] SY: That’s great. Yeah.
[00:10:35] TH: Also helping with our design system. So we have a design system here that are essentially usable components that we can use throughout our app, but it still needs a lot of love. So working through that, help them to make that better, beef that up a little bit, figure out a good strategy to use throughout the company. So those are kind of my two main things I’m working on right now.
[00:10:54] SY: So now let’s get to the star of the episode, “I Wish I Never Learned to Code.” I’m wondering, what did your employers think when they found out about this article or heard about just the title of this post?
[00:11:08] TH: Right. Spoiler alert, I don’t actually wish I never learned to code.
[00:11:12] SY: Okay. Good. Good.
[00:11:14] TH: But yeah, it was meant to sort of cause that reaction, right? More of a tongue-in-cheek article of, “Okay, here I am. I’m a senior software engineer. I’ve been coding for over, it’s been like six and a half years now.” So yeah, I mean, that was kind of the reaction I wanted is like, “Okay. Well, why? Why do you wish you never learned to code?” Hopefully to not be clickbaity, but it sparks some interest. Right?
[00:11:38] SY: So tell us about the thesis behind this piece. What is this article about?
[00:11:42] TH: So it was actually just kind of the backstory of this. The article topic was actually suggested to me by a guy that I do some freelance writing for, this company called Dev Spotlight. And so from time to time, I write some articles for them. It’s usually more like tech content for their clients and whatnot. But sometimes we do kind of some fun articles like this one and he suggested that one to me of, “Let’s write an article called ‘I Wish I Never Learned to Code.’” “So that sounds really interesting. What’s it about?” And he just said, “No idea.” But I liked the title. So anyway, so I thought it would be fun. So I was thinking about it for a while and what I wanted it to be was sort of a tongue-in-cheek about the software engineers, the quirks we have, the interesting subculture that software engineering is, kind of to poke fun at our habits and the things that we do, but also to show the joys and benefits of programming and how exciting it can be.
[00:12:40] SY: So what are some of the quirks that you manifested when you became an engineer? You list some of those in your article. Tell us about some of the major ones.
[00:12:49] TH: Yeah. So I think the biggest one is just being hypersensitive to everything I see on the web.
[00:12:58] SY: You can’t unsee it, right, once it’s there. Yeah.
[00:13:01] TH: Yeah. It’s almost like being a great singer and then cringing every time someone’s singing slightly off key or something. But yeah. So I’ll be browsing on my phone or something and need to go to a website and it’s absolutely not mobile responsive. I'm like, “Man! This is gross. Who made this?”
[00:13:20] SY: Gross.
[00:13:22] TH: This actually happened to us like a couple of days ago actually. My wife was trying to pay a bill on her phone and we went to the site to go enter your credit card info. And the site wasn’t like mobile responsive at all. It was to the point where just whatever content they had on there, it was cutting off part of the page. And so it was cutting off like where you could put in your credit card’s expiration date.
[00:13:45] SY: Oh, no!
[00:13:45] TH: We couldn’t fill out the form. We couldn’t submit it.
[00:13:48] SY: That’s terrible age.
[00:13:49] TH: I had to go grab the laptop.
[00:13:50] SY: In this day and age, that is truly embarrassing.
[00:13:52] TH: Right. Yeah. You’re losing money from people unable to pay you.
[00:13:58] SY: Okay. So not being able to unsee things, being able to notice all these other things, what else? What’s another quirk?
[00:14:05] TH: Probably more just along the design part of things. So I’ll be browsing and I’ll see something really cool and maybe that’s a neat animation or a parallax scrolling effect or something. Right? And so when that happens, like I don’t just move on with my life. I'm like, “Oh, that was cool.” Right? And keep going like, “I have to dig in, like find out, like how did they build that?”
[00:14:26] SY: What’s the plugin? What’s the framework?
[00:14:28] TH: Yeah. Right? So I’ll start opening up like the browser dev tools and trying to sleep it together. Because for me, it’s like the minified, uglified codes. It’s like, “Okay, how can I find the JavaScript for this?” Or maybe it’s some third-party package or something. So that’s always fun, sort of trying to reverse engineer what people did on their sites.
[00:14:49] SY: And you also mentioned some interpersonal quirks. What are some of those?
[00:14:52] TH: Yeah. So a lot of the things that software engineers talk about and discuss often in very passionate debates about things like, “Should we use spaces versus tabs or what’s the best editor you should use? Do real software engineers only use the terminal and they code in Vim or Emacs? Or is it okay to use VS Code or Sublime Text or IntelliJ or whatever?” The things that come up most recently have been just how we do our agile software development in terms of how we manage Scrum, like what a story point looks like. We’ve had several hours of debates of it’s a story point, a measure of time, right? So I say this task is a one, so it’s one day that we expect to get it done, or is it more like a relative measure of complexity and effort and risks? So is this a two because it’s similar to other small stories that are a two? But we spent hours defining that of what does this actually mean and how should we log these things, right? Like do we break down or do we put story points on the tasks or do we put them on these bigger user stories or even just like the epics themselves? Which is absolutely fascinating that we can spend so much time talking about just like metaprogramming.
[00:16:16] SY: Yeah. Yeah.
[00:16:17] TH: Like this has nothing to do with how we should actually build our products or our future. This is entirely just how do we record and chop our work.
[MUSIC BREAK]
[AD]
[00:16:43] Explore the mysteries of the Python temple, the OSS Elfa pant and the flame of opensource all. While learning the tools, uh, software development with Twilio quest become an operator. Save the cloud, download and play Twilio quest for free at twilio.com/quest. Career karma helps code newbies with free career coaching and a community of peers and mentors.
To help you learn to code and find a high paying job. In less than a year, download the clear karma app and get started in live audio rooms, hosted by bootcamp grads who landed coveted jobs in tech like Netflix, Tesla, Twitter, and YouTube. Be one of the over 300,000 people they've helped get started.
Visit careerkarma.com.
[AD ENDS]
[00:17:12] SY: So you mentioned that developers are really opinionated about their tools and methodologies. Totally, totally agree with that. I have way more opinions than I have the right to. Tell us about some of your specific tastes and opinions.
[00:17:25] TH: So if you want to weigh in on the spaces versus tabs debate, I’m a big fan of spaces. So I’ll go for that. If you want to know more generally, I probably don’t care a whole bunch for that. Just pick a convention and go for it. Code formatters like Prettier are super helpful to enforce that for you. In the JavaScript world, semicolons are optional. So there’s the camp of semi-colons versus no semicolons. I am very a no semicolons person.
[00:17:55] SY: I am inconsistent with that, like half my stuff has semicolons, and the other, within the same function won’t and I just have not made up my mind. I can’t pick a team. Just can’t do it.
[00:18:05] TH: Yeah, got to get a formatter in there.
[00:18:08] SY: Yeah. That’s true.
[00:18:10] TH: Then my other big one is just like the agile methodology. So Scrum versus Kanban. I am very much a fan of Kanban. And the more I do Scrum, the more I start to hate it.
[00:18:24] SY: Well, let’s dig into that a little bit. Tell us what Scrum is? How does it work? And how’s it different?
[00:18:28] TH: So basically like we have this whole agile methodology that we value people over process and we want to be iterative and basically ship things quickly, deliver value to the customer. And then there are different frameworks within which you can do agile. So like some of the big ones are Scrum or Kanban. And so Scrum, you typically have a period of time that you choose to get work done in. So you’d have a sprint, is what that’s called. So you have like a two-week sprint or some people even do one week sprints. And so before and after the sprints, you have sprint planning where you say, “Okay, this is all the work we’re going to pull in. We’re going to get it done in these two weeks or however long.” And then in two weeks, we’ll do this again. Right? We’ll have another sprint planning. Kanban on the other hand is very much just a prioritized list. And so rather than having like these time boxes and periods, we just have a prioritized list. We say, “Okay, what’s our top priority? What would come on Features A, B, and C or just Feature A or whatever?” And, “Let’s go do it.” Whereas I sort of take issue with Scrum is that there’s always like this crunch towards the end of the sprint to get something done. It’s like Friday afternoon and you’re rushing to get this last task done and someone will be pressing for whatever, trying to get something done really quickly. And then you have to ask yourself like, “Okay. Why? Is there a deadline? Is there a big press release happening on Monday or something?” But like, “No, the sprint is going to be over.” It’s like, “Okay.” “So can we get this done on Monday morning?”
[00:20:08] SY: Right. Right.
[00:20:09] TH: So we traced this artificial time box that doesn’t need to be there. And it gets even worse as you go into things like quarterly planning. I don’t know how much you’ve seen it, like safe, agile, but they’re very big on like these quarterly planning increments. So you have like three months basically that you commit to now. And so now it’s even worse. It’s like now we have a three-month time period and have even more uncertainty and more work. And so then you’re rushing to get these things done or you’re trying to eliminate some of the scope in order to make it smaller so that you can finish it within the time period. I don’t know. It makes you make decisions that you wouldn’t have made if there weren’t this arbitrary time box trying to limit you.
[00:20:53] SY: So you also mentioned this idea of continuous learning and how continuous learning is definitely one of the expectations of being in tech in general, but definitely being a developer. And you talk about it as a little bit of a burden that we must bear. Tell me a little more about that.
[00:21:08] TH: So it’s pretty common in the JavaScript world, especially, to talk about things like JavaScript fatigue. So it seems like every day there are new JavaScript libraries that come out and there are constantly new UI frameworks and libraries. Right? So like when I was first starting, it was very much just Vanilla JavaScript and jQuery. And then we started getting into more like templating languages. So jQuery templates existed or something like Handlebars you might use. And then we started moving into AngularJS. So the 1.x version. And then React came along in the Vue. And it’s honestly like exhausting trying to keep up with all that. Right? When I was first learning to code, it was as simple as just you treat your index.HTML file and your style that CSS file and your Script.JS file. And you’re good to go, right? Those were the three things you needed. You needed to learn just a little bit of HTML and CSS and JavaScript and you could start building things. And now, like if you were a new developer trying to break in right now, like let’s say you’re self-taught or you going to a bootcamp or whatever, you have to learn not just HTML and JavaScript and CSS. And this is, I should say, assuming you’re going to be a front-end web developer, right? You have to learn not just HTML, CSS and JavaScript, but you have to learn all the build tools. You have to learn about Webpack and Rollup. You have to learn about these compilers and these transpilers like Babel that takes the new syntax and can use it to the old syntax. And then you have to understand NPM and Yarn and installing dependencies. That’s just massive. It’s this huge ecosystem of JavaScript now that I feel like creates a pretty large barrier to entry.
[00:23:04] SY: So how do you deal with this? How do you kind of manage all this fatigue, especially over the six plus years that you’ve been working your way through a developer career, now you’re a senior developer? How do you manage all of this? Or have you managed all of this?
[00:23:18] TH: I try to always be continuously learning. Right? So to go back to your previous question, just about how important it is to be continuously learning, I try to always take time throughout the week to be, I don’t know, going through a tutorial or watching like maybe a Pluralsight course or LinkedIn learning course, or even just like reading a programming textbook. And so doing that, I think helps keep your skills sharp a bit. And then the other part is just like being intentional in your learning. So for instance, like if I’m, I don’t know, I primarily work out of React right now. So if I need to make some cool animations or something, I might spend some time diving into the different animation libraries that are popular in React, or maybe you need some help learning how to write unit tests. Then take some time to be very intentional in saying like, “Okay, I’m going to go learn how to use Jest or Karma,” or whatever, and actually go write some unit tests. So. I try to do I guess what you would call just-in-time learning of not just learning something just because, but trying to learn things that are relevant to what you’re working on, but then at the same time, not just like learning as you go, but actually like taking time out of your day or your week to say like these two hours or four hours, this is my learning time. And I think that helps a lot to help you stay on top of things.
[00:24:42] SY: So tell me about the reaction you’ve gotten from your piece. What are some of your favorite responses?
[00:24:48] TH: My favorite response so far I think was, “I wish I learned not to click on clickbaity titles.
[00:24:59] SY: They are very compelling. I got to tell you. Very compelling.
[00:25:04] TH: But I really appreciate it, I don’t know, it seemed to resonate with a lot of people. Some people said, “You’ve managed to sum up everything I feel about, about software engineering in this article.” Or, “I have a love-hate relationship with programming and this summed up my feelings pretty well.” So I’m glad that it resonated with people. There were also people that I feel like maybe miss the point, maybe they miss some of the sarcasm in it. I think one guy told me to relax. I take myself so seriously, which was the opposite of the article, but it was good. It was good to see some community responses.
[00:25:51] SY: Coming up next, Tyler gives his biggest piece of advice for those who want to take the leap and become developers, despite the potential quirks after this.
[MUSIC BREAK]
[AD]
[00:26:13] Hey codenewbies. Did you know that all apps need databases? Take a look at your phone and see what apps you have. Instagram door dash, Venmo, Lyft. They all use databases, databases make up the software layer that power our apps and most databases you sequel for writing and querying data. So once you master coding, you're going to want to start to consider the tools you need to create your app, including the data.
The expert, the couple flaps, the company behind the leading database solution. Cockroach DB offer free courses for all skill levels taught by in-house experts. You'll learn about SQL databases and building applications with quizzes, tutorials, and prizes along the way. Visit dot com slash to take your coding skills to the next level and get one step closer to becoming a software developer.
[AD ENDS]
[00:27:05] SY: So are we all hopeless? Are we doomed to suffer these quirks and lifestyle alterations if we keep coding?
[00:27:13] TH: Potentially. I don’t know. I feel like the bright side of it, I guess, is that they’re not so bad, right? Sure. Maybe you turn into a little bit of a pretentious internet user that judges people’s sites as you visit them, but I think we can learn not to. Maybe when it comes to like bikeshedding. Right? So I mentioned that in the article of just all the arguments that we get into, the whole spaces versus tabs, and what’s your favorite editor and whatnot. I think we can learn not to care about things that don’t matter so strongly and realize that it’s okay if someone has a different opinion than you or it’s okay if you use spaces or tabs. Just pick one and be consistent. Or like with your semi-colons, you got to make up your mind. Just pick one and go for it.
[00:28:07] SY: So now I want to ask you a serious question.
[00:28:09] TH: Okay.
[00:28:09] SY: So that article was kind of poking fun at developers, I guess, is probably the best way to sum it up and kind of pointing out some of the things that happened to you when you became a developer. But is there any part of you that does regret learning how to code in any way? Are there moments when you have those feelings?
[00:28:27] TH: I don’t think so. At least in the sense that, I mean, coding is very fun in the way that we get to create. We can take these lines of code and create products and apps that do things that were just in your head previously. I mean, that’s really a deal to me. Like if I were to pick my dream job, I’d go be a musician or something. Right? But I need a lot more talent than I currently have to go do that.
[00:28:56] SY: Right.
[00:28:56] TH: But yeah, I mean, I don’t think I really regret being a software engineer. I think it’s a lot of fun. It’s a good creative outlet. And if I weren’t in software engineering, it would be probably in something similar, just some sort of creative field.
[00:29:09] SY: So what piece of advice do you have for CodeNewbies who want to one day become that opinionated, life-altered senior engineer that you talk about in your post?
[00:29:20] TH: So probably two things. The first is that you don’t have to know everything about everything. I think that was one of the biggest maybe flaws in my learning when I first started. I was trying to learn HTML and CSS and JavaScript, and then also Ruby and Java and PHP and C++ and Python. And I mean, very few people are proficient in that many languages. Right? And so to advise people first learning to code, kind of a common philosophy is that you want your knowledge to be T-shaped, which essentially means that you go very deep on maybe one or two things or a few things. So if you’re a front-end developer, you need to be very good at JavaScript. You need to take probably one UI framework or library, right? So you can fall into a React camp or an Angular camp or Vue camp. Right? And get very, very good at that. And then you also want to have just like a breadth of knowledge, but a lot more shallow, right? So like you want to be able to fumble around on the back end and at least understand what’s going on or be able to make contributions occasionally. You want to be able to understand different frameworks and be able to pick up different libraries, but really that T shape of knowledge is what should be going for. And then the second thing that I would probably give as advice is to focus on the fundamentals. So along the lines of the whole JavaScript fatigue thing with constantly new libraries and packages coming out is that a lot of these are just their new ways of doing things or different syntactic sugar on top of already existing fundamentals or different patterns or whatnot. And so if you can learn for instance, if you can learn JavaScript really well, you’ll have no problem picking up a new library or a new framework or whatever, but if all you focus on is for instance React and maybe figure out how to use React, but you really don’t understand what’s going on underneath the hood or you really don’t understand the fundamentals of JavaScript, then you’re really going to fumble through things because you’ll have a hard time translating those skills into other areas. So yeah, go deep on a couple of things and really learn the fundamentals.
[00:31:58] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Tyler, are you ready to fill in the blanks?
[00:32:05] TH: Let’s do it.
[00:32:06] SY: Number one, worst advice I’ve ever received is?
[00:32:09] TH: The worst advice I’ve ever received, at least when it comes to career advice, was to not leave Qualtrics for “some cosmetic company”, which is what Younique is, was an e-commerce company. They told me that you’d have an extremely hard time breaking back into the tech industry after leaving. And I don’t know if I’m an outlier or if this is the norm, but I did not find that to be the case at all. So I worked at Qualtrics and then Younique and then after that two more tech companies at Instructure and Workfront. And they really didn’t ever bring that up at all. No one said, “Well, why did you get out of tech? What happens there?” No one viewed that as a step down or out of the important industry at all. So kind of the counter advice is that it seems like people are looking more for the relevant skills and experience, not so much the prestigious company names, as exciting as it is to say, “Well, I work at Facebook or whatever.” Just focus on your skills and don’t be somewhere that you feel undervalued or somewhere you don’t want to be just because a tech company.
[00:33:19] SY: Number two, best advice I’ve ever received is?
[00:33:23] TH: Yeah. So the best advice I’ve ever received, I was 20 years old and I was actually serving a two-year mission for my church and talking with the guy at this time. And he had told me, he said, “We were talking about just the future. What are you going to do when you get back home?” Right. Because I had been going back to college and essentially moving on with my life. And he told me, he said, “God will open up opportunities for you that you can’t even imagine right now.” I think that's great advice, regardless of whether you’re religious or not. Right? But that there will be opportunities in your future that you can’t even imagine right now. And that was very true. I’m 28 years old now. So this was eight years later, and yeah, my life is way different than I thought it would be. I thought I was going to go get my master’s degree, be a psychologist, be a counselor.
[00:34:17] SY: Be a counselor.
[00:34:18] TH: Yeah. And here I am and I’m married. I’ve got two kids. I’m a software engineer. Yeah. My life is way different than I thought it would be eight years ago.
[00:34:29] SY: Number three, my first coding project was about?
[00:34:32] TH: My first project was building Flappy Bird. So that game, if you remember that, that came out, it was like 2013, I think.
[00:34:41] SY: I was going to say that’s a while.
[00:34:42] TH: Yeah. That was a while ago. And then it was shortly removed from the app store right after that. But Flappy Bird was all the rage back in 2013. And I thought that would be fun. That was something I was curious about. I was like, “How could you make a Flappy Bird? That seems simple enough. Right? You press a button to make a bird jump and you don’t hit some pipes.”
[00:35:04] SY: Yeah, yeah, for sure.
[00:35:05] TH: Yeah. So I built a little web version of that, and yeah, that was a pretty fun first experience.
[00:35:12] SY: Number four, one thing I wish I knew when I first started to code is?
[00:35:16] TH: So one thing I wish I knew when I first started to code, and I think we touched on this a little bit before. It was just that you don’t have to know everything about everything. It’s a huge, huge field, and there are tons of different specialties besides just front end and back end or dev ops or an SRE. You have all the different languages within that. They’re very different skill sets in software engineering. And even like the most senior software engineers who have been doing this for 30 or 40 years don’t know everything about everything. And so don’t beat yourself up about how much you don’t know because everyone is very much in the same boat.
[00:35:59] SY: Well, thank you so much for joining us, Tyler.
[00:36:01] TH: Yeah. Thanks for having me.
[00:36:09] 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.