@ -15,10 +15,11 @@ Different organizations might have different seniority titles but they mainly fa
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.
* 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. They usually require very specific and structured directions to achieve something.
* 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.
* Over engineering is a major problem, often leading to fragility and bugs.
* They might be afraid to work on an unfamiliar codebase.
* They are afraid to take initiatives.
* They don't participate in the team discussions.
@ -40,6 +41,7 @@ Being a Junior developer in the team is not necessarily a bad thing; since you a
* Don't just blindly follow the advice of "experts", take it with a grain of salt.
* If you are asked to provide estimate for some work, do not give an answer unless you have all the details to make a reasonable estimate. If you are forced to do that then pad it 2x or more depending upon how much you don't know about what needs to be done for the task to be marked 'done'.
* Take some time to learn how to use a debugger. Debuggers areb quite beneficial when navigating new, undocumented or poorly documented codebase, or to debug weird issues.
* No one likes know-it-all, be honest, confident and humble.
* Avoid saying "it works on my machine" -- yes, I have heard that a lot.
* Try to turn any feelings of inadequacy or imposter syndrome into energy to push yourself forward and increase your skills and knowledge.
@ -50,5 +52,18 @@ Intermediate developers are more competent than the Junior developer, they start
Without supervision, they might delay the execution while trying to "do things properly". They don't know when to make tradeoffs and they still don't know when to be dogmatic and when to be pragmatic. They can easily become attached to their solution, become myopic, and be unable to take feedback.
Mid level developers are quite common, most of the organizations wrongly label them as "Senior Developers". However they need further mentoring in order to become Senior Developers. Next section describes the responsibilities of a senior developer and how you can become one.
Mid level developers are quite common, most of the organizations wrongly label them as "Senior Developers". However they need further mentoring in order to become Senior Developers. Next section describes the responsibilities of a senior developer and how you can become one.
### Senior Developers
Senior developers are the next level after the Mid level developers. They are the people who can get things done on their own without any supervision and without creating any issues down the road. They are more mature, have gained experience by delivering both good and bad software in the past and have learned from it - they know how to be pragmatic. Here is the list of things that are normally expected of a Senior Developer:
* With their past experiences, mistakes made, issues faced from over-designed or under-designed softwares, they can foresee the problems and persuade the direction of the codebase or the architecture.
* They are pragmatic in the execution. They can make the tradeoffs when required, and they know why. They know where to be dogmatic and where to be pragmatic.
* They have a good picture of the field, know what the best tool for the job is in most cases (even if they don't know the tool). They have the innate ability to pickup a new tool / language / paradigm etc in order to solve a problem that requires it.
* They are aware they're on a team. They view it as a part of their responsibility to mentor others. This can range from pair programming with junior devs, to taking unglorious tasks of writing docs or tests or whatever else needs to be done.
* They have a deep understanding of the domain - they know about the business side of the company and realize how management / sales / marketing / etc think and benefit from their knowledge of the business domain during the development.
* They don't make empty complains, they make judgments based on the empirical evidence and they have suggestions for solutions.
* They think much more than the code - they know that their job is providing solutions to the problems and not writing code.
* They have the ability to take on large, ill-defined problems, define them, break them up, and execute the pieces. A senior developer can take something big and abstract and run with it. They will come up with a few options, discuss them with the team and implement them.
* They have respect for the code that was written before them. They are generous when passing judgement on the architecture or the design decisions made in the codebase. Approach inheriting legacy code with an "opportunity mindset" rather than a complaining one.
* They know how to give feedback without hurting anyone.