Nowadays we are very comfortable using our credit cards to buy things that we need, and we must admit it made our lives a lot easier

We can buy online everything we need. It is just as far as a click of a button. We can now chat instantly, in a matter of seconds, which is a great achievement for the messaging industry. Sounds great, doesn't it?

But it wasn't always like this. We remember the days we used to go shopping in a real store, sending letters and receive the answer late. Traveling tickets used to be bought from the train stations, airports, and lots of effort was indeed needed.

Many programmers that passed the junior level, will encounter situations when they must review other developer's code. For some, these events are daily, while other programmers only do it if necessary or in special situations.

It is very possible that the reviewers have to spend more time trying to understand the code they are reading. Losing time in IT can lead to a significant amount of effort required, overtime schedule only to complete the review so it can be shipped to production.

Furthermore, we all know the time is money, so a lot of financial resources are lost in the process of reviewing bad code, code that is not readable.

These are the top 3 tips.

1.COMMENTING

Even though there are many plugins to tell what's wrong with your code, it's not bad to rely on yourself sometimes and save the IDE from suggesting to you. Its a personal achievement, and it's healthy in the long run.

At the very beginning of your career, in order to achieve good reviews and feedback, you are strongly advised to use comments in your code so you can easily remember what your code was meant to do.

This will not only save time when you're trying to remember what you wrote but it makes it easier for reviewers. Yet, it is nor recommended to have a comment every 5 lines of code. That will make your code even harder to read.

In other words, you should comment to make your and other's life easier. On the other hand, if you're a senior and use comments, then you're not probably a senior.

In order to demonstrate the power of commenting, let's see an example in the form with no comments.

And now let's see the same method, but placing a comment before its signature. The comment will tell the intended behavior for that method.

Comparing the two examples provided above, it is no doubt that the second is much more expressive, it gives an assurance that the code is doing what you're saying and it respects the requirement.

To that end, commenting is one of the powerful tips you can use if you're a beginner, it will definitely boost your speed and will end as a healthy journey where you only benefited from using commenting among your code.

2. Don't repeat yourself - DRY

In order to understand what's behind this software principle, let's look at the name itself. Don't repeat yourself. It is actually very simple, affirming that you should never write the same piece of code or logic among your program.

According to deviq.com, the Don't Repeat Yourself (DRY) the principle states that duplication in logic should be eliminated via abstraction; duplication in process should be eliminated via automation.

The purpose of a program is to be efficient and effective. If this principle is broken, not only more effort to build software is required but it also implies slowing the development process, time-wasting, and energy-consuming factors across the development teams, not to mention the delivery delays, testability difficulties, code length, and maintainability.

The code is not extensible anymore, becomes hard to maintain, and soon there is an immediate need for a brutal refactoring of the program. It requires more time for reviewers to read and understand your code, therefore more time allocated refactoring and testing updates.

In order to overcome this concern, you must pay attention to the structure of your code, analyze, understand, and discover code fragments that can be extracted to a method that can be reused across the program.

It will significantly decrease the amount of work and energy required for developing the software.

To illustrate this, the following image contains business logic that is repeated twice. Ii looks overwhelming, its too much code to read and not pleasant at all. The solution in the right section of the screen describes the actual desired behavior.

While the example may be simple, it is nonetheless harmful to the program when we use the same functionality over and over again by duplicating code, which is known as CPP ( Copy Paste Programming ).

Provided that, what would be the approach if one thing changes? Find and Replace? It could be an option, but its bad practice, and unorthodox.

Consider looking over your code twice, and make sure you deliver quality, not quantity. It is better to spend a little more time improving your program, instead of getting bad reviews and refactor requests which can lead to unproductive work.

3. Ask

This last one is not directly tied to the code but it is leading to writing better code.

The majority of junior developers try very hard to do things on their own. This is a very in-demand skill that recruiters chase.

Being able to learn on yourself, is probably the most valuable asset you can develop. You are going to benefit from it significantly in your career.

No wonder good programmers and people in general that gained this skill and continued to develop got high places, managers, leaders, and senior positions.

However, not all the time is recommended to push yourself to the limits. There may be times when you and the internet can not figure out a problem, or understand things. It is time to ask for help from your team lead or mentor.

A golden rule that most companies follow is that a programmer should spend as much time on a problem as needed, but no more than 2-3 hours. If the limit is reached, then it is time to ask for help from others.

This rule isn't just for juniors, this applies to everybody, middle or seniors. All of us do this. It is more productive, efficient and moreover it is an effective way to build things.

So, next time do not be afraid to ask for help. Go for it. You will never be seen as stupid or incompetent, instead, you're going to learn how to be a team player, listen to suggestions, and react.

All things considered, junior developers should not be frustrated with their results after the months but should be eager to learn the best practices used in the programming language they use. 

Good code is an asset. Good code is common-sense.