Hey, everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be answering a listener question from Levant. Levant, I hope that I am pronouncing your name right. But in any case, I'm going to go ahead and read Levant'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 wanting 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. Lavon, let me first say that there are a lot of people who are in your same situation. They are 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. To be honest with you, there are very few employers who actually 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, 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 specific rubric out there to define what a junior and a senior developer is. Of course, there's some things that we can kind of extrapolate. Now I'm going to do that in a minute to kind of give you a framework for thinking that 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 canon out there. There's not a single 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 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 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 is 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 particular error. So they are 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 know exactly how to solve all of 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 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 Code School. Code School is an online learning destination for existing and aspiring Developer That teaches through entertaining content. By pairing immersive video lessons with in-browser challenges, Code School 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, Code School offers something for everyone. Use your learning experience from Code School's five main paths. JavaScript, Ruby, Git, HTML and CSS, or iOS. Or you can take advantage of Code School's growing number of elective courses like Try R and Chrome Dev Tools. Take your learning on the go directly from your iPhone or iPad from the free Code School iOS app. More than a million people around the world use Code School to improve their development skills and learn by doing. You can join them by visiting codeschool.com slash Developer Tea for more information and to start playing courses today. So we've been talking about different levels of experience and the different types of 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. Because people call the job title wizard, which is one of the things that the listener Levant has asked about. Of course, Levant is very specifically looking to move into a JavaScript job. And we'll talk a little bit about that towards the end. 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 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 need new perspective or maybe I've been looking at the problem for too long and I feel like maybe I'm a little bit burnt out on the problem. And so I just need somebody to come in 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 5% to 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. And 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 programmers 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 levels 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 programmers 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 be 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 pace? 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 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 just 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. 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 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 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. Levant, I know that you want to get into JavaScript development a little bit more. You've said that you've worked with PHP and Pearl 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. 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. Go and try to work on Express or something like that, but instead work on a project that uses Express and go and open an issue or two on GitHub and try to work towards a solution. 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. The reason I say you should do this is because number one, it benefits the community because you are hoping to 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. 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 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. 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. 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. 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. Levan, I hope that this has helped answer your question today. Thanks so much for listening to today's episode of Developer Tea. I've got one more thing to talk about, and that is learning. You guys know that it is 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. 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. Code School.com slash Developer Tea. Thank you again for listening to today's episode, and until next time, enjoy your tea.