© 2019 Tim Buchalka
  • Tim Buchalka

Explanation of Various Programmer Roles

Today I want to discuss various programming roles. We're talking about junior developer, developer, senior developer, and a team leader.What are the differences with these roles? Let's go through that and also how they interrelate to each other which I think should be pretty useful for you, so stick around.



As mentioned, we're talking about programmer roles.


I'm gonna use the term programmer and developer interchangeably in this post, but technically, programming is more coding, so you're pretty well coding all day whereas a developer is involved more in the development of something so you're basically in all aspects which can include coding. Now that's a generalization because some companies will treat someone who's a developer purely as a coder or a programmer. Point of mind is I'm just basically saying they're both the same for this video.


Let's start with a junior developer, also known as a entry-level developer. Mostly, because this is your first job, you'll be doing a lot of learning. You will be learning in all roles. Even when you get to a senior developer role or a team lead role, you still do a lot of learning. That's just part of programming. But when you're starting out as a junior developer, you'll really be focusing a lot on learning, especially in the first few months of starting in your job.


Companies typically hire junior developers as a long-term investment. They realize quite correctly that the first few months, maybe as long as six months, you aren't gonna be able to contribute a lot in terms of code because you're learning. Of course, a junior developer gets paid less so less responsibilities as well. The company's aware of that and is treating it as a long-term investment. That's why often it's a lot easier to get your first programming job as a junior developer because, of course, you don't need that experience and that's what you're getting this job for, to get that experience.


The types of things you'll be doing is you'll be learning about the code base, the systems and programs, projects that are part of that company. That's where you'll be learning all about. You'll be learning about the team, how to interrelate with the team, as I said, the code base, but even things like how to act in meetings.


For example, (depending the development methodology that's employed in the company), you might have to get up once a week or even once a day with a quick team meeting to talk about what you did the previous day. So you're needing to start engaging with the team and getting up at meetings, talking about yourself and talking about what you're doing, what you're learning, and so on. That's not always a daily thing. Sometimes it could be a weekly thing or even a monthly thing. The point is these are the sorts of things you'll be learning as a junior developer and how you interrelate to the team and again, the code base. You can read my post about junior developers here and you'll be able to find out more information about the typical duties that a junior developer would actually go through.


Let's move on now to the next role, which is the developer. In other words, we've removed the word junior from a developer and you're now no longer an entry-level programmer, you've moved up in the ranks. Now, there are few ways that this can happen. The obvious one is it's just gonna happen automatically with experience. You start out as a junior developer and as you get more skills or build more skills and get more experience and you're no longer a junior, you're starting to contribute more to the team. Secondly, you could get a promotion. It could be some reason that you've excelled, you've done really well (hopefully, that is the case), and they'll put you into a more senior position and giving you some more responsibility. So it's just a great way to remove the word junior from your title.


In terms of how long that takes, that's completely reliant on you and the company. Some people are junior developers for two months, some for two or three years. It really just depends on the size of the company and the sorts of things that you're doing. I wouldn't be worried too much about that, moving from junior to developer. The obvious reason you wanna do that is probably as you're seen as someone who's got more skills and experience, most likely, you're gonna have an increase in salary. So that's a good reason to do it.


At this point in time, as a developer, and you're no longer an entry-level or a junior developer, you now understand the systems that are working with the company. You can code a lot better than you could before, you're contributing a lot more, you've got more responsibility, and perhaps you've got write access to the code base. So you can sow to the repositories so you can start writing and contributing code and basically, you're more heavily relied upon than you were as a junior developer. Because of that, you make now much more than a junior developer because of this knowledge - these knowledge areas if you will - or the experience and skills that you've actually gained since starting out as a junior developer.


It's important, obviously, to work through your skills all through this process, certainly from a junior developer, but even as a developer. Keep working on these skills and enhancing them because they're building you up and making you a more valuable commodity from the employer's point of view.


Next, we're talking about senior developer. This can also be a promotion or it can just be a title. I've known people who are just, "programmers" paid the same as other people, but they're seen as a senior developer because they've got more skills than a lot of the other developers out there. They might be particularly good with a programming language or they might just have a more of a detailed understanding of the code base. They also might just be able to answer a lot of other people's questions and it could be they've just been there the longest.


I've seen developers who've been at the same organisation when I've come in as a contract programmer who've worked there full-time for 20 years, so obviously, they've got a huge amount of knowledge that they've obtained over those 20 years, and they've moved into a senior role, either with a paid promotion or just in title. Some good signs that you're a senior developer is if other programmers are coming to you for advice. They're asking lots of questions about how to do something or, questions like "Will this work?" and things of that nature. That's probably a good sign that you're a senior developer.


Another thing that a senior developer would do is you'd be mentoring junior developers. For example, if a junior developer started with that company, they might come and sit with you for the first week or two weeks to learn some of the ropes and you might be the person who's going to help them to learn the basics about the systems and so forth. That's the sort of thing you do and then again, in general, a senior developer starts working on more things. They've got more responsibility than a junior developer, sometimes a lot more responsibility, and they've just got that real-world knowledge and knowledge of the code base from the company because of the skills and so forth that they've actually got. In essence, you probably know the code base a lot better than a lot of the other programmers and you're probably more skilled in the programming language of choice for that company than a lot of the other developers on the team.


Next, we're talking about the team leader. The team lead or the team leader, in general, manages the programming development team. They would often be tasked with making the final decision on technical problems. So there could be, for example, technical meetings where the programmers are all contributing and trying to figure out a solution, you know, strategy, the architecture of a particular solution. Well, after going through all that and getting people's opinions and talking about it, often, the team lead will be the person who either comes up with the idea, the recommended idea, or will say, "Okay, I looked at these. In my opinion, we need to do this. We're gonna go this direction", and because they've got the skills, they're able to do that. They've got good knowledge of architecture, of architecting systems and they know the right way forward. They're really the people that you depend upon to really be able to push through and make the right decisions.


Another role for the team lead is to protect the team from the users. I know that sounds funny, but basically, what I'm saying is they've often got the skills to communicate technically and non-technically. In other words, they can talk with the senior programmers all the way down to junior programmers and because they've actually got those skills, they've probably risen up in the ranks.


They're really good programmers in their own rights but they're now more of a management role so they're actually looking after, as I mentioned, the architecture of the system. They are making sure things are working, making those final decisions, but also talking to the team, the technical side of things, the nontechnical side as well, being able to engage and talk to users and for them to understand what they're saying. In other words, they are able to speak in a way that actually makes sense to people. I've got another post about that, about communication skills and how it's important as you're building your career that you learn that so check out that post here as well to make sure you're learning the right communication skills.


All right, so the tech lead in general, are expert programmers but often, they spend less time doing the coding now because they're focusing more on managing the team and making those sort of high-level decisions. They've got a lot more responsibility than a senior developer (they've probably been a senior developer for a while) and they've moved up into that next role and now, they've got usually massive responsibility and really, the buck stops with them so they really might need to make sure they have a good understanding of the entire system.


That's it for today. I hope that was valuable. See you in the next post. You made it to the end of this blog post. Thank you for reading. If you've got any questions, feel free to leave a comment and I'll get back to you.