I have been working on redoing the roadmaps – splitting the skillset based on the seniority levels to make them easier to follow and not scare away the new developers and I thought it would be a good idea to reiterate and have a separate article on what I think of different seniority roles.
I have seen many organizations decide the seniority of developers by giving more significance to the years of experience than they should. I have seen developers labeled "Junior" doing the work of Senior Developers and I have seen "Lead" developers who weren't even qualified to be called "Senior".
You can judge the seniority of a developer by looking at their perception of work, how they interact with the peers and how they approach problems. We discuss these three key factors in detail for each of the seniority levels below.
### Different Seniority Titles
Different organizations might have different seniority titles but they mainly fall into three categories
* Junior Developer
* Mid Level Developer
* Senior Developer
### Junior Developer
Junior developers are normally fresh graduates and either they don't have or they have a minimal industry experience. Not only they have weak coding skills but also there are a few other things that give Junior developers away:
* Their main mantra is "making it work" without giving much attention to how the solution is achieved. To them, a working software and good software are equivalent.
* Because they don't have industry experience, they have a tunnel vision, they need supervision and continuous guidance to be an effective member of the team.
* When given a problem, they often try to fix just the current problem a.k.a. fix the symptoms instead of fixing the root problem.
* Most of the Junior developers just try to live up to the role and might leave work for a senior developer instead of at-least trying to take a stab at something.
* They don't try to learn about the business side of the company and don't realize how management / sales / marketing / etc think and they don't realize how much rework, wasted effort, and end-user aggravation could be saved by getting to know the business domain.
* They might be afraid to work on an unfamiliar codebase.
* They don't take or are afraid to take initiatives.
* They don't participate in the discussions.
Being a Junior developer in the team is not necessarily a bad thing; since you are just starting, you are not expected to be a know-it-all person, however it is your responsibility to learn, gain experience, not get stuck with the "Junior" title and improve yourself. Here are a few tips for Junior developers to help move up the ladder of seniority:
* All sorts of problems can be solved, if you work on them long enough. Do not give up if Stack Overflow doesn't have an answer.
* When given a problem to solve, try to identify the root cause and fix that instead of fixing the symptoms. And remember, not being able to reproduce means not solved.
* Understand that code is often ugly and weird for a reason other than incompetence. Learning to live with and thrive with legacy code is a great skill. Never assume anybody is stupid. Instead, figure out how these intelligent, well-intentioned and experienced people have come to a decision which is stupid now.
* Try to turn any feelings of inadequacy or imposter syndrome into energy to push yourself forward and increase your skills and knowledge.
* It's okay to not know things. You don't need to be ashamed of not knowing things already. Ask however many questions that would allow you to work effectively.
* Read a lot of code, not just code in the projects you work on, but reference/framework source code, open source. Perhaps even ask a subreddit for the language/tool about good examples to learn from.
