DEV Community

Cover image for Avoid These Mistakes as a Junior Developer
yusufcodes
yusufcodes

Posted on

Avoid These Mistakes as a Junior Developer

Introduction πŸ‘‹πŸ½

Last year, I took my first steps into the industry as a part-time Junior Developer whilst completing my Computer Science degree. In this post, I want to reflect on some mistakes I’ve made, hoping to help other developers who are early into their careers.

Not asking for help 😨

As an early-career developer, it is so easy to feel like you need to know everything. You feel like you need to prove yourself to your team, and prove that you belong in the role you've landed, so you want to take everything on without asking for help. However, the honest truth is everyone needs a helping hand at some point, no matter what seniority level they're at.

As a junior, your colleagues will not expect you to know how to do everything. They are there to help you, and have probably faced the issues you are facing before, so you will save a lot of time by reaching out for help! Asking for help is not a reflection of your ability to do your job. So, when you find yourself struggling, make sure to reach out to someone for help!

Asking for help in the wrong way πŸ€”

The time of your colleagues is precious, so you want to make sure you've tried everything you can with your skills and knowledge with any problems you face. An example of this is searching online for solutions, or consulting the documentation for the technologies you are working with. After doing some research, you are in a better position to ask for help. See the following example of asking for help:

OK Approach: "Hi, I am struggling with Problem X. Any ideas what to do?"

Better Approach: "Hi, I am struggling with Problem X. I have read this article (link), and had a look at this tutorial (link), and tried applying these, but I am still having problems. Can anyone guide me further?"

Explaining what you have already tried can save time for your colleagues, and can help them identify whether your approaches were correct in the first place. Take the time to look into your problems a little further, and you may be able to fix things yourself! (And, if not, you will have a much better way of approaching your colleagues).

Avoiding tasks outside of your comfort zone πŸ™…πŸ½β€β™‚οΈ

Alright, hear me out with this one. I'm not saying you must take on the most difficult ticket on day one. However, as you build up in knowledge and confidence, you will be in a better position to attempt harder tasks. You can use guidance from your management to help you move onto harder tasks. If you stick with the same tasks you always do, without trying to move up in complexity, it will take longer to advance as a developer. Your employer will favour your willingness to try harder things, and in the end it will only help you grow as a developer - so keep pushing yourself! (But not too hard, burnout is real πŸ˜…).

Not breaking down big tasks ✍🏽

When you first get started as a dev, it can be easy to just follow a single ticket through without thinking about the magnitude of the task. However, if you try and think about the individual blocks of tasks you need to carry out, you could break down a larger task into smaller ones.

The benefit of this is it will help you work in a more Agile way, allowing you to deliver smaller chunks of work in a quicker timeframe. This can help you receive feedback from your colleagues much sooner, helping you deliver the best piece of software in a better timeframe.

Putting yourself down πŸ˜”

If there is anything I excel at, it is putting myself down. When I make progress with a task, I will dismiss it two seconds later and identify what I must do next. This is not a great way to work, because you will never feel satisfied with the progress you're making at such an early stage of your career. It may seem small in the moment, but these little wins will contribute to larger successes as you work on more tasks.

Conclusion βœ…

These were just a few little mistakes I've identified in myself as an early-career developer. I hope I can continue identifying and learning from my mistakes, and that these are useful for any other early-career developers out there!

Can you think of any other mistakes to avoid? Let's generate a discussion in the comments below πŸ€”!

Top comments (0)