Are you a Jr dev trying to get better?
I have been working with a lot of Jr devs and through the time I identified 10 common errors they made.
Read them and let me know if you identify with some of them. But remember
My goal with this list is to help you become better than you were yesterday.
1. Misreading errors.
This seems to be pretty obvious but it's wa...y to frequent that a dev reaches to me asking for help because they are stuck ...and when I see the error my immediate question is
Did you read carefully the error? If so what's the error about?
For instance, simple errors (😅) like:
Of course, there are times when the error message is not clear and it's ok to ask for help, but please read and try to understand what's failing.
2. Write code as soon as possible.
When you're going to work on the next task, check if you start coding ASAP, because that's something you should improve. There are many things you should do before hand to make sure you deliver what's expected, for instance:
- Read and understand the scope of the ticket.
- Clarify ambiguity with your Product Owner/Team Lead.
- Look for areas in the app that might be impacted or at least you need to test.
- Etc
3. Misunderstanding of the ticket's scope
This can go in two ways:
- Un-fulfillment of all acceptance criteria. In other words, doing less than what was expected.
- Adding things beyond the scope of the ticket. Doing more than needed.
4. Mixing new code with refactors.
Just with experience you'd know how risky is to introduce new code while refactoring the same area.
Aim to deliver things separate and if you want to refactor some code because it's awful or any other reason, make sure you know the code well or at least have a decent set of tests before doing the refactor.
5. Not taking time to learn your tech stack.
If you're new in a company, it's maybe your first job, you want impress your coworkers, so you do your best to deliver as many tickets as possible, but in the long run you aren't going to increase your velocity and you'd be stuck with silly issues because you didn't learn the stack enough.
Here is one the best quotes that illustrate the idea.
Give me six hours to chop down a tree and I will spend the first four sharpening the axe. — Abraham Lincoln
Take time to learn your stack, if you work with React, read the documentation & understand what's going on, learn Javascript well, take courses, ...keep learning!.
Eventually something that could take you a couple of days to complete, you'd be able to do it in a matter of hours.
6. Focus on delivery not on quality.
Usually the devs I worked with try to finish the tickets ASAP and grab the next one. but I always tell them:
I prefer if you deliver one ticket with zero or few bugs instead of delivering 10 tickets full of bugs.
7. Not asking questions
First at all, if you work on a place where you don't feel welcome to ask questions you should tell your manager or move to a different place.
A lot of times I get into a meeting with the team, we discuss a new feature and we ask if someone have any questions and the room goes quiet, so we finish the meeting.
But later on and countless times Jr developers ask me directly questions of things they didn't understand during the meeting.
So I go ahead and explain to them that asking those same questions during the meeting is more valuable because we can consider even more things and that their input is always welcome.
8. Getting stuck
This is related to the previous one, if you're stuck with an issue, it's better to raise your hand and ask for help rather than getting block the entire day.
But as I said in point #1, make sure you read carefully the error and if you don't have a clue of how to solve it, ask for help.
9. Having the same errors all the time.
If you have an issue and ask for help, make sure you learn what happen, why it happened and how to fix it.
Because the next time you face the issue, you can solve it in own, and even better, eventually you can help teach someone what happen, why it happened and how to solve it 🔥.
10. Quality is a QA department responsability.
It's quite common that developers rely on the QA to guarantee that we aren't introducing bugs or breaking the app.
If you get rid of that mindset, and start caring about delivering features with high quality before they reach the QA person, you'd be miles ahead of the others.
Conclusion
You should be honest and assess yourself. Don't feel ashamed if you have identified with one, two or all of them.
Everybody was a Jr dev at some point and I have to admit, I got better at some of them when I get into Senior positions.
The key is to identify them and be better than yesterday ❤️.
I hope you enjoyed! Did you identify with some of them? Let me know in the comments
Also you can follow me on twitter where I share more tips to become a better dev.
Top comments (1)
Nice article, perhaps, another mistake is not take care of what areas can affect (dependencies ) potential changes in existing components—more in software where there is a lack of good automation testing.