DevQuestions with Tim Corey
I am Tim Corey. I teach coding online and my inbox is full of questions from current and future developers. I wish I could sit down with each of you and share the answers I know will help you go further, faster in the world of development. This podcast is the next best thing. On this podcast, I will answer the biggest questions people are asking! Send us to your suggestion for a future Dev Questions at https://suggestions.iamtimcorey.com/ To keep the podcast coming, like, subscribe, rate, and share it with your friends and colleagues. See why thousands of students have chosen to learn to think and code like a professional developer at www.DevForge.com.
DevQuestions with Tim Corey
195 What Is the Progression of a Developer?
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
What are the steps to move forward as a developer? What is the progression of learning I need to go through? Is there a specific path to follow? These are the questions we will cover in this episode of Dev Questions.
Website: https://www.DevForge.com/
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/
Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.
SPEAKER_02What is the progression of a developer? What are the steps a developer goes through as they increase in their knowledge and skill? This is the question we're going to tackle in today's episode of DevQuestions. Now, I want to point out before we talk about the steps, and I'm not going to say junior, mid-level, senior, we're not going there. We're going to talk a little bit more granular, a little bit more about the how it works rather than just giving random names to things. Because everyone has a different definition for those names. But at every stage, experience in that stage is what's important, not knowledge. So when we talk about these different stages, I want to make sure you know that it's not just, oh, hey, I learned that, therefore I'm through that stage. It's not about learning it, it's about having experience in that. Because that experience will help you build a foundation that you build upon for the next stage. So let's talk about the different stages. And these are loose, and sometimes you'll find yourself doing more in earlier stage, even though you've progressed in other areas. So just note that it's not a necessarily a linear graph. But at the same time, there is going to be a just starting out through much more advanced developer as we go through this list. Okay, so number one is you're just learning syntax. Okay, so this is where you're learning about the language. You're learning about how to even build something in the language. You're learning about if statements and variables and how to do loops and methods and all the rest. That's just basic syntax. And sometimes people think that when they've learned the syntax, that's when they understand the language. And in some ways that's true, in a lot of ways it's not. Okay, so really this is point one. This is the very top level, this is the very earliest in your journey is just knowing syntax. And it's really just barely the beginning. So if you find yourself in a place where you're you're just learning syntax, don't stop there. Okay, that's a great thing to do. And everyone starts at this stage, but you don't stop there. Okay, so learning the syntax and then learning how to use that. Again, experience is what's important at this stage. Not just knowing what an if statement is, but having used it 10, 20, 30, 50 times is what's gonna get a value to you. Number two, I call advanced syntax. So, okay, you've learned about how to do an if statement and a for loop and a for each. Maybe even know a difference between a do loop and a while loop and when to use each. That's good. And that's probably still back in the first syntax category. But then there's some more advanced stuff that you're gonna start picking up, the more like the 20%. You know, the syntax kind of covers the 80%, but the advanced syntax is like the stuff you don't use every day. Things that you might not uh do right away, maybe things like uh asynchronous is probably in that category, or uh delegates, or even some object-oriented programming things like inheritance versus um interfaces and multi-inheritance and all the other things that you could get into. Some of those things are more advanced in their syntax, and you won't use it all the time, but that's the next place to go is to dive deeper into the language, dive deeper into how to use the language in more scenarios. That's kind of level, the second area. After that is when you progress into problem solving and debugging. Now, again, you may have done some of this before because you probably had to solve some problems back in syntax. But this is where you really start focusing in on solving problems. As junior developers, often what you get assigned is all the tickets that come in for, hey, this system's broken. This we've got a bug over here. Can you fix this logic issue? Where you're not writing a new system, you're just solving a problem in the code that's existing. And this is where you learn how to track down problems and learn how to debug systems and figure out where the issue is and what's going on. Again, experience is really important here. This is why when I tell my students to go through the C sharp master course, we learn debugging early on because you're gonna have bugs when you start learning syntax. And I want you to practice that debugging right away. Because what is most important about problem solving and debugging is the experience of it. You can't just read a book on problem solving and then be a great problem solver. It may help, but the reality is having seen the problems and having gone through a debugging steps, the more you do that, the more skilled you will be in that area. Number four is okay, after syntax and advanced syntax and problem solving and debugging, you get to number four, which is knowledge of how applications are built. Not necessarily having built full applications yourself, but knowledge of how they are built. For example, as a junior developer, you might be in the room when the team talks about the decisions they make in building an application or in building a system or a part of a system. And knowing how that works and starting to figure out how that all fits together. How the it's more than just you know this little code bit here, but it's about the bigger picture. And sometimes, you know, decisions you make at the big picture will affect which code bits you use or how you use things. So knowing how applications are built from experience, from seeing it, is really valuable at this stage. And this is where you start getting into that, starting kind of creep into the mid-level developer where you you started to see this stuff and started to work on yourself. And then number five is firsthand experience on how to solve problems using long-term thinking. So when you get a help ticket and you may you know get an issue where they say, hey, when we enter zero, the system crashes. And you go and look and say, okay, well, we can just handle that and say, hey, if it's zero, don't crash. I mean, that might be a solution from a junior developer. But there are certain problems, and that may be one of them, but there are certain problems where there's a short-term solution, but there's a bigger implication. And you have to think through, okay, I could solve this specific problem, but I know that we're gonna have problems X, Y, and Z in the future. But if I solve it a different way, then we could solve all those problems or most of those problems, or mitigate potential problems by how we solve this problem. So starting to think long term, thinking about more than just the specific little issue you're in right now, but kind of picking your head up and looking at the whole system a little a little bit bigger. And you're looking a little bit deeper and a little bit farther down the road where you say, hey, if we do this, then this may become a problem later. And starting to think through those longer-term implications of what you're doing. Number six, knowledge of the patterns to solve common problems. Now, I intentionally said the patterns to solve common problems, not design patterns. Because yes, that's technically what we're talking about here in some ways, but not fully, because there are just normal patterns as developers that we have that we learn over time as we have solved problems. And this is where I put it at number six because I think it's important. And I got a future episode on dev questions that talks specifically on design patterns, but I think it's important to not put design patterns at the beginning. Because you haven't seen the problems, you haven't learned how to think long term, you haven't looked at the overall architecture of an application, even if you haven't built one, but having seen it, having worked in an application for a while where you know how applications work and how things interact with each other, at that point, then you've already seen how to do certain things, and you've seen what problems come up when you do certain things certain ways. Once you have that knowledge, then knowing about certain patterns that could help make those problems easier is helpful. Knowing how to do things better and make things better with a pattern can be very, very valuable. But if you don't have the history of knowledge of the big picture and of long-term consequences, well then you apply patterns in a way that is really irresponsible. And you don't know any better necessarily because you've never seen the consequences of those long-term decisions that you're making by creating a pattern or using a pattern. So being careful to know what the problems are and know the problems you're solving with a given pattern is really important at this stage. And then again, practicing it. Number seven is that you have an expanding viewpoint on your capabilities. So, okay, when you think about what you can do, at first, maybe you're working in just methods and say, okay, I can run a method. You know, at first you're in a help desk or you're you know solving help tickets where you saw a bug in somebody else's code. But now you started to build methods. And then maybe you build whole classes to solve problems. And then from there, you start adding features to your application. And then maybe you start building small applications or even whole systems that, you know, this part of the job takes a long time, but you start to grow out of, I can do this a little bit at a time, to I've got the long-term picture. Um, I've got in my head, I've got the idea of how problems can manifest and the history of how to make sure that I avoid certain problems and pitfalls. And I know how to kind of architect, really, is what you're starting to do. And it's not, you're not a software architect yet. You may be even just a mid-level developer. But what you're starting to do is learn how to architect small little bits. Start small. Don't start with, I'm gonna build an entire application that everyone depends on. Not the place to start. You need some practice, you need to build up to it. But you start with a method and say, okay, how can I design this method in a way that is thinking long-term, is hopefully bug-free, or you know, applying the principles I've seen to make it as bug-free as possible, and in a way that is going to help us out for the future. And you start doing that with a class, and then a system or a part of your application, and then a whole system, and so on as you grow in your skills. Again, this is where a lot of practice comes into place. Where you're doing spending a lot of time just building things. Now, number eight is when you start to mentor or lead others. This is where you deepen your abilities. So you spend some time one-on-one helping people grow, helping people below you, the juniors, the mid-level developers, you're starting to say, hey, let me give you some guidance, some help. Maybe you start stepping into a team leadership role where you have a small team of developers that works with you, that you kind of lead and guide, and you start to create that long-term thinking for the team, not just for yourself. You see, you keep growing and building upon what you've done before. And once you've kind of conquered that, this is when you step into the next role of training others, blogging, speaking, teaching. This is part of your growth process. Now, not everyone gets here, but I think it's important that the developers that want to go the farthest do this. And it's not because, you know, it's not if there are a certain personality or a certain no, it's about you learning. It's about you learning how to communicate to a wider audience, to an audience that's not just one person or four people, to an audience that could be hundreds or thousands in a way that is clear, that's concise, that has, you know, steeped in gray advice, that is leading them in the right direction. By doing so, if you do it right, you should be pushing yourself further. So that's kind of the structure I see, the growth pattern of developers. That's what I look for in developers and kind of figure out, okay, where are you in that one-to-nine scale? Where are you? Because if I hire you to be a senior developer, I want you to be in that number eight range at least. I want you to be to the place where you're starting to mentor people. You're starting to deepen your abilities by helping lead others to deepen theirs. So figuring out where you are on that scale is important. Figuring out what the next step for you is is important. But the most important thing is to practice what you are learning. Practice your particular number and start practicing the next one as well. All right. So that's my thoughts. That's uh my thoughts on what is the progression of software developer? How should you progress in your career? All right. Thanks for listening. And as always, I am Tim Corey.
SPEAKER_01Thank you for joining us for this episode of Def Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Deaf Questions. You can also send your questions to questions at IamTimcorey.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.