Becoming a DevOps Engineer With No Experience and No Degree With Logan Tran (S6E13)

This episode was transcribed with the help of an AI transcription tool. Please forgive any typos.

Laurence Bradford 0:08
Hi, and welcome to the Learn to Code With Me podcast. Thank you for listening. Today we're going to be learning about DevOps after this quick word from our sponsors.

Laurence Bradford 0:20
I just published a new website and I wanted a short, relevant insecure domain name for it. That's why I chose a dotTech domain. dotTech domains are perfect for all things tech, your portfolio, your passion project or your business. To get 90% off your dotTech domain, head on over to go.tech/learntocode.

Laurence Bradford 0:46
Data Science and Machine Learning are the two fastest growing careers in tech. If you want to become a well rounded data scientist, Flatiron School's online data science immersive can get you there. Start learning for free with their Data Science bootcamp prep course at flatironschool.com/learntocodewithme.

Laurence Bradford 1:09
Hey listeners. In today's episode I talk with Logan Tran. Logan is a completely self taught DevOps engineer. In fact, he never even went to college. After working in the music industry, he decided to switch into tech. Logan has previously worked at top tech companies like Apple than MT and others, both in person and as a remote employee. I've been following Logan on Instagram for a long time now, which has been my go to social media platform for some time. So I was really pleased when he agreed to come on the show. And our conversation we talked about what DevOps is how he got into the field, who might enjoy a career in DevOps, and the pros and cons of working remotely. I hope you enjoy this conversation with Logan as much as I did.

Laurence Bradford 2:00
Hey, Logan, thank you so much for coming on the show. I'm really excited to have you.

Logan Tran 2:04
Hey Laurence, yeah, I'm honored. Thanks for having me.

Laurence Bradford 2:06
Yeah. So I've been following you for a while now on Instagram. And I just love everything that you post and I love hearing about your story. So I'm so excited for guests to get to hear it as well and to get things started, can you tell us a bit about your background and how you got into technology?

Logan Tran 2:24
Yeah, absolutely. I'm honored to have my story. So I started in technology about five and a half years ago, and professionally so I actually dove into it when I came out of touring for music. So I got out of the music industry and I was traveling playing music for a bit and I wanted a little bit more of a stable lifestyle and a stable income. But since I wasn't traditionally trained through college, There was some ramp up that I had to do with sharpening up my skills in terms of what I knew for code. And when I knew in the world of like cloud infrastructures, so I dove into tech by getting a quality assurance job through apple. And as I was working through that QA job, I was just working on personal projects, and hacking different little apps. And I did that for about two and a half years, until I landed my first job as a software engineer, a junior software engineer, and then I kind of just took off with my career through there and ended up landing in the DevOps space later down the journey.

Laurence Bradford 3:49
Oh, awesome. I had no idea that you were in the music industry before. In fact, a lot of guests that we have had on the show that ended up transitioning And to check later in life have a music background. So I'm not a psychologist or anything like that or an expert on this area. But I have a feeling there's something between like being able to play and read music that ties into being able to program perhaps.

Logan Tran 4:14
Yeah, yeah, totally. I think there is a common thread between composition essentially. Right. So with music, you're you're compositionally writing something that sounds good. And I think with writing code, you're also composing in the same similar structured manner. It's just an application since it's not like audio based, but I think there are a lot of common threads between principles and methods between the two. So maybe that could be it.

Laurence Bradford 4:45
Yeah, yeah. I mean, that makes sense. I am terrible at music. But I always admire people who are able to read music, playing music and all that, but I would love to learn a little bit more about your QA job for Apple. So What did that entail?

Logan Tran 5:01
Yeah, so I was doing hardware and software testing for Apple. So anytime that new beta software would come out, I would test that software. I would also do QA testing on hardware components for repairs for iOS and Mac OS. So it was a lot of them rinse and repeat, work. To be honest, it wasn't the most exciting work or the most exciting job. But I went into that job knowing that I just wanted to get myself as close to software as I possibly could. And I wanted to surround myself with technologists who are passionate about technology and I just wanted to surround myself and indulge myself in a culture where it would inspire me to learn more and it would inspire me and encouraged me to push myself in my development. My personal development was my career. So yeah, it wasn't the most exciting job. It just had a lot to do with testing beta software before it was fully released. doing a lot of smoke tests as a user, or let's say like a new iOS feature would come out doing a lot of smoke testing for that said features and make sure that the user flow and the interface and things like that work, how it should. And then I did a lot of testing on hardware repair as well.

Logan Tran 6:24
So when an iPhone would go through, let's say, a quality assurance program, let's say there was like a display issue with I think it was like the iPhone seven. There was Apple did like a quality assurance program for their displays, because there was a known issue with that we did a lot of documentation and testing on the products that were affected by that. So that's kind of where it all started and a lot of my colleagues at the time or finishing school for software engineering, and they were all set Have them were pursuing that same track of what I was going for. So it was inspiring and encouraging to be working side by side with them knowing that they were chasing and pursuing his same common goal as I was. And it helped me to kind of make the most out of that season. working a job that I wasn't necessarily passionate about, but I knew it was a stepping stone to where I wanted to be.

Laurence Bradford 7:24
Yeah, I love that just knowing that it was a stepping stone to the next thing. So how did you, like land this job in the first place? Because you have this background in music, and I, you know, we didn't talk about this yet, but you didn't have a college degree either. So you weren't coming from computer science or something related? How are you able to get that that job?

Logan Tran 7:51
Yeah, that's a great question. And actually, my answer to that question, ties into how I got every other job afterwards and it all boils down to relationship So I actually got that job from a friend that I had made through the music industry. His name was Dorian Nolan. He was uh, one of my, one of the my friends that I would always see when I would be playing down in Florida. And he lives in Orlando. And so when I left the music industry and I was looking for a job, he was working for Apple doing that. And so I reached out to him seeing if there was any opportunity or any chance to be able to take on any kind of roll on his team or around his team and out of that friendship and out of that relationship with him, sprouted an opportunity for me to interview with Apple's team and the beautiful thing about Apple and why I really admire them as a company is that they don't just hire Based on competency, they actually look a lot at character and a lot of work ethic and just the way that you problem solve, even if it's not technology based. And they put a lot of value on there, they put a lot of value on employees who display traits of good problem solving, even if it's outside of technology, they put a lot of value on individuals who work well on a team and have good character and good integrity, and good communication skills, even if they don't have a background in technology, you know, etc, etc.

Logan Tran 9:37
And so, when I had the opportunity to interview with Apple, a lot of the questions and a lot of the things that were asked out of me, were just trying to identify how I problem solve in any kind of scenario and how I think and how I communicate. And then when it came to all the technical aspects of what the job actually entailed, they were things that I was able to get trained on and learn as I went through the job, which is actually the same common principle that ties into all technology jobs, I think like, there hasn't ever been a job that I have accepted or gotten into even as I've gotten significantly more advanced in technology and embedded systems like that. I've accepted a job where I knew everything like there was always a ramp up and there was always a learning curve to get through. And so yeah, I guess long lines going back to your question, I got that job with Apple out of relationship and out of a friendship and I think I just, it was perfect timing and perfect placement for me to grab the bull by the horns when the opportunity presented itself and I was lucky enough to have been considered by Apple and then hired by them.

Laurence Bradford 10:54
Awesome. And you're based in Chicago now was that position also in Chicago, are you living somewhere else at the time?

Logan Tran 11:03
Yeah. So I was living somewhere else at the time actually moved to Florida for that. And then I'm originally from Chicago. So I came back to Chicago in 2015. I lived in Orlando for like three and a half years.

Laurence Bradford 11:17
Got it. Okay, so you were I was in Florida, and now you're in Chicago. Makes sense. And you now of course, are more recently are in DevOps. How, how did you become introduced to that? How did you become interested in it? And also, if you don't mind, could you just give a quick description of what that is to the to the listeners?

Logan Tran 11:35
Yeah. So DevOps is, what DevOps is, is different interpretation depending on what company you work for, and how they interpret what DevOps is, but essentially, it's a culture in software engineering and software companies where you bridge the gap between operations and development. And you use software to do that you build something Were to bridge the gap between operations in the software development space. So it's kind of like having one foot in operations in the business side of things. And then one foot in software development in the software side of things. My journey into DevOps is pretty interesting as well. I actually didn't plan on going into DevOps or like Site Reliability Engineering, but I ended up I guess, falling into it and then falling in love with it that I stayed with it. So after the job at Apple, I had mentioned earlier that some of my colleagues were going to school for software engineering and pursuing the same track right and goes to the same goal. One of my friends that I worked with one of my old colleagues that Apple ended up getting a job at Braintree Are you familiar with what Braintree is?

Laurence Bradford 12:54
I.. It's like payment processing?

Logan Tran 12:56
Yeah, so Braintree is a PayPal company and they're essentially payment gateway. They power a lot of payments for ecommerce applications and mobile apps like Uber and Airbnb and grub hub and a bunch of others. So one of my old colleagues at Apple ended up getting a job at Braintree. And after, after him working at Braintree for like five or six months, there was an opening on one of Britain's sris teams that he referred me to. And I interviewed for that position. And I ended up getting a junior developer role at Braintree specifically on the Venmo team. Are you familiar with Venmo?

Laurence Bradford 13:37
Oh, yes, of course. I'm sure a lot of listeners are too. Yeah.

Logan Tran 13:41
Yep. So I ended up getting a role with them. And again, that opportunity was also birthed out of relationship. Because I wouldn't have gotten that that interview I wouldn't have even got an extended the opportunity interview with Braintree for Venmo if it Weren't for that relationship and that friendship that I had with my colleagues. So I ended up landing the job there at Venmo. I was doing, I guess now in hindsight, when I look back at it relatively simple work, relatively simple development work, but really helped me get my footing in and really understand how Software Development and Engineering plays in a production space. Know that Venmo for about a year and a half. And as I was working on that team, and I was collaborating with the other product teams at Braintree, I started to gain interest in the DevOps space specifically with the tooling and the technologies that the DevOps team at Braintree was creating. They were creating a lot of different micro services that automated the development lifecycle for the production teams, for the product teams at Braintree and it really intrigued me with how the systems and the services that those teams were building and writing or really empowering the organization to move forward and build quickly and iterate fast.

Logan Tran 15:13
And that's when my interest in DevOps really sparked. And so afterhaving worked at Venmo, for a little over a year, like a year and a half, I started to look around loosely at some other opportunities in Chicago, that were more catered towards the DevOps space, because I wanted to transition my path into DevOps, and DevOps. I think over the last couple years has really ramped up but when I was gaining interest in it, it wasn't a field or a role or a position that was quite desired yet or that there were a lot of companies that were really putting a strict focus and an emphasis on the DevOps culture. So it was really hard for me to find a DevOps role that for a junior Dev, right, like I was, I was pretty young in my career at that time. And I stumbled upon another company, it was a digital mortgage company, who was starting to build out a DevOps team and automate the development lifecycle through DevOps principles. And so I interviewed for that team. And luckily, I got the position and it was the first I was the first engineer to be on that team. And so that's kind of where my DevOps like, career started and where I got my first footing in DevOps, and I worked for them. Digital mortgage company for about a year and a half before I moved on to the company after that.

Laurence Bradford 17:06
Wow. So changing gears just a little bit here were all of these positions remote for the most part. I know the one in Florida wasn't but were you going to an office every day? How did some of these things look?

Logan Tran 17:21
Yeah, so at Braintree I went to the office four days a week, we did get to work remotely one day a week. So there was somewhat flexibility with remote culture. And then at the digital mortgage company that I worked that afterwards, I was remote three days a week. I went to the office on Mondays and Wednesdays and then my job after the digital mortgage company, along with my current role now are full remote

Laurence Bradford 17:50
And a lot of people listening. I know that's like their dream is to be fully remote. I mean for a lot of people outside of tech in tech everyone right? It's like Greg's you have so much flexibility over your working schedule. But I'm sure it comes with challenges like, especially as someone who was maybe more junior when you were starting off in some of these partially remote roles. What how, like, how have you been able to manage your day working remotely?

Logan Tran 18:18
Yeah, absolutely. So I think, yeah, you're right. It's a remote culture in the remote Park is something that a lot of people crave to have. But it certainly does come with its downsides and its challenges. And I think one of the biggest challenges of remote work is the barrier of communication with your team or the teams that are dependent on the work that you're doing. You have to be a lot more diligent in your communication and almost over communicate everything that you're doing and everything that all the problems and the roadblocks you're running into in order to keep a consistent workflow. working remotely. And another big, big challenge of working remotely is really having the discipline of knowing what your boundaries are as an employee and as a worker and knowing that everyone, everyone has their own distractions, and everyone has their own boundaries, so to speak, when it comes to environments that cultivate a productive workflow for them, or not a non productive workflow, and I think one of the big challenges of working remotely is drawing those lines and drawing those boundaries with where you allow yourself to work when you allow yourself to work and how you navigate your work environment and your workspace so that you're still producing high business value with the, you know, massive amount of freedom that you have with not having to report to an office or not having to see people face to face or being able to work from a rooftop or Europe. apartment or on vacation somewhere, you know, wherever. And I think it's one of the biggest challenges is really having the discipline of drawing those boundaries and knowing what kind of environments you've produced the most value in.

Laurence Bradford 20:15
Sit tight podcast listeners, we're taking a quick break to hear a word from our sponsors.

Laurence Bradford 20:21
My team and I have just published a brand new ebook called 28 Ways to Earn A Side Income While learning how to code for this resource. We wanted to pick the domain name that was short, relevant, and most importantly secure. We decided to go for a dotTech domain, sidegig.tech. We believe dotTech domains are perfect for all things tech. We found out some really big names also use dotTech domains, including the Consumer Electronics Show at CES.tech. Intel's Internet of Things portal at insight.tech and even tech thought leaders like Like Austin Evans, whether it's for your passion project, your startup or your portfolio, I recommend securing your dotTech domain ASAP. Learn to Code With Me listeners can get a limited time 90% discount on one and five year domains. Just head on over to go.tech/learntocode and use the coupon code Learn to Code. I'd love to hear which domain you go for. Tweet me at Learn Code With Me to let me know.

Laurence Bradford 21:30
How would you like to launch your career and what Harvard Business School calls the sexiest job of the 21st century? Data scientists and machine learning engineer jobs are the two fastest growing careers in all of tech. Since 2012, there's been a whopping 650% growth in data science jobs alone. Flatiron School's online data science immersive teaches a tried and true data science curriculum designed to make sure you graduate as a well rounded data scientists If you're looking to change careers, what better way than by learning from top instructors using real world tools, and working with your very own career coach to get the job search skills you need to land the job. You can even take this course alongside your current work commitments, full time, part time, or self paced. The choice is yours. Since 2012, Flatiron School has helped more than 3000 students watch new careers in tech, become one of them by taking their free data science bootcamp prep course, just go to flatironschool.com/learntocodewithme.

Laurence Bradford 22:43
Yeah, that makes a ton of sense. So getting back into the DevOps more specifically. Now, you mentioned another term when you were speaking earlier Site Reliability Engineering. What is the difference between those two things?

Logan Tran 22:58
Yeah, that's a great question. I get asked that a lot. So, DevOps, it, like I mentioned earlier is more of a culture. And it's a culture of automating in bridging the gap between operations teams, and software teams and development teams inside of an organization. But since that since DevOps is a culture, every organization's interpretation of what DevOps is, is very different. So for example, as I would be interviewing for other companies, that the role the title of the job that I would be interviewing for is DevOps engineer, but the interpretation and the job functions of a DevOps engineer for Company A, and then the responsibilities of a DevOps engineer for Company B could be very different, depending on the interpretation of company and company B's perspective on what DevOps is and how DevOps ought to be applied within the organization. Site Reliability Engineering is actually a term and a title or a role that Google came up with. And essentially, it's a quote by Google, one of the engineers at Google. Fundamentally, it's what happens when you ask a software engineer to design an operations function. And Site Reliability Engineering, in whole, I guess, is a more succinct way to describe DevOps, when you build engineering principles, through applications to solve operations problems.

Logan Tran 24:41
So DevOps in some companies will actually not entail any kind of software development whatsoever. A lot of like some companies interpret DevOps as an operations task. So a DevOps engineer might actually just be clicking around a console on like AWS. Making sure that instances and networks are running healthy, doing health checks on the different components of their architecture and their application. But they don't actually build any applications in order to do any of those tasks in any of those jobs for them. Site Reliability Engineering is creating and building applications to do those tasks. So typically, a site reliability engineer is someone that does operations jobs, but uses software engineering skills to fix those problems. And they typically come from a software engineering background, where some companies and some DevOps engineers, they don't actually have any engineering background or skills whatsoever, so they don't actually apply engineering principles and solutions to the problems that they they fix. It's more operations driven. Site Reliability Engineering focuses on solving problems through software. Solving operations problems through software and building tools to do that.

Laurence Bradford 26:03
Gotcha. So you don't have to go super in depth on this. But I'm wondering, are there any other job titles then that are in this DevOps sphere that, that you haven't talked about yet? So you mentioned right, the Site Reliability Engineering, and you just you also mentioned like a DevOps engineer. Is there anything else then?

Logan Tran 26:23
Yeah, so those two titles are those two roles are typically the most common that's used in the space. But typically, those teams could be comprised of network engineers. They could also be comprised of sis admins or system engineers. So again, it really depends on the company's interpretation of what that job entails and in what their needs are, but they're usually pretty diverse teams. When you look at a software engineering team, a prod normal product team. Everyone comes from a computer science background. Then they all just write code. DevOps in the DevOps space in the SRV space. The teams will be comprised of people that might have a strong focus on networking, or a strong focus on system administration or a strong focus on operations, or some focus on software development. And it might be a mix of all of those things.

Laurence Bradford 27:25
Gotcha. So, what, and I know you mentioned a few times that DevOps is more of a culture, it can really vary from company to company, what the role looks like, and their interpretation of it. But so a lot of people listening this show are new to tech, and most are pursuing web development or software engineering. What kind of person that could be a good fit for a DevOps related role?

Logan Tran 27:51
Yeah, so there's probably two main buckets of people I think that fit DevOps really Well, one bucket would be an individual who is very business minded, but has engineering skills. So one of the the reason I say that one of the responsibilities and focuses as a DevOps engineer and SRS to make sure that on the technology side of things, the technology and the infrastructure and the tool sets that the company is using, whether that be internal or their customer facing application, is beneficial to the company for scale and is actually cost effective and cost efficient. So a lot of focuses on a lot of your focus as a DevOps engineer would be making sure that your costs your tech debt is low with your infrastructure, and that you're the application in the stack that it's sitting on top of is built and maintained in a way That is most cost effective, effective and most scalable so that the company can move forward quickly. And that the product developers can just focus on writing new features.

Logan Tran 29:10
So the reason I say I think an individual who is business minded but is also good with engineering and technology is because you have to have a business focus inside a DevOps space and then sorry, space, because your sole responsibility is making sure that the business stays alive and stays healthy, on the business and operations side of things. So that's one bucket of an individual that I think fits the DevOps space well. And the other side of it that I think individuals fit really well into are people who come from a systems administration, or networking background, but want to dive deeper into building their own systems and their own tool sets. So a lot of DevOps responsibilities also ties into building and maintaining networks and system administration for the computers within a organization or one of like one of the organizations that I was affiliated with manage different kiosks around the cities. So having, you know, experience in in managing different hardware components like works really well as well. So I think those are the two in my perspective, those are two main buckets of people that fit the job really well.

Laurence Bradford 30:38
Got it. And on the podcast before we've talked a lot in past episodes about technical interviewing, and different things related to that, mostly focused though on software engineering jobs and like strategies and tips for excelling in that interview. How is a DevOps interview different than a software Engineering one, or is it kind of similar?

Logan Tran 31:03
It's similar in the sense that code is still very heavily involved. So you will get asked you different, like algorithm questions and efficiency questions on how to run the system. But I think it differs in the way that when you interview for a product team of software engineer position, are typically focused that the interview is typically catered and focused towards you building a feature or building some kind of app, the highlight the way that you think about how the application works as a service or as a product for the company, right? In the DevOps space, you're targeted by. They target a lot of questions and a lot of the interview around how would you deploy an application? How would you, how would you set up and build a system that enables the developers to release quickly and to iterate fast over their changes. How would you monitor application logs and application performance? And if problems go wrong? How would you if problems with the application go wrong? How would you create an automated system in order to solve that problem? And in order to keep your SLA is high for an application, so a lot of the questions on the DevOps side of things outside of the software engineering side of things are focused a lot on the deployment side of the application. And then how do you keep it healthy once it's running in a production environment?

Laurence Bradford 32:38
Awesome. And I would love if you could also just briefly talk about some of the technologies that you use in your DevOps work. You don't have to go in a ton of detail on every single one, but just the listeners can get a sense of like what you're working with.

Logan Tran 32:52
Yeah, totally. So it's I'm -- I am very heavily involved in the AWS product line. So everything every company that I've worked for is all cloud native. And so a lot of AWS technologies I code in go, are goaling. So it's a for those that aren't familiar with go Lang. It's a language that Google developed a five or six years ago to replace Python. Um, I use Kubernetes a lot, which is a container orchestration tool. And I use Docker a lot, which containerize as the applications and services that I write.

Laurence Bradford 33:34
Awesome. And so this is kind of so much I just asked, but are there any new technologies that you started working with that or things that are just kind of, maybe they're not even totally created yet, just receive a feature going that you're excited about?

Logan Tran 33:50
Yeah, I'm really passionate about Kubernetes. I talk about Kubernetes a lot through my social platforms, and I use it very heavily. In my current role, along with my last two roles that I've had in Kubernetes, in the DevOps space, has really, really gotten a lot of attention and a lot of traction over the last year or two. It's also a technology that Google started and then they ended up open sourcing it and giving it to cn CF. So it is now an open source project, but it was actually started by Google. So yeah, Kubernetes is something that I'm really passionate about.

Laurence Bradford 34:29
Awesome. And just to kind of wrap things up. One of the things I'm just so impressed about you is how you're totally self taught, you've moved into tech, you know, on your own. You also have all these other talents that I see like through your Instagram, like you seem to be great at design and like digital editing and all these different things. I just wanted to hear what advice you have for people listening about teaching yourself technical skills, without a You know, proper college degree?

Logan Tran 35:02
Yeah, that's a great question. I actually, I get asked that a lot through my social platforms. I think there isn't a one way one correct way to do anything. I think there are multiple ways to get to any destination that you want to get to in life. And I think it all boils down to you knowing yourself the most and knowing what works for you. So for me, the reason that I went down the self taught road was because I never really excelled in a traditional, like classroom environment. And I've always been a strong self learner. So because I knew that about myself, I was able to take on the you know, the self taught road and have the motivation and the drive to teach myself in to push myself to learn it so it worked really well for me. But I don't give the advice of to everyone, I don't give a single solution advice.

Logan Tran 36:06
Everyone have, Oh, do the self taught route, do the, you know, just teach yourself you don't need college because there are some of my colleagues and there are some of my friends who aren't good at self learning and self leading, and they excel better in a traditional environment. So I think in terms of like the best way or the best route for someone to learn, I think it all starts with a question in what environment do you learn best? And if the if you learn best by being hands on and teaching yourself and you're good at researching things on your own and asking the right questions on your own, and then seeking out those questions on your own, then by all means, self taught route is the way to go. But if you're the kind that excels better when someone sits in front of you, and you have a structured learning path and you excel well In a classroom environment with classmates and the teacher to ask you as questions to back and forth, and by all means the traditional routes the way to go. There's that kind of answer your question.

Laurence Bradford 37:11
Yes, yes, definitely. And just kind of piggybacking off that, I assume you're still teaching yourself things all the time. What like do you turn to like, are you? Do you just research the problem that you have online and figure out the solution? Or do you actually go through like books or courses to learn a certain topic in depth?

Logan Tran 37:32
Yeah, great question. I do a little bit of both. So everything that I learned, currently, I learned out of the having to learn it. So I'll run into a problem or I'll be I'll be building something or working on something and I run into something that I don't know. And so therefore, it causes me to have to go research it and look it up. I always say that Google is my best friend. And actually, when I get asked online, where Where they should start, I always tend to jokingly respond Google, but it's actually like, I actually use Google every day. So the Yeah, that's kind of that's kind of like my route of things of how I teach myself, and how I learned.

Logan Tran 38:19
But I also do buy books and learn through books. But more so when it comes to a specific topic that I'm completely unfamiliar with. So, for example, when I started with Kubernetes, a couple years ago, I picked up a book on Kubernetes. It's called Kubernetes. up and running. And I started with that before I started researching things online and looking things up online. So I think it really does like for me It depends on the topic at hand and how much I want to learn about it is it's a bigger topic that requires a lot of research. I'll typically start with a book and then Google things online. If it's a smaller problem and you know something that doesn't require too much detail, I'll start with the internet.

Laurence Bradford 39:08
Awesome. Thank you so much, Logan, again for coming on the show. Where can people find you online?

Logan Tran 39:13
Yeah, so I have a bunch of different social networks. But you can find all of them through links to all of them through my websites, loganmartintran.dev and my site there will link to all of my different platforms.

Laurence Bradford 39:29
Awesome. Thank you again for coming on.

Logan Tran 39:31
Nowm Laurence. Thank you so much for having me.

Laurence Bradford 39:39
Thanks so much for listening today. If you want a reminder of anything that was covered in the episode, just head on over to learntocodewith.me/podcast. You can see all previously published episodes there. And if you enjoy Learn to Code With Me podcast, please consider becoming a patron of the show. By pledging just a few dollars per month. You'll get out access to a bunch of patron only bonuses and privileges, like the ability to vote on the topics of future episodes. To find out more, go to learntocodewith.me/pledge. Thanks and I'll see you next time.