The secret is more in what you should not do rather than in things you should do. And the easiest way to appear like an amateur is to do these basic mistakes:

  • not testing your code before submitting for review
  • not following the existing architecture
  • not following naming conventions in the code
  • not using the same code style
  • not splitting your changes in smaller git commits
  • making the same mistakes over and over again

Depending on your level of experience, some of these may seem very obvious.

And they are…

BUT

So many junior developers are doing these mistakes, it’s not even funny.

I also did couple of these when I was starting out. It’s completely normal.

HOWEVER

If you want to appear as a professional ASAP – stop doing these mistakes and your colleagues will take you more seriously.

And it can even affect your salary.

Test Before You Submit

When a senior developers are checking your code, they expect some level of seriousness from your side.

If they notice during the code review that there is no way this code works then you look very bad. Because then they know you haven’t even run the code and went through the main scenario.

And this wastes everybody’s time – especially senior developer’s.

BONUS TIP

Always ask yourself: how can I break this? What edge cases and weird scenarios I haven’t considered?

If you always look for ways to break your code, and you only submit for review when you cannot find anything wrong – then you’ll be amazed at the code quality you’re able to produce without learning anything new.

And your teammates will notice that too.

Existing Architecture

It is not very often you design an entire system from scratch. Usually, you’re added to the team with existing architecture.

When you’re tasked with adding a new feature – just follow the existing architecture:

  • don’t create files in random places
  • don’t put your code in random places

Look where similar code resides and place your new code there as well.

This seems so basic but I’ve seen it done more than once so I have to mention it.

If you have senior developers on the team, they won’t allow you to merge this code. And if you’re alone then you’re making some serious technical debt damage to the codebase.

Just stop it.

Naming Conventions

The point of working in a team is to have multiple people working as one.

Multiplying their forces.

The whole being stronger than the sum of its parts.

BUT

That is never going to happen if all developers are running around in whatever direction they choose.

If there is a certain way variable and function names are written – then copy that style as well. Even if this is not your preferred style.

The point is in having the code look uniform. And that will be achieved if it’s written in the same way (same style).

So just do it.

Code Style

This one is fairly often.

Let’s say you see entire JavaScript code is written in a proper immutable way:

const allNames = users.map(u => u.name);

But then someone comes along and introduces the very first for loop in an entire code:

const allNames = [];
for (let i = 0; i < allNames.length; i++) {
  const newName = allNames[i].name;
  allNames.push(newName);
}

This will look super amateurish and if you do this, everybody will know you’re a noob.

So follow the same code style that is used throughout the codebase if you want to look like a professional developer.

Git Commits

Creating huge pull requests is never good.

The only exception is when a feature is simply too complex and it cannot be smaller.

BUT

If you do it all in a single (or just a couple of) commits with a huge number of changes – it’s going to be a hell to review that code.

It’s going to be tiresome. Your teammates who are reviewing your code aren’t going to like it one bit.

And sometimes they will ask you to do a new PR (pull request) with smaller commits.

Those commits need to be split into logical sections that are easy to follow. And this will allow reviewers to follow your way of thinking and do a better review in less time and with less mental effort.

So don’t unnecessarily make things hard on your teammates.

Be a professional.

Repeating Mistakes

This one is by far the worst.

It can include any of the mistakes mentioned before – just done repeatedy.

For example, a senior developer tells you not to do everything in one commit.

And you do it anyways.

And again and again.

Would they want to work with you?

They’re probably thinking what’s wrong with you when you can’t follow a simple instruction.

Because it’s not like you haven’t noticed you jammed your entire code in a single commit (again).

Be A Professional

If you refrain from doing the mistakes mentioned above, then you will appear like a much more experienced developer.

And your colleagues will notice.

Which will impact your performance review as well and potentially get you a higher salary as well.

So it pays off to be a professional.

P.S. -> read this article if you want to double your salary