DonTheDeveloper Podcast
DonTheDeveloper Podcast
3 Ways to LEVEL UP as a Junior Developer
In this video, I’m going over three key ways you can level up as a junior developer. These aren’t magic tricks or quick fixes; they’re real strategies that many successful developers have adopted.
First, we’ll talk about why mastering the fundamentals matters more than you think and how it sets you up for success beyond just following tutorials. Then, I’ll cover the importance of improving your process and why planning your work can set you apart from other juniors. Finally, we’ll dig into soft skills—how to build better relationships with your team and why this often overlooked aspect can make or break your career.
This isn’t just about coding; it’s about becoming a developer who understands the bigger picture. Let me know in the comments if these resonate with you or if you have other ways you’ve leveled up in your journey.
---------------------------------------------------
🔥 Webdev Career Help - https://calendly.com/donthedeveloper/coaching
🎮 Join Discord - https://discord.gg/TpQe2k8Ab3
❤️ Support What I Do - https://www.patreon.com/donthedeveloper
Disclaimer: Some product links are affiliate links which means if you buy something I'll receive a small commission at no extra cost to you.
===========================
WEBDEV COURSES I HIGHLY RECOMMEND:
🎓 Learn Frontend - Scrimba (20% off): https://scrimba.com/the-frontend-developer-career-path-c0j?via=donthedeveloper
🎓 Learn Backend - Boot.dev (25% off): https://boot.dev/?promo=DONTHEDEVELOPER - Get 25% off your first payment with code "DONTHEDEVELOPER"
🎓 Already Experienced? Level Up Here - Code Crafters (40% off): https://app.codecrafters.io/join?via=donthedeveloper
In this video I'm going to talk about three ways to level up as a junior developer. So what are the first ways? Let me share what I did when I was trying to get better with JavaScript. So I was in the JavaScript world, I became a front-end developer, I was a UI engineer initially and I, you know, I was pretty comfortable with CSS and JS and I at least I thought I was I was pretty comfortable with React as well.
Don Hansen:And then I remember leaving that position, going into the second position, and the second position really showed me how bad I was with JavaScript. Like, I was really bad compared to a lot of other people on the team bad compared to a lot of other people on the team and so I learned over time that the reason why I was bad was because I really didn't have a grasp on the fundamentals, at least as strongly as I thought I did right, and so the best thing that I did for myself was I jumped into Eloquent JavaScript. It was recommended by one of the developers on the team and eloquent javascript has some depth to it, right, and it really helped me understand javascript a lot better than I originally did, which then allowed me to just kind of like grasp and understand the concepts and debug, I guess, like more trickier situations. With React. I knew what React was doing and you know I really could start to design like a really, really basic, fundamental front-end framework for myself if I really put the time into it. Now it's not going to be something like React, but you know, at that time I could have just built a basic version of React and I was capable of that, but before I dove into Eloquent JavaScript I don't think I could have.
Don Hansen:I didn't really understand what React was doing, I didn't right, and I feel like there's just so many building blocks that make up the abstractions that we have. There's just so many building blocks that make up the abstractions that we have where it's easy to just put this software, this framework, on a pedestal and it does all these magical things that it was built by developers way more brilliant than us and we just could never understand, like what the hell is happening, right, but sometimes you do, and so it's easy to just like put that off, like, oh, maybe one day I'll be that good of a developer, but I think that's more achievable sooner in your journey than you think it is, and I think a lot of people could build a basic version of react if they have two to three years in the industry like a really basic version. It just depends on how comfortable you truly are with the fundamentals of the language that you're working on. And I've realized like, even if we moved out of React, even if we built something custom for example, one of my positions we had a custom library that worked like Redux. Right, we didn't use Redux, but we had a custom piece of software that worked like it and I could kind of understand the inner workings of that the further I dove into my fundamentals and I think a lot of people and I would really challenge yourself do you really think you understand your language? Do you really think you understand programming fundamentals, especially if you're going the alternative path, as well as a CS grad, as well as someone who really likes to explore and tinker, and they're curious and they want to keep asking why does this work? Why does this abstraction work? How does this abstraction work? They just keep digging deeper. Do you really think you understand or like have a solid grasp of fundamentals as much as you think you do? I think most people don't and I think it takes many, many years to even feel like you do, to then understand you could still go so much deeper, right, but I think that's an aspect of growth as a junior developer that I like. I start to see people moving from a junior to a mid-level developer when they really really build that solid foundation and they care about it and they dive deeper and deeper and deeper and don't just lean on abstractions right without understanding how those abstractions work and how to break those abstractions down if needed. Focus on those fundamentals, build those up. We all have to continue to work on this and it's just one way to level up as a junior developer. The second way is your process.
Don Hansen:I don't know about you, but when I first started I loved just writing code and seeing what happens. That was fun. I got to see whatever popped up on the console log, whatever popped up on the page right. And even in my personal projects I would just build. I would like I'd start with a navigation. Okay, let's build a personal project. Well, I think I can at least do a navigation. Well, if I can't even do that, I could do maybe like the top of my landing page, right, because I am not super comfortable with building a hamburger menu just yet, so I can't really build a mobile version of it, so let's just do like a really basic landing page. I'm going to build that out and then I'm going to add the navigation, and then I'm going to I don't know maybe add a form and or maybe a contact email on the bottom, and I might add some links for my footer on the bottom.
Don Hansen:And now let's add some other pages. Right, I kept adding and adding and adding. I kept thinking, like, what else could I add? But I never stopped to think about what the hell I was building. Right, I didn't plan it out, I just kept adding blocks to my project, these little modules. I just kept adding and adding and adding, and I never really thought about the problem that I was trying to solve. I never really thought about the content that needed to be on the page. I never really thought about the users that were going to use my application and what were their priorities. And, like, what the hell? What kind of problem am I trying to solve? What the hell am I trying to do? Right? The hell am I trying to do Right.
Don Hansen:And so you know, you're going to have a stage where you probably should just take a day and just code and not. You don't really need to think about like, oh, I got to build this expert project. No, I just want to build something. Let's just code it out. Let's just write code and see what happens. Right, that's okay. Right, but over time, especially when you really want to be seen as a professional developer, especially when you want to start moving to even that mid-level position right, you really shouldn't be leaning on your product manager to write technical requirements, like that's something that you should take ownership of, right? So, even if you're not really solving the business problem and you're given the solution and you have to come up with the technical requirements that make up that solution, that's a step up. I remember when I was starting out, I was given those technical requirements and I just went line by line by line by line and I solved those things in my code, but it didn't really require a lot of critical thinking or planning, right, I wasn't really mapping out the entire feature and all those building blocks that made up that feature. I was just building it and then building on top of that and building on top of that until I created what was asked of me. Right, that's what a junior developer does, that's what a basic junior developer does.
Don Hansen:But once you start moving more towards that middle level range like, you're taking ownership of the app that you're building, you're taking ownership of the feature and you are writing out those requirements and you are figuring out the scope of this feature and you are figuring out potential blockers and you are writing tickets for all of this. Right, writing issues on your epic or however you want to organize this. You are planning all this out and you're able to tell that project manager that, hey, you know, like, hash this out, this is going to take this amount of time. And then you know, when you start moving into the mid level, you are starting to take more ownership over your parts of the app. Right, you might get some user feedback. You might hook up your part of the app or set up events to be triggered with Google Analytics. You might want to pay attention to hot jar recordings. You might want to figure out how people are using your app.
Don Hansen:What are the frustrations? Right? A really valuable thing to do as a developer is, once you build something, to take ownership of it and track that. What the hell is happening? Are users frustrated with your feature, are they exiting out right away? How do you figure that out? Right, how do you? And once you do, and you realize, hey, you know, like, even if you just got some user complaints from customer service or whatever, like then what do you do about it? Do you depend on the product manager to then map out more features or create bugs for you? No, you pop up a bug in Jira because you heard some complaints about it or you experienced a bug yourself. You create that bug and you prioritize it and you got to realize like, okay, so what, what parts of my features or what parts of the app have significant traffic going to it that might lead to, like failed conversions and lost revenue for the business.
Don Hansen:Like, a lot of developers don't start thinking about this. But this is where you start. This is where you start to become a user-centered developer that cares about the features, that features that you're building. You take ownership over your part of the app and you're proactive with creating potential features and you might have some uh, stakeholders that you got to run your features through, but it it's like, hey, you know, like when you start taking ownership of, um, a part of your app, that could be so much better and you propose something that you know where you could official, efficiently plan this entire thing out. You, you come out with a proposal and you come up with issues and you come out with a bit of a timeline and you take ownership and show that product manager or whatever stakeholders are going to care about this. You say, hey, you know I can get this done in a week or two. I really think it's going to help people going through this flow of the website, this part of my app. I think it's going to make the user experience way better, and here's why, right. And then you start.
Don Hansen:You start actually documenting what this feature is like, the details of this feature, what is going to mean complete with this feature, and then breaking it out into its technical requirements, which is going to start with breaking it out into its pieces, its modules that you're going to work on. Try to split that up and then more specific, more specific technical lists within each issue that makes up this entire feature. That's going to take two to three weeks or whatever. This is the kind of mindset that good mid-level developers will start thinking about, and it more is in line with just becoming a developer that takes ownership over the work that they do, over the parts of the app that they manage, over the shit that they build for users and they care about it. Right requirements, um, and figure out, like, okay, what are going to be maybe spikes, maybe things that I need to dig into, that I'm a little unsure of, like, what are the hardest parts of this feature? How do I figure this out? How do I figure out if I can get this done in two weeks?
Don Hansen:Often it's like it's usually prototyping or tackling the hardest thing first and making sure that you have that down it does work within your application. Um, before you dump all of your time into building out a bunch of small stuff to then and cut, like, if you take two weeks to build out a bunch of small little pieces and then you get to a really hard part that just doesn't work for your app or it's going to take three to four weeks. That's what junior developers do. That's what, like, really starting junior developers do. They don't really plan this out, they don't prioritize things properly. You should be able to tackle the hardest thing and figure out can I do this in two to three weeks? Right, and then break it down from there into smaller issues and plan out your sprints.
Don Hansen:It's more, it almost is more of like a. It starts with, like a product ownership role, a user. You become a user center developer and then, before you even dive into the code, building out a bunch of shit that might not matter, you plan this out. You are able to identify the really hard part that you need to tackle and why it's difficult and how you're going to go ahead and actually learn this, whether it's like looking through documentation, whether it's building like a mini prototype, uh, just to test this, improve this. Um, you have to figure out like where you even start. But it starts with planning. It doesn't. This mid-level mindset doesn't start with you just jumping into the code and building out a bunch of small things to make yourself feel better and get those dopamine hits. It requires real planning, which requires context, which requires, obviously, a solid foundation with fundamentals, but you know a broader context of like how your application works, and it requires you understanding. You know where stakeholders want to take the business and you know where your users are at Like. There's a lot to this, but it's planning, it's building up your process around coding and building that just focuses more on initial upfront prep.
Don Hansen:That's the second thing. Now the third thing is soft skills. One thing you'll notice with a lot of senior developers that you know mentor people at your company that a lot of people respect. They have good soft skills, right. They care that. They have good listening skills. They have good active listening skills. They care about what you have to say, especially if they're mentoring you as a junior developer. You know they want you to almost get there, get most of the way there on your own and do a little bit of research on your own, and they want to build resourcefulness. They don't want to create dependency, right, they don't want to just tell you the answers right away. They want you to learn how to find the answers. So you know that's a soft skill or that's just a good mentorship skill senior developers have.
Don Hansen:But you know other senior developers. You'll notice the way that they interact with design, they interact with product. They interact with you know CTO different, just different stakeholders in general, like they become good active listeners. They understand the business requirements. They understand the user's concerns. They understand different stakeholders concerns. They understand the frustrations that the designer has went through, uh, with the front end team and the back and forth that doesn't always hash out cleanly and they try to empathize with that and they try to just understand, like, what the designer like really needs from me at this time as I talk to them, um, what their expectations are. And, like you're gonna find, it's not just different stakeholders have different expectations of the conversation with you and they want different things from you, but it's also different personalities within that department that you then have to figure out and maybe, um, I don't know, maybe Jill gets really defensive she has an ego, right. Maybe Jack comes in hungover every Monday and Monday's not a good day to really be critical of a lot of stuff with Jack, right, with his code reviews, and that's what it's about. It's about understanding the team that you work with, the individuals that you work with, and having some empathy in your conversations and just working on your soft skills, your people skills. This is a big thing, right.
Don Hansen:A lot of juniors come in with egos and you know I'm not saying it's a good thing, but it is common and those egos, if you want a long-term career as a dev, that needs to be crushed to an extent, right. That ego prevents you from learning, from growing and from connecting with people on your team who are going to contribute and want to help you grow and learn and build yourself up, and build yourself up within the company as well. Like, there are politics within a company, right? You know a lot of people don't like office politics. I don't know what to tell you. They exist. Start your own company if you don't want to deal with it. Oh wait, you are going to deal with it because you're going to have customers.
Don Hansen:Trust me, that bullshit never goes away. It just changes. It's form changes. It's like a ditto that just constantly changes into the next pokemon or the next challenge that. I'm not really good with analogies, but you get what I'm saying right. Um, you're never going to be able to escape from having poor soft skills and this is not a profession anymore for 99 of developers where you can just get away with being just a grumpy developer with an ego that just sits in the a corner and codes all day. That's, that's not a reality for most developers and you. You have to just accept it, whether you want to or not, and just work on those soft skills.
Don Hansen:So three things um, really getting a solid, fundamental uh foundation, which most junior developers don't have right, because it takes a lot of time to do it. And reworking your process, taking more ownership over what you're doing, like actually critically thinking about the feature that you're building, breaking that down and then breaking that down into more technical requirements. It requires a lot of you know thinking, not coding. Thinking initially planning, and it's just a of you know thinking, not coding. Thinking initially planning, and it's just a mindset you got to shift. You could do that. You could just shift your mindset right.
Don Hansen:These are just things that you kind of start out at a certain point and you start shifting it over time. This is a very normal process for a lot of developers that are in this for the long run. And then your social skills and I know a lot of people don't like when I say this, but it's just true. You can't escape it. You know like you're working with people, you're building stuff for other people. You gotta build up your social skills, no matter how uncomfortable that is. So these are three ways to level up as a junior developer. If you have other ways, definitely let me know in the comments. But