@ -26,9 +26,9 @@ Junior developers are normally fresh graduates and either they don't have or the
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:
* 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.
* All sorts of problems can be solved, if you work on them long enough. Do not give up if Stack Overflow or an issue on GitHub doesn't have an answer. Saying "I am stuck, but I have tried X, Y and Z. Do you have any pointers?" is much better than saying "this is beyond me".
* Avoid what is known as ["Somebody Else's Problem Field"](https://en.wikipedia.org/wiki/Somebody_else%27s_problem) behavior
* Do the personal side-projects, share them with people, contribute to the opensource. Reach out to people for help - you will be surprised how much support you can get from the community. I still remember my first opensource project on GitHub from around 6 years ago which was a small PHP script (a library) that fetched details for a given address from Google's Geocoding API – the codebase was super messy, it did not have any tests, did not have any linters or sniffers, and it did not have any CI because I didn't know about any of this at that time. I am not sure how but one kind soul somehow found the project, forked it, refactored it, "modernized" it, added linting, code sniffing, added CI and opened the pull request. This one pull request taught me so many things that I might have never learned that fast on my own because I was still at college, working for a small service based company and doing just small websites all on my own without knowing what is right and what is not. This one PR on GitHub was my introduction to opensource and I owe everything to that.
* Try to turn any feelings of inadequacy or imposter syndrome into energy to push yourself forward and increase your skills and knowledge.
* All sorts of problems can be solved, if you work on them long enough. Do not give up if Stack Overflow or an issue on GitHub 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. It is solved when you understand why it occurred and why it no longer does.
* Have respect for the code that was written before you. Be generous when passing judgement on the architecture or the design decisions made in the codebase. 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. Approach inheriting legacy code with an "opportunity mindset" rather than a complaining one.
* 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.
@ -38,5 +38,17 @@ Being a Junior developer in the team is not necessarily a bad thing; since you a
* Learn to communicate effectively - soft skills matter. Learn how to write good emails, how to present your work, how to phrase your questions in a thoughtful manner.
* Sit with the senior developers, watch them work, find a mentor. Get a hold of your ego and be humble enough to take lessons from experienced people.
* 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.
* 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.
### Mid Level Developers
Next level after the Junior developer is Mid Level developers. They are technically stronger than the Junior developers and can work with minimal to no supervision they still have some of the issues to address in order to jump to the Senior level.
Intermediate developers are more competent than the Junior developer, they start to see the flaws in their old codebase, they gain the knowledge but they get trapped into the next chain i.e. messing things up while trying to do them "the right way" e.g. hasty abstractions, overuse or un-necessary usage of Design Patterns -- they may be able to provide solution faster than the Junior developers but the solution might put you into another rabbit-hole in the long run.
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.
Kamran Ahmed
5 years ago