If you've been thinking about getting into software development, coding, and software engineering, this episode is for you!
Ken is a wealth of knowledge and we were very lucky to have him sit down and go over what he did and what you can do to become a software engineer!
In this episode, we talked about:
• How Kent worked his way up from a customer service role to becoming a senior software engineer
• How you can be a software engineer/developer without a degree and experience, and what are the best resources to learn
• How you can learn which languages or technologies you should learn by finding a job backwards
Ryan and Kent also talked about the day-to-day life of a software engineer and how you can prevent tutorial hell.
Enjoy the episode!
Check out our workbook to learn how to Teach Yourself. Get Work. Make Money. No Degree Needed!
Join the Degree Free! Receive our weekly newsletter and get exclusive tips and tricks to get hired and make money without a degree!
Check out the previous episode and learn how to repurpose your education and achieve financial freedom!
Ryan: Aloha folks, and welcome back to Degree Free where we teach you how to get the work you want, no degree needed. I'm your host, Ryan Maruyama and before we get into today's episode, I did have one ask of you folks. If you guys wanted to stay up with everything degree free, different companies that are going degree free, different degree free jobs, different tactics and tips to get you hired without a degree, go to degree free.co/newsletter and sign up for a weekly newsletter.
Now without any further ado, let's get to today's guest. Today, I am super excited to have Ken Utterback with us. Kent is a self-taught senior software engineer and we go over his entire story and how he broke into the industry and how you can to definitely give this episode to listen. If you've been thinking about, definitely give this episode to listen.
If you've been thinking about getting into software or if you know somebody that's thinking about getting into development, coding, software engineering, share this episode with them. Ken is a wealth of knowledge and we were very lucky to have him sit down and go over what he did and what you can do to become a software engineer.
And without further ado, please enjoy my conversation with Kent Utterback
Aloha everybody and welcome back to the Degree Free Podcast. I am very excited to have Kent Utterback today as our guest. Kent, thank you very much for joining us.
Kent: Yeah, it's great to be here.
Ryan: We've been trying to make this happen for a long time, and I'm glad we were able to put it on both of our schedules and get you here.
around our big life events too.
Ryan: Right? Exactly. And I guess first of all, Kent, the first thing I'd like to ask you is just a little bit of your background. Currently, specifically what I'd like to know is what you currently do for work.
Kent: Yeah. I'm a software engineer. I basically write software all day and the short of it,
And I find one of the biggest problems is not having a target when you're trying to reach your career goals. And part of that is knowing what's out there. And so would you mind explaining a little bit about what a software engineer does? And a follow up question to that is what's the difference between a software engineer and like a coder and a programmer?
Kent: Yeah. So those are some great questions and I agree. That was one of the things I struggled with too early on, trying to figure out where I wanted to go. But let's see, software engineer is a very broad term. Same for like developer and coder. It kind of just depends on the company really, the names are very interchangeable.
There's not a big difference but you will see, if you're out looking for jobs that a software engineer role is more geared towards the people who are doing a lot of like newer things and more difficult things, right? Stuff that's very novel and up and coming. They'll kind of call them engineers cuz that's kind of what they do, right?
They take, their past knowledge and skills and kind of design out stuff and then implement it. That's kind of what an engineer does, and then like a developer on the other hand will do, will kind of just be somebody who writes a lot of the code. They may not be doing a bunch of novel stuff, like. Especially what I do. I've been in the corporate space for a while and a lot of that is nothing new , everybody's just doing the same old patterns that were invented like a decade ago and they're just trying to adapt that to their business and bring their business online and use technology to do their business.
And that's kind of where, where those intersect too is there they can be sometimes interchangeable 'cause you will need, even for the corporate stuff, you will need some of those engineering skills and you'll also need those developer skills. And so in, especially in the industry that I'm in, they're very interchangeable.
Ryan: I guess to kind of summarize that, is an engineer kind of in charge of newer features and kind of where the product is going or where the, I guess the overall product is going and then the coder or developer, they kind of boots on the ground actually, actually do it.
Kent: I think so, in short, but like I said, a lot of companies will use the term interchangeably and you will see a difference.
If you ever look up like salary for the different job titles, there is gonna be a bit of a difference. You will see that I think developer and coder or program or titles end up a little bit lower on the scale than say like the engineer tacked onto it. But as we go further in our modern day, like they're really pretty much the same thing.
There used to be a big difference between them, but it's far less these days.
Ryan: I have one more question on this kind of knowing our job titles. Where does a software architect at? We've seen that a bunch of times, like I have no idea what that means.
Kent: Okay. Yeah. So that's kind of software architect. That is one of my current career goals.
That's kind of a next step for me cuz my current title's technically a senior software developer since I've been doing it for a while and I have, you know, some knowledge that comes with a little bit of leadership responsibility but an architect, software architect is somebody who kind of decides where the platform is that you're building is gonna go technologically, for example, they're the ones who are gonna decide whether we're gonna start implementing events or what kind of database technology to use or what languages we should be using for certain solutions and things like that.
Ryan: I see. So instead of just like a startup where they're just like, I only know Python or whatever and then you just build the whole thing in Python, the architect kind of from the ground up. You're like, Okay, well this is what we needed to do and these are the most efficient, I guess, code. I'm a layman, so correct me if I'm wrong but like this is the most efficient way to implement this different software and these different features in order to reach success.
Kent: Yeah, basically they'll also, try new things. So they'll do like proof of concepts for certain technologies and stuff to evaluate them for their applicableness?
Ryan: Is that a word? It is today.
Kent: I don't know, I don't think so, but yeah, it is today.
Ryan: And so you mentioned a couple of times in your industry. Can, do you mind talking about what industry are you in?
Kent: Yeah. so I'm primarily in the web development of stuff. I do a lot of websites, a lot of services, a lot of stuff that basically connects things for the company in order for them to run their business and have a better online presence.
Ryan: And so for those out there is that mostly front end stuff or is that, are you working on backend?
Kent: Currently I do both. Throughout my career, I've also done both as well. Sometimes the roles are independent, like there are people who specialize in just doing front end. There are people who specialize in just doing backend. There are also people who specialize in doing both at the same time. They usually call those full stack people, full stack developers.
My current company, I've done both sides. So my current team is a full stack team, so we do both front end, back end work.
Ryan: One of the things that we've heard a lot about is product managers. Like one of the titles that we've heard a lot about is product managers, and I guess we've had a product manager on this show before and we were talking about how they kind of come up with the vision of the software. Does your company use product managers?
Yeah, we do.
We call them project managers and product owners. They'll actually take a look at what the business wants to do. They do a lot of the outreach to our clients and kind of talk to them about what features they want implemented.
And then they kind of give us, as developers a rough idea of what that's gonna look like. Sometimes they bring in more art based people who will do some mock up designs in like, Services like Figma and stuff where you can kind of just do very graphical. Some people use, Photoshop and stuff to do mockups of what interfaces are supposed to look like, but they, we have a very open back and forth with the product owners and project managers to kind of understand where we're supposed to be headed forward.
And then it's my job as developer to implement that in code and how that's gonna work within the ecosystem that we're building.
I kind of wanted to go back to the beginning when you first, started as a software engineer. We had you months ago fill out. Well, we didn't have you, but you graciously filled out a little questionnaire.
Yeah, exactly. I would make you do anything and for everybody that wants it, I'll leave these in the show. Notes. degreefree.co/podcast there's a wealth of knowledge here and it goes over Kent's entire background, so I won't belabor it. People can just go to the website and look at it, but I did wanna quote the couple of lines here. Our question to you is how did you get your current job? And I'll just read your answer quickly. I said I first got my start switching from customer service and bugging the software manager and interviewing every time there was an opening. The fourth time, I got my first developer job.
Can we talk a little bit about what you did with customer service and like how you made that transition?
Kent: Yeah. So that one that was an interesting time in my life. Basically, I was trying to figure it out at that point and just like everybody else in the world, they tried to figure out where they want to go in their career and I really wanted to do the whole software development thing and I had a hard time breaking in anywhere I went on interviews for a while, didn't really work out so well.
They ended up hiring like, you know, people with more experience, even for entry level roles. It was super weird. Yeah, so I started working for this company that had a software product as a customer support person with a little bit of development skills already had. One of my duties as a customer support person is they gave me access to the Alliance database and I could run queries and stuff, which was kind of cool for that position.
Not every customer support's able to do that, but it was a nice, like, small company, so we were able to do that. Larger companies kind of don't really let you do that sort of thing. There's a whole process and escalation, but the way it worked is like level one, we're kinda just answering basic stuff.
As a level two, we get a bit more access with like the database and stuff. That's kind of where I ended up and then the level three was basically the junior developers on the developer team and they would actually go on the code base and look for bugs and other things that our customers were reporting. And at the time we had a bit of a bit of a high turnover in the junior developer space, and I knew it wasn't like the best position, just by the way the senior developers ran the development at that company.
And it was a very small crew. Every time there was an opening, I would submit my application to the development manager and I had like one interview with them. I answered their questions. I even talked to some of the engineers. They seemed to like me, but they ended up going with somebody else, right?
And then I did that at least three more times. And it wasn't until the fourth time that I had bugged him for it, they were like, All right, this kid's already asked me three or four times, has to like, every time you rejects me too. I see him in the office every day after that too, right? So, it, it must be a weird situation for him of rejecting some person and then to have to see them every single day.
At least every working day in the office. Then finally the fourth time, this was like over span of several months too. Yeah. So like several months this guy's just been rejecting me and at some point he's just like, All right, we need a junior developer was like, I think he was just like maybe tired of hiring people.
He was like, All right, come on over. He worked out a deal with my customer support manager and I ended up getting my start as a software engineer and that's where I started.
Ryan: That is amazing. And I guess just for clarification, the customer service role that you were in, was it a B2C, company or B2B company? Who are you helping for the customer? Who are the customers?
Kent: That's a great question. So the company that I worked for was actually in the education space and our clients were technically college students. Mainly people who were getting MBAs, and that's just who we worked with.
But our, the people that I talked to on a regular basis were actually administration at universities through their career services department. So it was a lot of people in career services who ended up being kind of our customers. We never really talked to any of the students, but basically if the students had issues, they would tell the customer or not the customer, what is it, the career services people, they would call us or submit a ticket and then we'd investigate into it.
So it's kind of b2c, but also b2b to a point, if that makes sense.
Ryan: That makes sense.
That does make sense.
One of the things that I see as a recurring theme, we're having these very gracious people just like yourself, that don't have degrees and that have broken into all different types of industries. One of the things that we see is a main thread between everybody is the persistence.
I mean, I know for myself, I couldn't get rejected four times. There's this, I would be done after the first time. I'd be like, Nah, okay, I'll just sit here and do the customer service thing but the fact that you were able to go and see people get hired and then not ultimately not fit the role and then keep going and going.
That's amazing and do you think that there was, that had something to do with it, The fact that you saw that revolving door of people, did that help in your confidence to think that you could do the job better?
Kent: Not at all, actually. Quite the opposite.
Just like you, every time the rejection hurt, like it does hurt every time and it takes a bit of a thick skin to try to achieve getting in like that.
But I just knew it wasn't gonna work unless I kept trying, what's that quote go? You know, you miss every shot. You don't take, I think that was what Wayne Gretzky or, you know, if you're an Office fan,
Ryan: the Michael Scott,
Wayne Gretzky Michael Scott .
Yeah. Wayne Greski. Michael Scott Kent Utterback, there we go.
Ryan: but yeah, absolutely. One of the things that I was wondering, you had this junior software developer role or junior developer role. What were your technical skills at that time?
Kent: My technical skills at the time I had, well because I was doing the customer support role, I got a lot of practice in writing SQL queries.
But I did have at least one like good senior developer who was able to kinda like, point me in the right direction and then I took, class on Udemy to learn C#. I made like a video, a couple of video games off of that course too. Nothing I would like, you know, release on steam or anything.
It was like real, real basic things. But those kind of things really paid off, I think.
Ryan: They hired you for this junior developer role and you didn't know the two main languages that they used basically. I'm just trying to summarize this here and did they invest in you to learn those or did they, did you just say, I am going to, I know that I need to know these languages for this job and I will learn it on the job and I'll learn all my free time.
Kent: So they didn't at first. What ended up happening is once I moved over, the junior developers had a real process problem because they served mostly as like the QA for the company and they had a very large backlog of tasks that they were just not keeping up with real time.
And it took them from like, when a bug would get to them, it took them a couple of months before they would even begin to touch it, right? And so what one of the things I did is I was real tired of just doing like QA, just bug hunting. So I kind of noticed that there was mostly a failing of the organization of how they, how we split up the work between us.
And so I came in and convinced them to do a bit more organized so we're not stepping on each other. So we're getting things done a lot quicker and what happened is I actually freed up so much time that they decided to invest in us, in our development skills as a result. So after I got them to basically near real time, we're like actually getting to bugs the same week or even the same day as they were being reported, or escalated to us that we opened up so much time that the development manager was like, Hey, I want you guys to learn, you know, more of the language and stuff and want you to get more involved in development. And so he basically gave us, at our, like our yearly or quarterly review, I can't remember which, he told us that he would like to see us do a project together that wasn't related to the company at all.
We could basically pick whatever we wanted as long as it involved the language that we used at work and we decided we wanted to play because of the video game stuff that I made, I was like, Hey, I could help these guys make a video game. We could all learn C# together, there was just three of us junior engineers, and so it wasn't until I like cleared off the backlog, they were willing to kind of invest that time into us because like most of the seniors were doing a lot of the heavy development load and the new, like the new features.
So they couldn't really justify just like paying three junior developers to just sit around. So it was like, well, might as well get invested in their careers. And so we kind of did that.
Ryan: Just to define the term, you said QA there, just to define QA. Could you define that for us please?
Kent: Yeah. QA stands for quality assurance and basically that's a type of developer role too where you kind of test out the code that's been written already and there's two ways to do that. You can do it like manually by clicking around in applications that are built to try to get the desired behavior from the application.
You can also write like extra code and stuff to run automated tests to test the code, but it's basically testing the code is what a QA does.
What I wanted to get into there, I wanted to dive a little bit deeper into, you said that you created a system and was the system, did it have nothing to do with coding?
Were you just, how did you look at that and said, say like that needs to be fixed, and then how did you come up with a solution?
Kent: Yeah, it had nothing to do with coding, the ticket tracking software that we had. Basically what happened was we just had this big backlog is like a single page or whatever, and we would get these escalated tickets to us to kind of look into these issues and test the application and figure out like why.
These bugs are happening and it just went to this giant pot, and a lot of these things were like really old. I noticed that every once in a while you'll get one that you like click into, and although it was not working back then, it's now working because of a fix that, or like just some code that somebody pushed out in the meantime.
So basically I sat down with the somebody who knew our ticket tracking software a lot better and just went through and started using the tools that the software provided, 'cause they weren't. A lot of times we were like stepping on each other's toes by doing the same ticket at the same time without knowing and so we're like wasting this time when we could be, you know, actually writing code instead of just investigating code. So I wanted to me as a, like an aspiring developer, I wanted to get to the writing code part. I was real tired of the whole testing code, so I just wanted to make it go as quickly as possible.
And so I came up with an organization system and used some of the tools, so where we can start assigning the tickets to us individually. So if we went into the ticket, we'd say, Oh, hey, so and so is already working on this. I can kinda let them do their thing. I'll pick something. I also had them write in the software allowed you to be able to query for specific things, and so we went in and cleaned up stuff.
We started cleaning up, so like , the scenario I mentioned before where something had been fixed in the meantime of the ticket being submitted and us looking at it. I went in and I think I had a daily, a weekly schedule. There were only three of us. So like one day out of the week, one of us would just go in and start cleaning the backlog for all these easy to do things that just weren't a problem anymore, just to get them out of there.
And so that's what we did. We started rotating days where we'd just spend a, I think like half the day just going through the queue, looking for all these easy things that are there and getting rid of them because they're either finished or it's just a quick reply or something, you know, and everybody else could start working on more, a bit more complicated except where they actually have to put in the time and effort to test.
But yeah, so it's kind of more just like a process of the whole system and how they worked and I think I did was it took about a month of doing that to where we were getting to the real near, near time. and that was one of the really amazing things and I think they really appreciated it too, 'cause I know there was at least another developer on my team who wanted to actually write code too.
He was doing a lot of the same like learning stuff outside of it. His degree wasn't in software development, he was a music production person, so he had gotten a degree in music product but didn't really know much about coding. So he had to also learn it by himself too. So it was really nice for him to kind of get there with us.
And he was real excited when we started being able to do projects and stuff and actually invest in our careers in that way.
Ryan: That's awesome and I get what a lot of people say when they're like, I can't break into a different industry, or I don't have domain specific knowledge in that industry, I can't provide value.
That's a perfect example of how you were to a, you were able to provide value without really being that awesome at coding and just kind of looking at a problem and fixing it. And then now the company is like, Well, these guys are kind of just sitting around, we might as well invest in them so that we can get them up to speed.
That's awesome. That's a great story. Thank you for sharing that.
Ryan: You mentioned you took that you Udemy course on C# and then you made like little games. One of the things that we hear. A lot about when people are first learning to code. They were talking about like projects and personal portfolios.
I guess there's a few questions that we're gonna go down this road. One is do you know of or do you have an opinion of the best language to learn when starting to code and then second after that is how do you pick a project or if a project is even the thing to do to in order to like concrete your learning.
Kent: Yeah those are very good questions. So to the first one, I would say yes and no. It really depends on what kind of like software developer or software engineer that you want to be. Cause there isn't really like a one size fits all, like the best of the best kind of thing to do. There are mainly just the best within certain categories, right?
So, Kind of have to do little exploration and even programs like yours kind of exposes people to what, different roles are out there. I know you don't always do like software engineers, developers, but it still kind of applies to that, those industries as well. And you kind of have to figure out where you want to go and then you can kind of map backwards a plane of attack.
And that's, that's kind of what I did originally. I had a very scattershot approach and that was a big detriment to my job hunt in the beginning is I was trying to be far too broad, specializing early, and then broadening after that is definitely the way to go. A lot of people will start with like front end or back end and just kind of choose a specific language.
I recommend looking at job boards and seeing what's available in your area. If that's your end goal is say, Hey, I want to get a job. I wanna do this as a career. Start looking at job boards. Just start. Typing in general things to Google. Even if like you don't know what the titles are, you can go to Google now.
Internet is a beautiful thing and you can go in and just type in software job titles or something like that and you'll get a list. Somebody's got a list somewhere. And there's even on like communities too, like Reddit and different Discord servers, depending on like where your circles are, there's always people that come up with these infographics on like what languages and technologies you should learn in X year.
They come out with different ones, like different ones every year. Like, for 2022 you can google like best languages to learn for 2022 and a lot of people have an infographic for it and you kind of start there and work backwards too. So if you like look at the job markets, see what's available and what languages the people are using near you or what, like is within your, in your area, even remote to companies that Remote first will be kind of dealing a lot more web stuff, right?
And so they'll have a bunch of web technologies. You can kind of just look at the job market and see what people are hiring for, and then go look at the technologies that people use to build those things. Then you can look at courses on like Udemy or even, there are a lot of community groups that do it.
And so that's kinda just my advice there.
Ryan: That's perfect. Just to jump in here, what you suggested about looking job postings and then kind of seeing what's in demand and then kind of targeting and aiming your learning based on that is perfect. We suggest doing literally the exact same thing. We call it finding a job backwards. For us at Degree Free, We think it's kind of common sense now cause we've been doing it for so long, but it's really not that common apparently.
And it just makes sense to, intuitively, if you think about it for a second, okay, I wanna be there. Let's go look at if software engineers is what we're talking about today. I wanna, learn how to, I dunno, be a software engineer for Meta and you just, okay look at what they need and then try to aim your career that way.
Kent: Yeah. So there's actually a term in my industry for that they call it tutorial hell. That's exactly what it is you're basically, your entire knowledge is doing what tutorials do and not necessarily expanding upon those concepts. That is one of the downsides, One of the thingsI've hated about tutorials is that they basically set you up for an end goal.
You follow the steps to achieve that end goal, and then you get there and you're like, Awesome. I built something. There's a real lack of like what is actually going on and why you built things the way you did and unfortunately that kind of comes with a lot of reading and a lot of articles that kind of just talk about technology, not necessarily tutorials.
So you kinda have to do a good mix of both or One of the things that I liked about the freeCodeCamp Place was, it was also community based when I had lived in Ohio, I actually ran the Columbus chapter for a couple years and we had meetups. We would get together, we would talk about different challenges, we'd go over other side projects.
Sometimes we'd pair on things but there was always like a mix of people who like knew what they were doing, people who didn't know anything at all, somewhere in between and yeah, that's kind of the way that I went. I was able to like, ask a couple of people questions. They bridged a couple of weird knowledge gaps that I had because like I did, kinda like you, I did do a few things from tutorials and then I tried to say, Okay, well this is thing I want to do is similar and I tried to do it.
It didn't work out. And then I didn't really know why or how to fix it. So then I had to, kind of ask and Google a lot and then ask for help. There's actually, uh, there was a method, I can't remember what it's called off the top of my head, but basically you try to do it first. If you fail that time, google it, and if you can't find the information on Google, then reach out to the internet or reach out to a community of some kind, and then hopefully that will end up, bridging the knowledge gap for you.
Ryan: How did you end up running the Ohio chapter of that meetup?
Kent: So I had joined it along with like, there were some other people in there. By the time I joined the group was kind of in a lull for a bit. There were some people before me that weren't really managing it too well. Somebody who was also really new to coding kind.
Stepped up and took over management of it and because I had the time then and I spent a lot of time with the group, I started to kind of just merge into, a management role as well. I helped like plan stuff. We reached out to different venues in order to like, to go to like libraries around the city and like other open spaces that had decent internet connections.
At certain point we ended up attracting people who actually were software developers who worked for companies who loved to do community outreach for like new developers. There was a, there were a couple like consult software consultancy firms that loved that sort of thing. After hours they would allow people to come to their office and they would have a point of contact.
You can be like Hey, I have this group, we'd like to have some space to meet, and they're like, Yeah, sure. You can come by. Here's our address and here's the front door code. Um, just make sure you're out by this time cuz we have a cleaner coming in at that point to clean the place and we wanna make sure there's nobody in there for them to clean.
And it was totally fine and, it was just a personal connection to get spaces for us to exist and to kind of collect and, share our knowledge together and talk about engineering concepts and implementing things.
Ryan: With that. It seems. Like that is an integral part.
I mean, I guess for anybody's learning but is to get into a community of people that are trying to do the same thing, and that's a really awesome way to kind of make sure that you are with those people is to kind of head things up. One of the things, not directly related to what you're saying, but one of the things that we always say, To people is try to improve your network.
And that's such a, like a cliche and everything, but one of the things that we tell them to do is to do exactly what you did, which is head up some sort of, community or meet up and it kind of gives you an excuse to reach out to people, like you said, these software consultancy firms that otherwise probably wouldn't have given the time of day I'm guessing. But you said, Well. I run the Ohio chapter and we have this meetup.
I would love it if you. Could give us some resources to help.
Kent: So, yeah we actually had a few people who went through like the freeCodeCamp courses and stuff who ended up working for those same companies. So they did, some of those companies actually used it as a pool for like new developers to kind add to their workforce as well.
So it their investment in the community kinda helps them out without having to invest anything. Like they're already paying for office space and like the utilities on the place, they might as well kind of like let some people use it with some control access but
Ryan: switching gears, again, I kind of wanted to go back to when you first became a software engineer and a junior developer.
When you, One of the things that we see when people are making huge career transitions come from like customer service role or to a software engineer, or from like a teacher to sales, anything like that. When you first get your job, a lot of people feel like they're underqualified or unqualified completely for their job.
And I'm just wondering for you being in that junior dev role, did you feel qualified at the time?
Kent: Definitely. I definitely felt qualified. The other junior developers weren't great at development either, so I felt totally fine. Like there were three of us and they all, both of the other two guys, um, came from different backgrounds.
Like one guy was music production, the other one was, I think his College degree was like a communications degree or something like that. None of them had anything to do with software, how computers work. They weren't even in any of the STEM courses but yeah, so there was a certain point where I was kinda like teaching them some things because I had done those like Udemy courses and that's kind of why I stepped up and kind of took the lead for some things.
But I could definitely see if you come in and you're a self-taught person and your coworkers are a bunch of college educated people, , there is a difference and you definitely will feel like you are lacking knowledge that they somehow have but I can definitely tell those people who feel that way is most of it's an act and really. The biggest difference that I found between self-taught people and college educated people is the nomenclature. Just this, like, your average person would call a dog a dog, but like, a science educated person would call them a canine or give you like the full kingdom and file and all the scientific Latin names for stuff.
It's basically you're talking about the same thing, but they're just using different words to describe what they're trying to portray. That was really the hardest for me, dealing with people who do have the college education was figuring out, all right, what does that phrase mean? And then I would Google it and I'll be like, Oh, I know this pattern and it just makes so much sense.
And I was like, why wouldn't you speak to each other like layman? Why do we have to have all these complicated terms that are basically gate kept by universities to describe different things? And I always thought that was weird, but it is. It is a hazard of the job, unfortunately, especially with a self-taught person.
Ryan: Funny story,
Maybe not self funny, but I remember when my buddy, he was first trying to become studying to become an EMT and we were studying together. I was dumb and I went to college and I was studying for my useless degree, and he was studying to become an EMT and he would just blabber on about like this acronym and this acronym about the human body and this and that.
And I was just like, Man, are you trying to have a conversation with me or are you just like trying to tell me how smart you are about all this stuff? And then he would break it down about like, Oh, it's actually the, like your cardiovascular system. And be like, Oh, okay, well then why don't you just say that?
But yeah, I find that knowing your vocabulary in many industries, whenever I'm trying to learn about new industry, that's the first thing that I do. I make, I try to go, I like Google, like construction industry vocabulary. And I'll literally make flashcards of like 16 on center, 18 on center, you know, I Frames, whatever, A frame.
And just knowing the vocabulary and when to use 'em. Can make you feel like you belong basically.
Kent: Yeah, it definitely does and, and I think you're right. I think some people do stick hard to the nomenclature. Be like, Hey, I went to college. I am smarter than you .And it's really funny when you find out like they do their job compared to like the way you do your job.
And you, if you guys are doing the same job and if you ever look the comparison, there's not much of a difference. I've even had, like, I had one manager who was also a self-taught developer too, which was cool and I talked to him about it and he definitely kind of like mirrored the same sentiment. And as I was like, I don't really get the, like the popness of the whole thing.
I was like, it doesn't really make you better. You just know a couple extra words than I do, even though we know the same concepts, I just know them differently.
Ryan: Yeah. I think a lot of it too can be like the sunk cost of it all. Like, you know what we found a lot is that, and rightfully so, I get it, people spend years and years of their life and tens and some, in some cases, hundreds of thousands of dollars to get their degree and learn this nomenclature and learn the vernacular and of this subject and they wanna show it off.
But switching gears to both, since we're talking about college, I did want to go back even further to your decision, as I understand it, you don't have a degree, and I was wondering if you could kind of walk us back to high school and what you were thinking when you were, I think you did go to some college and kind of that pro timeline.
Kent: Yeah, so I'm in a bit of a unique position for someone who's a self-taught developer, a lot of people either have the college degree that's in completely something completely different in transition. Some people don't go at all. I find that I actually went for about four and a half years.
I went long enough to get a bachelor's degree. I was originally studying for mechanical engineering at the time, but I ended up running into financial problems. Basically, what a lot of people don't understand is in order to pay for college, lending is very weird when it comes to paying for college and you actually open up like a massive line of credit, but it does have a limit.
A lot of people usually don't hit that because the national average isn't, I mean, it's way too high, but it's not higher than those credit limits. For example, one of my loans, the credit limit was like, I think like $90,000 or something like that. I ended up racking up about 150 grand cuz I decided to, for whatever reason, go to a private school, which was something I absolutely regret and still ended up not finishing.
I got, I had like couple semesters left and at that point I ended up with like my parents unable to cosign for more stuff because of debt to income ratio and I had already maxed out the line, like the 90 grand, already and a couple of other lenders that I was able to get in at the time and I literally just couldn't pay for it.
Because I moved across country and it's been so long, I can't really go back and finish unless I were to go to the exact same college. And that'd be way too difficult logistically, and it's not real worth it in my opinion but that's, that's kind of where, what happened for me. My original plan was I wanted to go and get a mechanical engineering degree and then I ended up wanting to go and get a master's degree in like aeronautical.
I originally wanted to break into like the aerospace and aeronautical industries and, design like planes and like rockets and drones and stuff.
Ryan: And are you still trying to get break into that industry but in a software sense or is that completely gone?
Kent: My long term goal is to actually start my own company. I would really like to, 'cause I mean I went for four and a half years. I basically got an engineering degree. I took all of my engineering classes. I think I would needed like a second electronics course and a few gen eds, something like that. I would've ended getting my bachelor's degree but if you can't pay for it, like they're not gonna give you the piece of paper whether you're almost there or not. Right?
So basically it's a wash at this point and I still retain a lot of that knowledge and I still have a lot of the textbooks from it and learned a lot, like, was it worth that much? Probably not, but it was still a decent education. And the software venture has kind of brought me around to the second side that I wanted to hit too, is I was real interested, especially when I was in school about how the software and hardware interacted in stuff like robotics and automation and stuff, where you go from software to controller to mechanical.
And that's kind of where I wanted to go is I wanna do. wanna create my own, like small research and development firm small project solutions for companies. And the ultimate goal. So eventually, I would like to get there, but it is gonna take a little while for me to kinda like build up that much capital in order to make that venture work and create more context, but one day I'll get there.
Ryan: So would that be like, I guess, could you gimme an example? I'm trying to think of like when you talk about that, I kind of go to like. The, I forget the company, Boston Robotics or something like that, Like where they're actually making robots. But I think, I feel like I'm super wrong.
And could you gimme an example of like, what kind of solutions you're thinking about?
Kent: Yeah, so that's actually a really good example. Something kinda like that, but a far lower budget I'm not, probably not gonna be out here, trying to build robotic like AI dogs or humans and stuff like that.
But, let's see. There were lots of TV shows when I was growing up that kinda covered this kind of thing. There was like, there's this, like one company, I can't remember the show that they were on, but this one company built these like off road wheelchairs and they got a letter from like a veteran who kind of like, who had an injury from serving and he really liked to go hunting and stuff and liked to get back out into the woods.
So he reached out to them cuz they do like these offroad, single person like vehicles and so what they ended up doing is they made him this this like, Part tank part, like forklift kinda thing where he could like drive it out into the woods and it had like a gun stand on it so he could go hunting again even though he was disabled.
I thought that was super cool but you know, stuff like that, biomedical, there's a lot of stuff going into, like the medical industry is always progressing. Aeronautics as well, like when I originally had this idea, drones weren't really a thing yet. It was only military applications that you had ever seen drones, and they were more fixed wing, like aircrafts and stuff.
But now, like it's gone so much to the commercial side where you can pick up drone parts for like 200 bucks and if you have a micro controller and some like programming skills, you can basically make an AI drone for like 200-250 bucks. And that's, you know, on a scale for a company that's not a whole lot.
So yeah, just there's, yeah, just like with the available new stuff, I just kind of want to keep pushing things forward.
Ryan: Awesome, awesome. And kind of circling back to what we were talking about, I'm not sure if, we finished on it just talking about like projects .
How did you, when you were first learning after Udemy course, how did you decide to make those little games?
Was it, were those tutorials and I guess how can other people think about their project selection? Is it like whatever the tutorial says or should they come up with an app idea? Like if they wanna make apps, like come up with an app idea and then go figure out how to make it?
Kent: A mix of both actually. Starting with tutorials is great to kind of get something accomplished and it also, because it is somewhat tutorialized, you can kind of look for software patterns that people write in and can kind of get you into better habits too. A lot of people who put out tutorials spend a little bit of time to kind of like clean up their code so it looks nice and so it makes sense.
It's not gonna be super performant or anything like that, but at least it's a good industry kind of standard. Then once you kind of like get a lot of the basics down, then you should absolutely come up with some novel ideas. Or even if you wanna like recreate stuff, there's a lot of tutorials.
People out there a lot of times will like recreate Flappy Bird cuz it's pretty simple and it's something that you can do fairly easily. A lot of people will go out and make their own, like Twitter or their own like social media of some kind. A lot of people take directly from like Instagram and you do end up learning like a lot of good skills on how to handle things like just having image, having a data storage solution, being able to recall those things for a graphical interface for a user.
And a lot of those techniques and theories apply across like many different industries and different applications. And so if you can kind of build things that are within your wheelhouse or like at least attainable. And I'll kind of explain that in a sec. It really will benefit you in your learning if you can kinda build those things and then use your creative mind to kind of bridge gaps between what you just went through the tutorial and learn why it does the way it does.
Cause when you start building the things from like scratch straight from your mind, you kind of have to get creative. And if you know how, if you studied how it works, you can kind of bend it to bend what you learned to what you want to do.
Ryan: And how much planning do you recommend when they're thinking about doing this?
I guess like do they need to go through the whole, like I guess if they're learning like how to make a website or something, do you need to go through the whole like wire framing of it and like mocking it up? Or do they just like pen and paper, write it down? Or do they start clacking those keys?
Kent: It really depends on what the goal is.
If you're trying to build something just to learn, do whatever you want. So if you're the kind of person who likes to plan it out to be like, Hey, I want this, I want this, I'm gonna draw it on piece of paper, that's fine, do that. If you just wanna build something just to build something, you should also do that.
Just start typing away start somewhere. Anyway, if you're the kind of person who can kind of just go at it, that's great. Go ahead and do that. I will say that if you don't at least plan a little bit, you might get stuck and frustrated when you start working on something that like really interests you and you will kind of neglect a lot of the more, boring stuff that you kind of already know, but you still need to do anyway.
So having a small plan is always helpful, but it doesn't have to be anything like building out wire frames or like drawing it up first or anything like that.
Ryan: Now that you're like a senior in your career, do you see any important skills that new people that are coming into your industry lack? Is there any, are there any skills that you are like, You should be better at this, or like, maybe you could be better at this.
You should know this.
Kent: It's a great question. I haven't really noticed it too much because a lot of people who are just breaking into the industry, they're pretty much up to date on a lot of the technology. When you go out there and search for things, basically, especially for software engineering and development.
A lot of what you're gonna find in like the top of Google listings is gonna be almost the latest and greatest thing. Unless you're doing like a tutorial that's like five plus years old, you're pretty much implementing current modern patterns and strategies. What I really find is dealing with people who've been in an industry for a long time, who are unable to connect with the people coming in is where the biggest issue is.
There's a lot of people who will come into the software industry, learn the things, and then don't really keep up with new techniques, new habits, new , new languages, all that stuff. And it really shows and is kind of odd to me how that happens , but I've definitely ran into scenarios where I had people who've been in the industry much longer than I have.
Like I've only been, I think I'm gone on year six now as a software developer and there are people I've interacted with who have 10 plus years. I've definitely noticed that, they don't really have the best willingness to learn some of, like the newer languages or newer techniques or kind of take more novel solutions into account for different scenarios.
A lot of people will fall into a pattern of using the same old habits and patterns that they've been using and just kind of. Just stay doing that. And that is one way to go about it. Like obviously, you know, they're my superior still, even as a senior engineer, Right. And it like, it works out for their career.
Personally, I, the way I view software development, I don't think that's the way to go. Especially when you have a disconnect between like, people who are coming in and people have been there for a while. I have had to like translate newer things into older concepts but even the old people, or I shouldn't call them old people. People have been in the industry longer also struggle with the nomenclature that we kind of talked about before.
And they will, people will like reinvent the same patterns and give them different names over time. And then you kind of have to navigate that. But if you've been in the industry for a long enough time, a lot of people don't really care too much but I will say it is like we talked about earlier, it is harder for self-taught people to kind of bridge that nomenclature in the beginning until you kinda like figure it out.
Ryan: So it seems like you really have to keep up on what's. What's new, which now that I, now that it comes outta my mouth, that I'm like, it's software. No, duh,
Kent: Yeah. It's definitely industry unique.
You know like take like the constructing example you gave earlier, there's isn't as fast of a progression. A stud is still a stud building. Standards haven't changed a whole lot. Like we're talking, they changed maybe like every decade or more like couple decades.
Right. And so your terminology is gonna be pretty solid for a while. Software is definitely one of those weird ones where it progresses very quickly.
Ryan: How often are you finding that you have to like, do extra studying, I guess. So not only in your day to day job, but you're like, Oh crap, I really don't know this concept and then you're looking it up.
Kent: I don't really see that much anymore especially as the, this kind of like the more senior person on our team. I tend to just relay stuff that I know to the newer people on my team and that's usually where that comes from. However, like I do take it upon myself to learn new technologies. So like, the language rust hasn't been around for very long. It's fairly new. They're still working on it, but I've still been writing a bunch of it in my free time, even though my company doesn't use anything in that language and probably won't have a need for it. I still wanna see what's going on, what's the new hotness and just to stay current 'cause I did see kind of some interesting patterns that they're trying to, and some interesting patterns that Rust uses and like the problems that it's trying to solve. And it's very interesting to see what new stuff comes out to kind of solve certain problems.
And just by, even though it's probably not gonna be beneficial to my current position, that doesn't mean it won't help me later. So kind of what I do now, I don't really have to search for much. I mean like any developer, I do have a limited memory so I do kind of have to google things that I should know or I've already learned, just to kind of make sure my syntax is right.
So I'm like doing writing the code the right way but other than that, I don't really investigate a lot of new concepts cause I've learned most of them but that doesn't stop me at all from still searching things anyway, if that makes sense.
Ryan: Yeah, definitely. With learning new languages, you were talking about rust and not being around very long and learning it.
One of the things that I've read, listen, I'm not a coder, I have no idea how to do anything in software, but is it, how hard or easy is it to learn new languages? Is it one of the things I keep reading, like whether it's on Reddit or in different communities, is that like, once you learn one of them, it's pretty easy to learn multiple?
Is that true in your experience?
Kent: Yeah, actually. A lot of like programming concepts are very like relatable across it. You will come in, until you start getting to like a real deep level on how a language works, You don't really need to at the beginning know too much about the original language.
Like you will get a concept for your basic loop and then when you go to implement it, once you learn the syntax, you're like, Oh, I remember this. It's very relatable across things. There's very few languages that, where this is not the case but a lot of those is when you start going down into the very low level stuff when you're communicating with hardware directly, like with stuff like assembly language and um, even writing in just like binary stuff like that's completely different.
Ryan: Real quickly, would you be able to kind of define the lower languages and higher languages instead maybe not using examples since you already did, but rather like what you said, like lower languages is interface with hardware and then higher languages would do?
Kent: I can try.
Ryan: It's alright if you don't know.
Kent: On a technical side. I mean, I I know it's just hard to put it into more of a layman term, but I can try. Let's see. So like lower level languages, so like assembly language for example, you are specifically telling the computer to put data in certain places and what to do with that data and you're very limited on what you can do.
So, for example, math is very common, right? With computer science, and it's really important that, you know how math works on a simple and a more complex scale. When you get the lower, lower level stuff, when you get to the higher level stuff, you can write equations like you normally would as in like algebra, right?
But in lower level stuff, in order to say do like a multiplication or division, you actually have to, you only have addition and subtraction, right? So you kind of have to write, in lower level languages. You have to write multiplication as a series of additions. And then like divisions is also like a series of subtraction.
Ryan: Perfect. Thank you.
We've been focusing a lot on your past and how you got to where you are.
I kinda wanted to switch gears and kind of look at the future. So for software engineers, you already, we already kind of talked about it with the software architect. What is the kind of career progression, if you say, if you wanted to reach the heights of, you'll keep wanting to progress the ladder and you keep wanting to go up, what are the next steps?
Kent: So basically there's two kinds of roles, right? Or technically three. But in the beginning, when you become a developer, it's a lot of hands on stuff. A lot of times they'll call it like an entry level or just junior, or not even either those terms. They'll just call you a developer or whatever.
Then you kinda like start there. You'll progress to some kind of mid-level title. After a while, you kinda have some stuff but not necessarily all of the knowledge and then you end up as a senior where you're kind of expected to have a lot more knowledge and capacity for what you're doing and your like, workload and kinda like expectations, you know, change, right?
The more senior you are, they kind of expect you to be able to do things without too much input. As where like a junior probably needs at least some kind of point person to answer questions, to guide them when they need help, stuff like that. That's how it's supposed to work and then once you get to senior level there's kinda like three different patterns you can go.
Depending on the company size too. Some people don't go past senior, but some of the larger companies will do like a staff engineers, which is kind of like the next level and, or like a technical, technical lead of some kind. These roles kind of start to progress more into a little bit less of the actual hands on development and into more of a people management style.
So like a technical lead will lead your team as you progress forward through technical stuff. So what that means is kind of like, what we work on, how we do it, right, things like that. And they also serve as the point person to facilitate cross team communications as well.
As a staff engineer, you're more geared towards the actual contribution and not really so much the leading portion and then you can also go into just mostly people management. So like my position currently, I have a technical lead that I report to and a people management lead, or at least that's what I like to call him.
I think he's just called my manager or the engineering manager but I kind of split them and that's basically the career path there is you actually can like kind of stick more to the technical side or you end up splitting to the people side and then depending on which shoot you go, there's different directions.
So like on the technical side like we talked about before is where you get into your architects and those kind of people. On the people side you end up in like engineering management, VP of engineering, and you end up in like CTO or president of engineering or whatever those titles are.
But they tend to be more the people side. So once you get to like senior, it kind of splits a little bit. And then some companies that are larger will have an extra staff engineer, which also serves as a hands on building person as well but that's kind of usually how the course goes.
Ryan: That's interesting because I have a good friend who is a chemical engineer.
He's a process engineer for, anyway, but yeah, he's a process engineer and he explained this to me one day and he basically said the exact same thing that you did. And he said like, he's a senior process engineer and in manufacturing, and he said exactly what you said. Where there is, he can go and manage people or he can get like maybe one, one more jump up in the tech in like the technical role.
But he said, What he was saying was that in order to, I guess I'm not sure how it is in your industry, but in, in his industry, he said in order to make quite a bit more money as far as compensation goes, he said the way to go would be to the people route apparently and because he just into the, chief engineering officer or whatever.
Kent: Yeah. And unfortunately that's also how it is here too. The people managers end up, I think in higher salary brackets than like an architect and stuff. I will say though, like even as a software developer, some people just stay as senior engineer. Once they reach senior, they kind of just stay there and that's where they end up retiring.
Some people have no desire to go either route. They don't want all that extra responsibility or to lead a team. 'Cause even the like technical lead has a little bit of people management cuz you still have to like, divide up the work and make sure your entire team crosses the finish line with all the projects that we have.
Right. And so even though you're still in involved in a technical role, you still kind of have to deal with people like needing to take time off and people like being sick and then trying to manage the team going forward. Right. You're still partly doing people management, but you do have some technical like, Input into the product as well.
Ryan: For you now to get personal, like how are you planning on getting to software architect? Is there like a clear line? Are there like hoops that you have to jump through or is it just like if you get enough experience and the job opens up, you can just apply and then interview for it?
Kent: It kind of depends really. So there's two different paths to go and one is to like just apply externally to other companies to try to get that role and interview for that role like you would any other. A lot of times this would kind of, you know, as you guys have probably stayed on your channel, jumping from jobs to job is a lot better salary bump than saying, getting promoted internally.
Right. But that doesn't mean I can't use an internal promotion to as a jumping off point to kind of move externally as well. A lot of the job market likes you to already have experience in the job that you're deploying for. So it is really hard, like we talked about, breaking into the industry even as a younger person or a newer person to the industry, it is hard to break in because you don't have that experience yet.
It's even the same for the higher positions. They really want you to have like that leadership experience. They want you to have that title before, like going through the interview process in a lot of situations but I will say it's not nearly as bad. I definitely get a lot more interviews and conversations now as a senior than I ever did as trying to break into the industry.
A lot of times that was far more rejection, so it does get better. So I'll say there's a light at the end of the tunnel, but it is a long road and there's a lot of rejection. But yeah. I think I answered your question. I may have gone on a little bit of a tanget there.
Ryan: No, no, no. That was perfect.
That was perfect. Thank you.
Ryan: And I wanna be respectful of your time, so I'll start to wrap up here. I have a few more questions, for you and I guess going back to thinking about if somebody was 16, 18 or they're like you customer service role, they're trying to make a huge transition. I know that you answered, some of you answered this question in our questionnaire.
Like I said, I'll put that in the show notes for everybody. degreefree.co/podcast. You mentioned freeCodeCamp and I was wondering if there's are other resources. You also mentioned Udemy. There are resources or books or anything out there for people to kind of explore what it is to be or how to become a software engineer?
Kent: Yeah. I mean there's lots of stuff like we talked about before, it's really just getting on and just hitting up search engines and just poking around the internet until you figure it out. Like if you just go out and search for how to code, a lot of things will come up coding courses, I will say that you should absolutely give all the free resources a try first.
Unfortunately with the way things are with my industry, there's a lot of people out there who are just in, in the position to sell you a course and to not actually follow through with any sort of results For, unfortunately, it's little unethical in my opinion, but technically it's legal so just be careful of that kind of thing.
So definitely try the free resources first. Ask around the internet of paid resources that people like tried, if that's the way you wanna go. Personally I like Udemy it is a paid resource, but a lot of times you'll get deals where they're video courses. Like some of those are real good quality for how cheap they are.
It's like, I think the, like the video game course, I paid like $15, right? You know, one, five, $15 for, hours and hours of videos. Like, I think it was like at least 20 plus hours of video. And I built so many different random games using C# and like Unity and granted they did take the original and split it into a 2D game and a 3d, but even like the amount of content you get back for it, like Udemy are pretty good resources if you look for the deals.
They have deals for stuff on sale for like, Anywhere from $5 to $15 all the time. Definitely try the free or cheaper resources and, searching the internet can be really helpful, but you do end up in that like tutorial hell we talked about. I wouldn't necessarily say boot camps are the way to go.
They do work for some people. There are some legit boot camps out there. I will recognize that but there's also several out there who just want you to pay for their course and to move on and it's basically like an MLM or a pyramid scheme for them. I think in that respect. , cuz you'll get a lot of people who's like, Oh, I'm, an ex engineer at Google, or ex engineer at Facebook.
And then like, you know, those kind of people just definitely check into their background to see like how long they worked at those companies. I've seen at least an example of one or two who are like, Yeah, I'm an X engineer at Google, here's how you can get a job, blah, blah, blah. And you look into 'em and they were basically a software development for like two, three years.
They worked at Google for a few months and then dropped out and started selling these courses because like, you know, once they made the content, they can kind of just resell it to people and package it as a one size fits all. You know, unfortunately their business model and it works. But, I wouldn't say you get a whole lot of value out of it.
But there are some legit boot camps, that people have gone through and there's lots of Reddit sub-communities you can ask, be like, Hey, I'm trying to be a software engineer, here's this bootcamp I heard about. Is this any good? Definitely ask around. A lot of people have already looked into a lot of these things, you know what I mean?
If you're lazy and don't wanna search it, I totally understand. Like we all have limited time, you know, and you wanna make sure you get where you're going. And it's definitely ask around. People will tell you and they'll be, especially on like, um, like Reddit and even software development like Discords and other communities, they will let you know what's good and what's not.
Ryan: Yeah. I found that Reddit is a wealth of knowledge. It really is. And there's a couple of subres, even though I'm not a developer, but I'm, I like, just follow them. r/learnprogramming that's, seems to be a good one. And they have like a really big writeup for people that at the very beginning, at their wiki they have a really big writeup of like how to choose your first language and stuff like that.
I have no idea if it's good or not. Cause I have, I've never done it, but I've read the whole thing. But yeah, there's a bunch of resources out there and thanks. I think that you hit the nail on the head cuz I was trying to get after like, there's so many ways to learn nowadays from free resources to paid courses to boot camps and it's so difficult for anybody to really figure out how to start. And so that's good. At least there, at least that's a roadmap. You're start with the free resources. And Udemy as you said, is great. I've taken a bunch of Udemy courses and I've seen some that are like $90 and then I would just wait for the sale, like you said.
And it was like 20 bucks alright perfect.
Kent: Yeah and Udemy also has stuff that's like, not software development too. So, you know, anyone listening to this and it's like, Ah, I don't wanna be a software engineer. That's totally fine. They have lots of good resources even in any industry, right?
There's lots of good resources out there for most industries where you can kinda learn.
Ryan: Yeah. And last but not least, Kent, if people wanna say hi and. Follow what you're doing, follow along on your career, where can I send them to learn more about you?
Kent: Oh, man, that's a great question. I don't really have much of a social media presence.
I kind of just exist, I guess if you want to like, add me on LinkedIn. I'm on LinkedIn. I do have a GitHub. I go by, Kentleton that's, K E N T T L E T O N and then I usually use that for most platforms and stuff. I am on Twitter, but I don't tweet very much, so I won't give that one out.
But yeah, I guess those are the places.
Ryan: That's excellent. And I will have links to everything we talked about and those links on LinkedIn and GitHub in these show notes for everybody but Kent, thank you very much for making the time. We really appreciate you, doing this and helping up other people learn how to do this themselves and become a software engineer.
Kent: Yeah, .
Ryan: All right. Bye-bye. Thank you for listening to this weeks of the Degree Free podcast with my guest Kent Utterback. I hope that you guys got a lot of actionable advice out of this. As I said before, if you know somebody that's thinking about being a software engineer, Share this episode with them.
Kent went through everything that he went through to become a software engineer and how you can be one, two, and before you get outta here, I do have a couple of asks if you guys wanna support the podcast. The best way that you could do so is by leaving us a review wherever it is that you get your podcast.
That would be great. An honest review. 4, 5, 6 stars, whatever you can, that would be great. Next, if you guys wanna get in touch, please do [email protected] If you have any questions or if you are degree free and you have an interesting career and you just wanna say hi, definitely hit us up.
[email protected] and last but not least, if you'd like to keep up with everything, degree free, different degree free jobs, different companies that are down, credentialing and hiring degree free people. Sign up for our weekly newsletter. Go to degree free.co/newsletter to sign up. Until next time, guys
Kent: You can kind of just look at the job market and see what people are hiring for, and then go look at the technologies that people use to build those things. Then you can look at courses on like Udemy or even, there are a lot of community groups that do it.
You can kind of just look at the job market and see what people are hiring for, and then go look at the technologies that people use to build those things. Then you can look at courses on like Udemy or even, there are a lot of community groups that do it.
Our free weekly newsletter gives you everything you need to know to find work and get paid!