Develop Yourself
To change careers and land your first job as a Software Engineer, you need more than just great software development skills - you need to develop yourself.
Welcome to the podcast that helps you develop your skills, your habits, your network and more, all in hopes of becoming a thriving Software Engineer.
Develop Yourself
#236 - Developer Internships: The Good, The Bad, and The “Wait, They Threw Out My Code?”
Send a text and I may answer it on next episode (I cannot reply from this service 😢)
What’s it really like to go from coding alone to working on a real dev team?
Dean Fox shares his raw experience navigating TypeScript, Git, team dynamics, and scrapped code during his first internship through Parsity's Inner Circle program.
👤 Connect with Dean: Dean Fox on LinkedIn
Shameless Plugs
🧠 (NEW) Parsity's The Inner Circle Program - a highly customized roadmap to take you from 0 to hired. For career changers who want to pivot into software.
💼 Zubin's LinkedIn (ex-lawyer, former Google, Brian-look-a-like)
👂🏻Easier Said Than Done Podcast
Already a developer? Check out 👉 Not Another Course
Serious about joining Parsity? Schedule a call with me ☎️
Welcome to the Develop Yourself podcast, where we teach you everything you need to land your first job as a software developer by learning to develop yourself, your skills, your network and more. I'm Brian, your host. In this episode I speak with Dean, a current mentee in the Parsity Inner Circle program, about the good, the bad and the ugly of internships. Now at Parsity, we've been experimenting with internships. We've been doing so for the last year and a half of internships. Now at Parsity, we've been experimenting with internships. We've been doing so for the last year and a half or more and they've been really great as far as moving the needle with getting people the experience they need to make them sound like less of a risk in the market by teaching them the skills that they'll actually need on the job. They're also really demanding and, while they can turn into actual offers or give people the experience, that's great, to put down on paper, they are not easy.
Speaker 1:I asked Dean about his experience in this particular internship, which was very intense, using a modern tech stack, and what he really thought about it and what you can probably learn from this, too, if you're considering going down that path. So, whether you're considering joining something like Parsity or just doing an internship on your own. I think you're going to find a lot of value in this episode. I hope you enjoy it and, without further ado, let's get right to it. Today on the Develop Yourself podcast, I have Dean, who's a current mentee in Parsity's inner circle. Can you just briefly tell us a little bit about you? Know what led you into coding?
Speaker 2:I'm originally from South Africa and I moved here in 2019 to get married and I was in the IT field back in South Africa and I just got completely burnt out on the field. So I got into a cabinet building company and then we moved to Knoxville, tennessee, and I ended up at a framing shop building picture frames. And one day I woke up and I thought, like is this my career? Like, is this, is this what I want to do? Is this what I want to do when I have a family and kids and my wife wants to stay home? And like no, like what am I going to do in five years? Like, am I just going to be incrementally earning an extra? Like 50 cents a year or whatever? Like yeah. So then I thought, like I could get back into it. But man, I really just don't want to do that and I've always kind of avoided coding thinking it's like I mentioned this um to zoom in.
Speaker 2:I always thought it was kind of for the clever people in it and then the not so clever people were doing like support, you know, fixing printers and stuff. Like you know, his analogy is like if you get in the car and in new york and you want to go to la, you, you still got to go west, like if you go east you're not going to get there, no matter how fast I was getting on a plane, then the plane wasn't landing where I needed to be. And then I was getting on a plane, then the plane wasn't landing where I needed to be. And then I was getting on a train and like, yeah, so I just decided.
Speaker 2:And my initial reaction and I think a lot of people is, when it, when you guys say you know it's going to be a year, like sometimes at least you know the initial reaction is, oh, I don't want to wait a year in my job. I hate my job. But then I thought back like the first time I started a coding tutorial was two and a half years ago. How different could my life be right now if I just committed? I was like you know, what a year is nothing.
Speaker 2:Let's do it very cool.
Speaker 1:I I'm. A lot of what you're saying resonates with me. I was thinking the same thing. I kind of cleaned up my life before I learned to code and then I was on code academy and I'm like thinking cool, and I'm thinking also in the back of my head if I stay in this job I'm currently at you know it was a nice, safe job with a union or whatever and a school, and I'll get like this tiny little raise every year. I'll never really get what I want. And also I wasn't happy.
Speaker 1:I like coding. I assume you do too, and I've actually reviewed some of your code and I got to tell you it's really good, like. And I got to tell you it's really good, like. I review a lot of code and I'm reviewing a lot of the code on this project and I'm impressed. You came from a very non-traditional background, like everybody that I've talked to on this show, basically, but you're doing a hell of a job. It's pretty amazing, thanks. But I also know that this internship has been pretty difficult. Can you briefly tell us a little bit about what you're working on?
Speaker 2:it's uh, I've been leveraging some llm, some llm work and trying to integrate that with what I'm doing never copy pasting stuff.
Speaker 1:I don't understand golden rule oh, that's right, there you go, yeah it's.
Speaker 2:It's been a good challenge, um, and I'm glad I learned it in an internship and not, you know, in something that's like really high stakes or something that would have like hurt me a lot more, you know.
Speaker 1:So I'm glad I went through that. That's awesome and I know that you know you're being very diplomatic, but most software engineers, especially those of us that have worked for a while we've written lots of code or little bits of code, but sometimes a lot and then you find that you've done all this work and it gets thrown out the door pretty unceremoniously. Usually it's not uncommon. I've worked on teams, big and small, where you do like, maybe a large project, like hey, we want you to integrate this thing. You know the marketing team wants you to integrate something. And then you do it and you struggle with it. You're like, ah, it's finally ready.
Speaker 1:And then you hear you know what, something else that basically happened to you on this team and I'm sure that was probably surprising to you, right? You're thinking like what the hell? I spent all this time working on this thing and now you don't even want it. This is a really small startup, by the way. But yeah, it's not a great feeling, right, to feel like, hey, I've done all this work now but you reframe this a bit. I know it's not easy. We all get attached to the code, right, but if somebody that didn't code or worked on a team, they heard that they'd be like well, what was the point of that, like, how do you kind of reconcile that in your mind and think about the benefit that it provided you, even though it's not going to ultimately go out to the public?
Speaker 2:I mean I'm in a unique position where I'm learning and I mean I know that'll always be the case. It's not that I'm going to learn now and then I'm not going to learn, you know, I'm just going to know things. But having gone through that, doing all the problem solving, doing all the debugging and all that stuff I mean there's just no way that's a waste. Like, just because it's not on a website somewhere, it doesn't mean it was a waste. It doesn't mean that, like I didn't learn stuff, I didn't struggle through things that I'm not going to struggle through next time. Like I learned a lot and I learned a lot about what not to do as well.
Speaker 2:I learned a lot about what questions I should have asked. Instead of just maybe not assuming that, like giving myself a little bit of credit, it was a fair assumption. It wasn't that I just like didn't want to ask questions. It's just I didn't know exactly what questions to ask. I just like didn't want to ask questions. It's just I didn't know exactly what questions to ask and I think that's that was a lesson that I learned from.
Speaker 2:That was, um, okay, even if you get this, this stuff that you think is is your target, clarify some things. You know, is this exactly what you want or is this a guideline? You know, and, um, just just little things like that. I mean, especially where I I'm at learning like I can't get enough reps in, so just doing all that was like I mean, it was different a week ago. I was a little more like this, but, um, yeah, having sat with it and and really thought about it like I'm, I'm still stoked, I did it, I'm, I don't think it was a waste of my time. Like the code might yet technically be a waste of my time. Like the code might yet technically be a waste as in not being used, but for sure it wasn't a waste for me.
Speaker 1:Yeah, like we write code all the time, like think about like the code you write might write for the inner circle. Like the projects you're doing, that will probably never see the daylight right Like the light, but they're incredibly important because you learn a ton on them. And I think you hit on a really important topic too, like communication. Often what happens on teams and everybody's seen this as well, that's worked in software for a bit you have different expectations. Somebody hands you something or they say something and you think you kind of have an idea in your head of what should be built and then somebody else has an idea in their head of what should be built and then at some point there's a mismatch. That occurs when you're like here I got this thing and they're like expecting a dog house and you built like a doll house. You know type of scenario.
Speaker 2:But you both think you understand each other.
Speaker 1:Yes.
Speaker 2:It's almost like you don't think to ask the questions because you think you understand it Exactly.
Speaker 1:What was like one of the biggest things that was surprising to you going from, you know, doing all this work in inner circle and more on your own in a solo setting, to working on a team.
Speaker 2:I don't know if this is surprising, more than it was a bigger challenge than I thought. So, yeah, maybe I was surprised by the difference. In this way, a lot of the stuff we're doing in our learning process is from scratch. So I'm creating the app, I'm building the pages, I'm linking everything up and now getting like, here's the code, add to it, use the connections we've made and all that stuff, and I knew that that was going to be the job. I knew I wasn't going to be creating. You know, create next app from scratch and do all this stuff the way I want to do it, and it's too neat and tidy as I want to do it.
Speaker 2:But you can't know how different that is until you do it. So, getting a code base and then saying like, okay, use what we have and make it work, and then it's like well, can I change the file structure or do I have to use this file structure? Like, can I add some utilities in this workplace or do I need to put it? You know, just that kind of stuff. Um was a lot more different than I expected, and maybe that's being a little naive, but to my credit, I don't know, it's my first time, of course. Yeah, that was really great to experience in this context as well.
Speaker 1:That's cool to hear and that's, yeah, a lot of the questions that I heard from you and other people in there were things that I often take for granted or just kind of become second nature to me. I'm like, oh yeah.
Speaker 1:And things that I often take for granted or just kind of become second nature to me. I'm like, oh yeah, and I'm like, well, how do I know that? I don't know that just because I woke up and know it. I know that after writing tons of code for tons of different applications and on different teams and things like that, what were some things about working with a team that you found either more difficult or more enjoyable than working solo?
Speaker 2:So there's definitely both for me More difficult. I've realized I do not want a remote job as much as possible. It's been really difficult and the extra challenge for me is that it's all after hours for me, Like I have a day job.
Speaker 2:So I'm down and working when everyone else is kind of in their downtime. So that's been a little challenging getting replies during the workday and replying at night and then getting replies during the next workday, and you know that's just a logistical challenge that I won't have in the future, even working remotely. You know we'll all be in the same working at the same time and that kind of stuff. But for this thing that's been a bit of a challenge.
Speaker 1:So just there's some logistic stuff around. Working remotely I mean a lot of questions I had.
Speaker 2:If I could have just turned around and, hey, what's this thing? Okay, and just carry on working. Yeah, I mean, that's invaluable, especially for me coming in so green, like oh yeah, to just ask those questions and get a response immediately and it's not actually stopping my flow, um is like invaluable. And yes, I understand if I do work remotely, that'll be easier when we're both on the same schedule, but that's been probably the hardest thing is just aligning work times and dealing with that discrepancy. Yes, on the flip side of that, the plus sides of working in the team is there's been a couple of guys who I've really enjoyed bouncing stuff off and just talking through and like we'll hop on like once a week and just talk about either vent on the frustrations we share or like, um, I'll vent on something and he'll go, oh, oh, I'm. I actually looked at that up and here's a quick response.
Speaker 2:I'm like man I just overlooked that. That's great, and vice versa, being able to just bounce ideas off someone, um, has been really cool, whereas when it's just me and and I, uh, maybe it's like you don't get that same bounce, you don't get that same relationship.
Speaker 2:And it's been really cool doing that with someone because all my um inner circle stuff has been just me, you know, and and I mean you guys with feedback and stuff, but on the day-to-day, like I'm just, I'm writing the code, it's just me, and yeah, exactly that's been really cool, it's it's.
Speaker 1:It's hard to mimic that experience. Like there's really nothing like the experience of being in just a really like messy situation, honestly, which is kind of what we all get into on that first day. Work like this is about as close to what you'll experience on a Thursday work obviously much more intense because you're trying to juggle your job and this at the same time which is pretty amazing and dealing with all these new tools. It's interesting, though, that from the challenges you've been talking about, none of them seem to have to do with code. It seems mostly around like the processes and like the norms and the work culture. But I'm curious was there any like code related stuff where you're like, oh wow, this code is so different? For example, like when you looked at this code base, which is moderately complex and pretty big it's bigger than most code bases you've probably worked on so far so was there anything you looked and say, wow, this is like completely foreign to me.
Speaker 2:I will say being able to ask like chat, gbt about type stuff has been very helpful because it can be a rabbit hole, um, especially when you use a type across a whole bunch of different components and then you start getting you change one thing and then you get a whole bunch of red things, everything breaks, yeah, yeah, everything just goes red and you've got to trace, like where you use that thing. Yeah, so, but I do like I like typescript once you get going with it.
Speaker 2:I really like it yeah, I'm really enjoying that safety of it. Um, but it's, it's definitely a challenge. It's like if someone a friend of mine described it to me once. He said like because he was, he's a ruby guy and he was learning javascript. He said, man, it's just so much typing. And then I looked at typescript and it was like the guy who made javascript was like let's just add more topping to it, let's add more types, like yeah, but I mean like one or two lines, much, yeah, exactly more lines, like more characters for like the same function.
Speaker 1:Yeah, totally exactly.
Speaker 2:But it saves you in the back end. Um, with debugging, not back end, isn't coding back end, but I mean on the on the back side of it, where it's like you're not debugging as much so I am really enjoying it I'll be honest with you.
Speaker 1:I I hated typescript for a long time and I got I got forced to use it, basically in a, in a similar type of application that you're building for work at a startup that I was working at recently and, um, I had to be used typescript and this, this place had TypeScript. People that, like, really knew TypeScript. I thought I knew TypeScript, but then I was going, I was having the same issues you're having and I think it's really cool that you're getting to experience that a little bit earlier and I'm glad to hear you're enjoying it, because it took me months before I was like I don't. I was like was like I don't want to do it. Why can't we just do this in JavaScript? Be so much faster. But I see what you're saying, because you change your type one place and it breaks across multiple files, so you immediately get that feedback that hey, something's wrong and if you had that in JavaScript you wouldn't. You'd probably find out later.
Speaker 2:Oh yeah, there's something. I broke way down the line. There's a problem here, and then you. It's just like endlessly chasing exactly exactly.
Speaker 1:That's a really cool observation or that's a cool like epiphany though. You did a tutorial like that, it was nextjs. The cool thing about nextjs or like react, is it's not that different, right like you can only write a component or have a use effect or use state like in a few different ways. It's not like completely a black box of things. Lastly, on the technical side, how did you feel using git?
Speaker 2:this is like generally the area where people have the most trouble I did it the right way and it's been so nice and smooth. Um, I'm still, you know, learning the, the pull, requests and stuff and how to manage that and manage not only just submitting it but dealing with the, the comments coming back and all that stuff um, so I'm still learning but uh, it's, it's been cool. Um, as again, it's nice to learn on a. Um, I'm not saying there's no stakes, but it's like um yeah, it's lower stakes, for sure.
Speaker 2:Yeah it's an internship you know, we're here to learn like yeah, yeah I mean not saying their code's not important, but I'm saying like um, yeah, I mean I think you get what I'm saying. It's not like this is my job and like, um yeah, the stakes are just different. I wouldn't say they're lower, they're just kind of different yeah, yeah, totally.
Speaker 1:I mean yeah, it's like it's you're providing a service for free and they're like saying, hey, like we're going to teach you and be more patient than if we were, you know, paying you and we expect that, hey, this has to be done by X, y, z date, even though, if I'm being honest, there's a little bit of pressure obviously in every internship to to ship code at a certain point. Um, I know a lot of people that are listening to this, especially if they're earlier in their career and they're probably like scared. Or if you've started a new job, I know you're feeling this. You look in a code base. There's actually some people in parsing that got hired recently and they're staring at a big, massive code base kind of which you had happen. How did you navigate the code base when you start, started it like, how did you know? Like, oh, there's this repo and there's like a hundred or more files. Where do I start? Did you have a process for doing that?
Speaker 2:I mean, I think I did. It wasn't really glamorous. I just found the repo that they're working in and I just try and find the first entry point, like the srcapppagetsx, and then go, okay, what does that render? And then you come on and click on that and it opens that, and then I just kind of followed the rabbit hole as far as I needed to go for that moment, like I learned, like I don't need to understand this whole thing right now. I need to understand what I need to do, to do. I need to understand what I need to do, my job and when. That my job will inevitably rely on some other jobs and you know I'll look into those.
Speaker 2:But there's some stuff in the code that I didn't really dive into because that's some back-end stuff that I'm not. Yeah, I get handed an endpoint and then I use it. I don't need to know how that works, I don't need to spend time drilling down into and now I'm out on my own personal time for me to learn about it, but for what I need to produce, I don't need to know that. Um, so I try not to get overwhelmed with, like the amount of stuff in there that I don't need to know for what I'm doing, but I would like to know it. I like knowing the bigger picture um of what's going on.
Speaker 2:But yeah yeah, I think that's just how I approached it and then kind of just started learning about things as I needed them. Like oh, I need to go into this actions file to create some stuff that the backend guys didn't do. Like, okay, let me see what they've done and how and the documentation and see how I need to do that, but slowly, I think, would be my answer. Like, don't just try and understand the whole big picture, just get a page up and running and then see what happens.
Speaker 1:And like oh, if I click here it goes there. Let me find that in the code Like how does that?
Speaker 2:link up and stuff.
Speaker 1:Oh yeah, that's that's. That's the process I've been using for years, whether it's like an API or a front end application or full stack, whatever I do just what you said, like find an entry point, and then I eventually will ask for some sort of task to do, Like, if they don't give me one off the bat usually the company I'll try to make an entrance by saying, hey, I really want something to do. You know, give me something and that'll be like my first little foothold that I can get into the code base. What's really cool, I think, about this whole experience is like now we're talking the same language, which I think is really cool, Because now in an interview, when you go into one, you now immediately have that kind of like that rapport with somebody and also that validation where you kind of are speaking the same language and you understand those same experiences that somebody that's written code in a professional setting has done.
Speaker 2:And I've got star stories as well, you know, for all those kind of questions. Oh yeah, Yep exactly you know, for all those, yeah, oh, yeah, yep, exactly, yeah, I want to go back to the um, to the get on so quick, like, and all the stuff that I said about how scary all that is.
Speaker 2:I mean yeah, there's a few commands you can run that are like destructive. But generally if you stay away from those like yeah, if I push something to main that shouldn't be there, they can just revert back like it's not as scary as it like comes across.
Speaker 2:So I I've had to keep telling myself that. But, like I said, when there's things like force and hard, I'm just like am I going to break something? Yeah, or am I good? Yeah, I still get those feelings. I'll be honest, and I don't know if this was your feeling. But sometimes when that happens and you feel like, oh my gosh, I've messed up, I'm fired, this is the end of some guy, just walked in oh yeah, that's fine, and then solved the problem and you're like I want to get there.
Speaker 2:I want to know that guy's like chill of, just like okay.
Speaker 1:I became that guy at one company. That was great. That was a great feeling when I went from like being the person that had to rely on a person to come do that and then at some point I became the person that was like helping out. More junior feeling. Because everybody gets into a bit of trouble with Git Because, honestly, the dirty secret is most people don't know Git very well beyond Git add, git commit, git push, and when they have to do anything outside of that flow and I'm talking about people that have been working in software for a while I mean I've seen this and they completely get blown apart. When they have to do something else, like a Git revert what if I have to revert the revert? And then all these other interesting things that pop up. You know we talked about um using large language models, ai with coding, but you know, um, I'm not.
Speaker 2:I'm not going to take my whole code base and paste it in and say here's my context, you know, do this thing like no, it's, it's helping me with individual tasks instead of the whole task, like individual smaller tasks and, uh, just making things a lot quicker. And then, as I say, like whenever I'm, if I do end up copy pasting stuff which still feels icky to me, but I'm trying, yeah and uh, I'm still going through it and thinking like okay, is this, is this calling the wrong function, is this pointing to the wrong thing? And, and it has sometimes, and I haven't caught it and I'm sitting there thinking I'm refreshing, why is this not working? The code's right, the console log is right, everything's good. And I see one little letter that got left out because I changed something, and just stuff like that.
Speaker 2:Yeah, yep, and you learn that once and then you check it again. It's been a learning curve, for sure, and I definitely want to tone back in my personal stuff with it, but I'm glad I've had the experience and the bad experiences of using it right now.
Speaker 1:Yeah, it's good to get bitten I mean, you can't cheat time in the saddle is my big takeaway. Like there's certain things you just have to experience, and I think that's kind of the magic of doing these internships, or even like just figuring out, like what do you want, what is in your head that you want me to make with code, and figuring out how to do that effectively. If you were, if you have advice for people, like what would you say to people that are out there that are considering doing an internship or doing some sort of freelance work? Do you have like any kind of generic advice or things that you wish you had known before starting an internship?
Speaker 2:Well, this, this is advice, but it's not that I wish I'd known, it's that I did know and I didn't. I did it, but not as much as I should have. It's just ask questions Like, even if you think you know what it is, just double check and say, hey, this is what I understand from you. If you think you know what it is, just double check, say, hey, this is what I understand from here. Am I on the right track? Um, so, yeah, I mean for me, as I said, I didn't. There were some questions I didn't know to ask, but what I, what I should have done, is what I just said, like before I got started hey, you sent me this thing. Um, I'm assuming this is what you want. I'm gonna go ahead and make this correct and they'll say yes or actually no. Uh, sorry, we should have said you know, this is a guideline or this is a whatever.
Speaker 2:Um, so just asking questions, like a lot of questions, um, and uh, I think I mean it's okay to over commit to a certain point, but I think at some point, like if, if they've given you an amount of time for a week, try and stick to it, um, it's okay to go the extra mile every now and then. But, uh, find that balance. I think of um not sacrificing your own personal stuff for um over over committingitting and burning out on it. It's a hard balance, I get it. You want to make a good impression, you want to do good code and sometimes, where you're at that good code can't be done in the time they give you based on your level. I get that and I've struggled with that. I've also had a couple of weeks where I've put way more time in. That's been good for me personally. So it's just about finding that balance, um. But asking questions, I think, is the main thing. Like, just don't be shy to ask questions and piss the people if they're not getting back to you I.
Speaker 1:I love that, um, because I've, I'm, I, I've learned both those lessons, and those are two lessons. Honestly, I find myself learning all the time. Unfortunately, every single time I start a new job, I tend to do both these things. I don't ask questions cause I want to appear either competent or I'm just nervous, or I think I understand something I don't and I'm still learning the people. And then I tend to go overboard in order to get something done in the amount of time that I think it should get done, or because I want to make a good impression, and I end up spending these marathon sessions. It is not, it's not sustainable and it's hard.
Speaker 1:It's really difficult to to know your limit and to to to stick to it, um, but those are really important takeaways. Um, you've done a hell of a job on the internship, by the way, just really top notch. It's been awesome watching not only the code you've written, but just I've done a few PRs, pull reviews, pull requests in this particular repo, and it is impressive. And the people at this business Founding Titans, by the way, I don't think it's a secret, but they've been overall, very impressed with the work that Parsity mentees have been doing as well, so really cool. Thank you for telling us about it and keeping it real, and if people do want to connect with you, what's the best way for them to do that?
Speaker 2:I am on LinkedIn. I don't know my user handle particular, but Dean Fox from Knoxville, tennessee, cool. I'm also on all the things Twitter, instagram, all that stuff. I don't know my handles because I'm not an influencer, but yeah, we'll get them in the show notes.
Speaker 1:We'll put them in the show notes. If you're so inclined, we'll add those in there, but yeah, thank you.
Speaker 2:I'm not super active on social media, but go ahead.
Speaker 1:We'll add them, man, just in case. That'll do it for today's episode of the Develop Yourself podcast. If you're serious about switching careers and becoming a software developer and building complex software and want to work directly with me and my team, go to parsityio, and if you want more information, feel free to schedule a chat by just clicking the link in the show notes. See you next week.
