Developer Tea

Listener Question: What's The Difference Between a Junior and Senior Developer?

Episode Summary

Today we'll explore what the difference is between a junior and senior level developer, basic characteristics, and how to get from junior, to mid and senior programing levels. Today's episode is sponsored by Code School. Code School is an online learning destination for existing and aspiring developers that teaches through entertaining content. Visit www.CodeSchool.com/developertea for more information and start playing courses now.

Episode Notes

What is the difference between a Junior and Senior Developer?

In today's episode, I talk about what it takes to get from Junior level programmer to a Senior level programmer. We'll go over some basic characteristics of the two levels, and tips to get further in your programing career.

Special thanks to Today's sponsor: Code School

Code School is an online learning destination for existing and aspiring developers that teaches through entertaining content. Visit www.CodeSchool.com/developertea for more information and start playing courses now.

Episode Transcription

Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today I'm going to be answering a listener question from Levon. Levon, I hope that I am pronouncing your name right. But in any case, I'm gonna go ahead and read Levon's question. It's about the difference between different levels of developers. So he asks, what is the difference between a junior and senior developer? My girlfriend says it's time. I lean toward it being a matter of experience. I've been working as what you referred to as a general developer in a previous episode. For the past 15 years, I've worked with HTML, CSS, and JavaScript, but not deeply and mostly on my own time. I've done projects with various languages in the past, and I can write some SQL, but I'm not one to create a new database via the command line. I'm not a newbie with this stuff, but I'm self-taught, so I'm no expert. I'm trying to get out of my job and go somewhere where I can finally move to the next level. But I'm not comfortable with the senior programmer label since I don't know exactly what that means. I see jobs for junior developers, but that usually involves working with languages I don't know and or some kind of ninja or wizard skills that I don't feel like I have. I feel stuck in limbo and I'm totally bored at my job, but I can't get out. Any advice would be appreciated. I'm trying to move towards JavaScript with something like Node, Express, Angular, and Gulp. Thanks. Levon, let me first say that there are a lot of people who are in your same situation. They're in a job that they don't feel like they want to stay in. So hopefully if you're listening to this episode right now and you're in that position, your ears are kind of perking up a little bit because there is always a future for you. And to be honest with you, there are very few employers who actually want to stay in that position. So I'm going to give you a little bit of a rundown of what's going on. I'm going to give you a little bit of a rundown of what's going on. I want you to stay there if you don't want to be there. As an employer, I know that I want the people on my team to be 100% in the pocket and excited about the work that they do. And if they can't be excited about the work that they do, then I would rather them go and find something that they can be excited and me go and find someone who would be excited about doing their job. Now, don't take that speech as a go out and quit today. That's not what I'm saying. Of course, you know, there's a time and a place to move on. to the next phase of your life. But don't feel like you have to stay tied down to an employer or that you can't get out. Just remember that there is some weight to that decision, perhaps more weight to that decision than most other decisions that you would make in a given day. Now, with that said, your question is a little bit hard to answer. And it's not because you worded it wrong or anything like that, but because junior and senior developer, there's not really a lot of time to do that. So I'm going to give you a little bit of a rundown of what a junior and a senior developer is. And I'm going to give you a little bit of a framework for thinking that, you know, industry standard, what a junior and a senior developer would probably be required to be able to do or what their job looks like on a day to day basis. But there's not a single, you know, canon out there. There's not a single rule that you can apply to a junior and a senior developer. And so I'm going to give you a little rule set that explains exactly what a junior developer does in relation to a senior developer. Both you and your girlfriend then are right because of this. And that means that it has something to do with both time and experience. And I would extend that argument to say that time and experience are kind of inextricably connected to each other. You can't get experience without spending some time. And of course, vice versa, you can't spend time without experience. You can't spend time being a developer unless you're being lazy and actually not being a developer without gaining experience. Those things are definitely connected. Of course, some people gain more valuable experiences in shorter amounts of time, which is why you see some senior developers getting to that position much faster than others. So it is definitely not a perfect equation. Five years doesn't mean one job versus 10 years meaning another. There are some kinds of things that are connected to each other. And I'm going to give you a little bit of some companies and also there are some industries that set up those kinds of rules that you cannot be a senior developer until you have put seven years into this company. Some companies are structured that way. So that is a partial answer to your question. Some companies require a specific amount of experience or a certain number of years working in the industry. But as I said before, there isn't a hard and fast rule. So it's a little bit difficult, again, because there's no right answer to this question. But I want to give you a framework for thinking about the different types of jobs, thinking about the different types of responsibilities. The reality is the responsibilities of a junior programmer, a mid-level programmer, and a senior level programmer are all very different. Each and every day looks very different for each of those different roles. So let's start with the junior programmer. The junior programmer, kind of the one that's right out of school, or perhaps they are right out of their own training programs, and they've gotten to the place where they can work and be somewhat productive, but they need help quite often. Often they have very little context for how to approach a given problem until somebody gives them some kind of context or direction. Sometimes they will even ask, what should I search? What should I Google? Everybody who is a programmer these days is using Google pretty regularly, I would say. At least I think I use Google probably more than any programmer in the office. So many of us solve problems by Googling things these days, but a junior level programmer is the kind of person who doesn't even really know exactly what to Google just yet. They have a hard time reading stack traces in order to figure out what line is causing a problem. They have a hard time reading stack traces in order to figure out what line is causing a problem. particular error. So they're often calling on the help of either other juniors or mid-level, and every once in a while, they'll call on the help of a senior to come and help figure out how to solve a particular problem or give them some kind of context for how to solve a given problem. Sometimes people in this position aren't sure what type of programming they even want to pursue, whether that's languages or what types of problems they like to work on, and they're working in a junior job in order to learn more about what they want to do, because honestly, they just don't have the context to even decide whether or not they want to pursue this as their lifelong career. That's true for some juniors. Of course, again, these are all just guidelines. Some juniors have significantly more experience and know for sure that they want to go straight down this path. But the thing that binds all juniors together typically is that they don't have a lot of experience to draw on. They don't have a lot of experience to draw on. They don't have a lot of experience to draw on. They don't know exactly how to solve all the problems that they're running into. So for that reason, you can't build a business entirely out of junior level programmers, typically speaking, because they don't have context and there's a lot of kind of lost time that goes into figuring out what to do to even start solving a problem. And that is where the teaching of a mid-level or a senior level programmer comes in. That's why pairing is so important. Is so important and so pushed, especially for younger programmers, but also for more experienced programmers. And before I talk about mid-level and senior level programmers and the characteristics of those positions, I'm going to take a quick sponsor break. Thanks so much to today's sponsor, CodeSchool. CodeSchool is an online learning destination for existing and aspiring developers that teaches through entertaining content by pairing immersive video lessons with in-browser challenges. CodeSchool has become the best place to learn new technologies from the comfort of your browser. Each course features a unique theme and storyline, so you feel like you're playing a game rather than sitting in a classroom. Whether you've been programming for decades or have only just begun, CodeSchool offers something for everyone. Choose your learning experience from CodeSchool's five main paths, JavaScript, Ruby, Git, HTML and CSS, or iOS. Or you can take advantage of CodeSchool's growing number of elective courses, such as the CodeSchool course like TriR and Chrome DevTools. Take your learning on the go directly from your iPhone or iPad from the free CodeSchool iOS app. More than a million people around the world use CodeSchool to improve their development skills and learn by doing. You can join them by visiting codeschool.com slash developer T for more information and to start playing courses today. So we've been talking about different levels of experience and the different types of programming that you can use. And I'm going to take a quick sponsor break. So if you're a programmer jobs and those titles that come along with those jobs, for example, the junior level programmer, a mid-level programmer and a senior programmer, there's all different types of job titles that come along with a given agency. Sometimes people call the job title wizard, which is one of the things that the listener Levon has asked about. Of course, Levon is very specifically looking to move into a JavaScript job. And we'll talk a little bit about that. But I want to go ahead and give you guys a little bit more of an idea about what a mid-level and a senior level job typically would look like. So for the mid-level positions, you're typically going to see developers who are fully competent to solve 90 to 95% of the tasks that they receive completely on their own if they needed to. And typically they aren't completely in the dark. And when they ask for help, it's usually in order to gain a new perspective. And they're going to be able to get and most often that's from another mid-level developer. Usually it doesn't need to go up the chain any further. Usually it's just a, I need new perspective, or maybe I've been looking at the problem for too long and I feel like, you know, maybe I'm a little bit burnt out on the problem. And so I just need somebody to come in and look at that and look at this. Maybe it's right in front of my eyes and I don't see what's happening. Or maybe they've experienced this problem and it's just not one that I've experienced before that falls in that 10, five to 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10% of the tasks that I'm unable to complete as a mid-level developer. Of course, they'll still often run into problems that they must research as a mid-level developer. But the main difference between the junior and the mid-level is that the mid-level feels fully confident in being able to research the right things and solve those problems relatively quickly. They don't chase down the wrong paths a lot of the time. Usually they know exactly, what they need to actually Google, or they know exactly what the problem type is, what is most likely causing the problem, but they may not know the exact syntax that they need to use in order to fix it. But they typically have a given path that they know that they need to walk down in order to fix a given problem. So the junior's job typically is to learn a lot, to soak up as much information as possible, not for the sake of learning, but rather for the sake of becoming competent and able to solve problems faster in the future. When they encounter the same issues in the future, they are able to solve them much more quickly and without having to bring somebody else in just to solve a problem that they've already experienced before. If I had to characterize the mid-level programmer's job, I would say that it's primarily to write good code. Now, that seems obvious. That's all programmers' jobs. But the mid-level programmer, the output of quality code is typically much higher for the mid-level than it is for the junior. And sometimes it's even higher for the mid-level than it is for the senior. And I'll explain why in just a minute. So the mid-level's job is to ensure the quality of the code that they're writing and to actually write code, to actually stay on task and in the pocket and writing code. At a relatively predictable and sustainable rate. The senior level programmer's job is slightly more nuanced and it adds a bit of more responsibility to that person's plate. Typically, senior level developers are connected to the business level decisions. They talk to somebody who is not a developer as their quote unquote boss. They have some kind of insight into what the business needs to do. And they have some kind of insight into what the business needs to do. They have some kind of insight into what the business needs to do. And they have some kind of producing or perhaps some of the business level strategic decision making that maybe some of the other developers are not really thinking about all the time. And the reason for this is because the senior level developer has a little bit more intuition because they've been in the business world for a little bit longer. Now, of course, every developer all the way down to the junior developer level position, everyone should be connected to the business at a cultural, and a value set level. Everyone should be aware of the business goals. And all of that needs to be transparent, of course. But the senior level developer is more responsible in their day to day life. And in their day to day responsibilities, they should be thinking about these things and considering whether each and every decision they are making is driving towards those business goals or not. And you'll notice that I'm framing this conversation primarily from the perspective of a traditional software development firm. But this is true, typically, of most developers who would consider themselves in the senior role. Their level of responsibility for the actual end product goes a little bit beyond just whether or not the code is good, or if the user experience is solid. It actually goes into whether or not this is a viable product. Are we going to be able to maintain it at a sustainable level? And I think that's a really important question. And I think that's a really Do we have the developer resources on our team? And there's so many nuanced decision-making responsibilities that go into a senior level position. So, in some ways, the senior level developer is typically considered kind of a managerial position, as well as a technical position. Again, these are not hard and fast rules. There are plenty of senior positions out there that are solely technical, where you're hyper-focused on what you're going to need to do, what you're going to need to do, what you're going to need to do, on one specific technology, and you don't have to interact a lot with business plans or proposals or any of those other things that most mid-size firms most likely would require of a senior developer to interact with. But this is, again, just a blanket statement kind of blueprint for what these jobs would typically look like at a given software development firm. Senior software developers are also pretty often brought into the hiring process in order to vet the skills of junior level or mid-level developers, and also even more senior level developers. If you're hiring, typically you're going to talk to somebody that is in the senior level of a given department, and that includes development. Seniors often provide architectural expertise, solving problems by determining kind of the system level tools, and procedures for the larger project. So that idea of zooming out and looking at how the entire system works together, what pieces and parts are moving in this big system. And of course, I'm talking in somewhat abstracted terms because these positions can be working with many different types of software, many different actual delivery venues and media. So I don't want to drill down into the specifics of this, but I'm going to talk a little bit about the different types of software that we're working with. So I imagine that a given senior software developer is looking at the big picture, while a mid-level software developer typically looks more at tools and then uses those tools to accomplish those features. The senior level developer is looking more from the business perspective and scoping the project and determining the future of the project and all of those larger level goals that each and every project has. On top of all of this, senior level software developers, of course, are never too good to get into the weeds. Small bug fixes, syntax errors, those are still things that senior level software developers very often execute on. And that's because code is still code at the end of the day. Writing a good method definition or a good class or a good function or a good routine, all of those things are still things that senior level software developers, should practice and be very aware of on a day-to-day basis in the most common cases of this job. Now, Levon, I know that you want to get into JavaScript development a little bit more. You've said that you've worked with PHP and Perl in your email to me. I think that there is a lot of opportunity in JavaScript. I haven't been very vocal about it on the show, but I think that any time you spend learning JavaScript is time well spent. So I would recommend that you go out and try to find an open source project in JavaScript. Go and find one that you can work on with a team of people who need open source contributors. I would even say that you should focus on finding one that's a little bit smaller. Don't go and try to work on Express or something like that, but instead work on a project that uses Express and go and open a issue or two on GitHub and try to work on a project that uses Express. So I would recommend that you And once you've found a solution, once you've actually executed on a solution and written tests and all your tests are passing, go ahead and issue a pull request. Now, the reason I say you should do this is because, number one, it benefits the community because you are helping solve real-life problems. Number two, it actually benefits you directly because it builds up your experience and it also builds up your credentials. You can show your code. You can show that you actually solved real-world problems. Of course, you're learning JavaScript in the process and you're building positive relationships between yourself and other developers in the community. So there's so many different reasons why contributing to open source is a fantastic way to build your portfolio, especially if you're looking to move into a new technology. Go ahead and start learning that technology before you try to move into it. Of course, you can't take a senior level position with a technology that you don't know how to use. So if you're looking to move into a new technology, you can't take a senior level position with a technology that you don't know how to use. So if you're looking to move into a new technology, you can't take a senior level position with a technology that you have no experience in because you would quickly find out that that's going to be difficult for you. You might even end up feeling like a junior level where you don't know even what to Google to solve a problem. So go through those hard parts. Get relatively familiar with the tool sets and the community and perhaps some of the conventions of those tool sets. And at that point, you can start talking to these companies who have posted requests for senior level developers. And talk to them about your actual responsibilities as a senior level developer. Does your experience actually qualify you, for example, as a senior level developer? Some of these people, as I said earlier in this episode, have a very specific set of requirements in order to even apply for a senior level position. So talk to the companies and get an idea of what those responsibilities are. If you feel comfortable with your skill set as it relates to, what that company is looking for, then the title doesn't really matter at that point. You can be a junior or a senior developer. And if they're looking for a particular skill set, then you can throw away the title. It really doesn't make any difference as long as your skills are matching what that company is looking for. And you are happy with your compensation. And you feel like it is fair for the work that you're providing. Levon, I hope that this has helped answer your question today. Today's episode of Developer Tea, I've got one more thing to talk about, and that is learning. You guys know that it's so important to keep on learning as a developer each and every day. I've done so many episodes on how to become a better learner. But perhaps the best way to be a better learner and the best way to learn is to do, to actually get on the ground and start coding. And Code School is a way that you can start doing that. Code School is today's sponsor, of course. You can go and check it out at codeschool.com slash developer tea. That's a special link that lets them know that you're coming from developer tea. I would really appreciate if you use that link, which is in the show notes. But Code School is a great option for you, whether you are at the beginning of your career, just learning how to do the very first basic hello world stuff. Or if you're well into your career, and you want to learn more about a given subject, they've got so many different courses, they've even got electives. So go check it out codeschool.com slash developer tea. Thank you again for listening to today's episode. And until next time, enjoy your tea.