One of the many things you might be asking yourself when starting your software development career is:

“How do I REALLY contribute to my new team?”

This was one of the things that scared me when starting my first job as a junior developer. So I’ve decided to summarise the things I did that earned some praise from my manager and teammates.

When hiring junior developers, it is expected that there will be some learning and ramping up time. You will have to learn the processes, the codebase, and a bunch of other stuff.

But that doesn’t mean you can’t hit the ground running and make an impact with your new team from day 1. Follow these tips and you’ll do just that.

Take pride in your work

Let’s look at a picture.

Credit: Pedro Campos

Now you’re probably asking, “Why are you showing me a photo of some old Coke-Cola cans?”

Which is a fair point. But what if I told you that this was actually an oil painting? Yes, this hyper-realistic painting is the work of Pedro Campos (see a link to his site above). You may or may not be into art, but you have to admit this is pretty cool (my phone doesn’t even take pictures this clear).

But still, what’s the point? My point is you can tell just how much pride Pedro takes in his work. Every intricate little detail is covered. Even though this may only seem like a bunch of old cans, he has turned it into something amazing.

This is the approach you should take with your work. No matter how small or simple a task is, give it your all, and leave no stone unturned.

This is one of the best ways to make a good impression with your team. Write readable code. Test your code. Leave comments where necessary. Cover all the edge cases. Put 110% into everything you do. Doing this makes your teammates think “Wow, this person knows their stuff and cares about what they are doing”.

Know how to ask for help

As I mentioned in my article, ace your first year as a junior developer, asking questions when you are stuck is a good habit to get into. Although, knowing how to ask questions can make all the difference. If you say “Hey, I’m stuck can you help me?”, it makes it a bit harder for the seniors in the team to help you. In contrast, saying:

“Hey, I’m working on this task, and I’m trying to do something, but I am getting an error in this function at this line. The error message is confusing, have you any ideas?”

The more information you can give, the easier it will be for others to help. You will also show that you understand what you are trying to do, and have simply hit a wall.

As a side note, make sure to give your best shot at overcoming the issue you have come across. Do a quick Google search and have a look at other parts of the codebase that solves a similar problem. If you still are stuck after doing some investigating, go ahead and ask for help.


“The quieter you become, the more you can hear.”

There is a time to speak, and there is a time to listen. As a junior developer, when a senior developer is explaining something to you, or your team is discussing things, that is the time to listen and take it all in.

Ask questions if you’re not sure about what is being said, but try to refrain from interrupting or talking over somebody else. Nobody likes that.

If need be, write things down. It leaves a great impression when a junior developer only has to hear things once, without having to be repeatedly given the same information a few times. Plus, it’s one less time you’ll have to ask!

Some great note taking apps I personally use are (all completely free to use):

Help Others

Found yourself at a loose end after finishing a task? Or waiting for your code to be reviewed/tested? You could spend that precious downtime scrolling Facebook, or you could find ways to help your team.

Don’t be afraid to turn to your team and say,

“I have a bit of downtime if anyone needs help with anything?”

Even if no one needs any help, the team will appreciate that you asked. Now you can browse social media guilt free! Hurray!

Communicate Well

Communication is important, which is why I’ve opened this section with a picture of two really stern people sitting at a laptop.

You’ll be working with managers, teammates (some remote!), end users and the like. So it’s important to be able to communicate well.

As a junior developer, there is often that thought that speaking more = more information. This, in fact, is not the case. Ask my old team lead. “Chris, you’re waffling again!” felt like his catchphrase at times.

For example, you will likely have a daily standup or some sort of progress meeting. So instead of waffling, try being as concise as you can:

“I am working on some task, so far I have managed to complete this part, so I have to write some tests. I should be finished in by the end of the day.”

Being able to communicate your progress keeps your team up to date. Not to mention speaking with clarity and confidence will instill a sense of assurance with the rest of your team.

BONUS TIP: Prepare what you are going to say in advance, and write it down. Don’t be afraid to reference this when you are talking!

Seek feedback often

Seeking feedback early is a good way to reduce the amount of wasted work you could end up doing.

There is nothing wrong with waiting until the code review phase to get feedback on your work. But this may mean you have to go back over and change your hard work (my first code review had me changing my entire solution!).

A more proactive approach that will allow you to be more efficient in completing tasks, is to get feedback on your code before you even write any code.

Wait, what?

How do you do this? You create a design first. This can be as simple as writing out the functions you will need, the general flow of the program, or writing out some steps on paper.

You can then ask the senior developers on your team “Can you run over this design with me? to make sure I’m going in the right direction”.

This achieves 3 things

  • You will know early in the process if your thought process is correct
  • You will show that you can think about your code before going in guns blazing and writing code. This is an impressive trait to have.
  • You can be quite certain that your code will be correct when it comes time for it to be code review. Changes will be minor and it will speed things up.

Own up to mistakes

Let’s face it, everyone makes mistakes. I have many years experience and I still make mistakes. I spoke with a talented guy with 15 years experience recently who had made a bad design decision and it cost his team weeks of rework. So mistakes will happen.

The important thing is that we own up to them when it happens.

Why is this important? It’s not so you can be thrown into the town square and egged by your teammates (that would suck). It’s so that the team can rectify any issues and ensure it doesn’t happen again.

When I was a junior developer I changed a configuration property on the integration environment as part of a task I had. I accidentally got the property name wrong and this caused the environment to down. The team frantically tried to figure out what happened.

I felt bad, and thought “damn, they’re going to laugh at me and think I’m a fool!”. But I spoke up and said, “I changed this property on the environment, is that what it could be?”

The senior developers said, “Ah, possibly, can we get a look at what you did?”

I showed them the changes I made, and we rectified the problem in no time. In the end, there was no harm done. Sure, I got a bit of playful stick from everyone, but I gained a lot of respect and helped solve the problem by owning up to the error I had made.


I good way to show your proactiveness and willingness to contribute is to volunteer for tasks. When your manager or team lead asks for volunteers to do a task, put your hand up and say you’ll do it, if you think it’s a task you can do it.

Not only does this show that you are enthusiastic, but this gives you the opportunity to learn the codebase.

For example, if you are investigating a bug, you’ll have to dive into that part of the code and understand how it works before being able to solve the problem at hand.

Not to mention the kudos from team members and management you’ll get for fixing bugs!

Bring donuts

Yes, it is a well-known fact that donuts and buns have powered every major software project since the beginning of time. Ok, maybe not, but they taste good and are a nice gesture. If you really want to be an awesome teammate, get to know your team! Be friendly, be positive, and always wear a smile. You’ll be surprised at how the simple things like that can have an effect.

Give 110%

Remember to give your all, show how willing you are to learn, and be passionate, and you’ll make a lasting impression on your teammates.

Thanks for reading!

I’m currently creating a bunch of guides, articles, and video courses to help you along your journey into web development. If you would like to be a part of it, make sure to join the mailing list over at!