Based on my experience both as a junior dev and as someones with some experience managing them, here of some things I think junior devs should keep in mind for greater success.
Starting off can be tough, you may suffer from imposter syndrome or your tasks can be overwhelming. It is important to lead on your senior devs to help point you in the right direction. If you are unclear or something or completely lost it is important to communicate it as soon as possible. A good company should anticipate this for junior devs and provide mentors to guide you.
While you are encouraged to reach out for help keep in mind that other developers do have their own work. If your first response to every error or problem is to run for help, it can get bothersome for your seniors really quickly. You should definitely try to hash it out on your own, common errors are very googleable and it is likely you'll find an answer on stack overflow. Then if that doesn't work you can know more about the problem when you finally ask for help.
Instead of saying:
- My code is broken please help.
You can say:
- Hi I'm trying to use package x to do y but I got this error and stack overflow says to z but it's not quite there yet. Have you seen this before?
When starting off, you are mostly aiming to simply get the code to work. However, there are more aspects to quality software such as design, reasonable naming and readability. It's important to get feedback to seek opportunities for improvement. You can ask questions such as "Is what I'm doing here makes sense?", "can this be done better/cleaner?".
If you are working with other junior devs you may be tempted to show them up in order to stand out. However, this attitude is not in the best interest of the product as a whole. Rather you can gain more points by looking out for your co-workers, helping when you can and building trust. This would show that you are thinking about the success of the team as a whole and are probably able to take on more responsibility.
When you find yourself with extra time on your hands you are presented with an opportunity to show initiative. While I'm not saying to just run off and push code to production, instead, consider what is is a wider picture of the task you just completed. Think about how other components relate to your work, maybe you can work on making that interface more convenient for others or even adding some documentation. This will indicate that you are thinking about the work at a higher scope than was initially assigned.
Very often we may make assumptions when communicating as tech people. This ambiguity can result in a deliverable not quite meeting the expectations. Your idea of 'done' may differ from what a senior dev is looking for. To help with this it is important use project management tools like jira, trello, etc to document exactly what is required. Concepts like user stories and acceptance tests are good for fleshing out these details.
You can also just simply ask "What exactly you should be able to do if this task is to be considered completed?"
For example, your deliverable may require:
- Its own unit tests
- Deployment to a staging environment
- Integrated into a branch and passed all tests
- Need to be runnable on the command line taking input from a file
- Properly documented and staged in its own repository.
Seeking clarity on this can save you from looking like you half-assed task when you simply didn't know what was required.
These are just my thoughts on what helped me and what I'd like to see from developers that I work with. What other tips would you recommend?