Common Engineering mistakes new Software developers to make: Part-1

Photo by Marvin Meyer on Unsplash

As new software developers, people tend to think of themselves just as a developer and often forget about the engineering aspect of their profession. This may seem like a trivial thing to forget but in the long run, improving both the development and engineering aspect is a must to become a good software developer. Software development involves writing tons of code while engineering is the part where you plan out how you’ll structure and organize the code so that it is scalable, extensible, and maintainable in long run.
Code written by fresh software developers is often focused just to solve the development problem and is rarely scalable or maintainable in long run. A lot of developers have a tough time understanding their own code which they would have written a month back which does not scale well when they start working in a team. In a team often others stumble upon your code when they have to use it or refactor it. It would be a big hassle if you have to explain what you have written to someone new every time such a situation arises. Thus when working in a team with senior engineers who review your code new developers often end up with multiple comments and requested changes on their review. Trust me I have been there, my PR once had around 40+ comments on Github when I started working.

I have compiled a list of common mistakes new developers make through my experience of making them and seeing others make them when reviewing their PRs.

Mistake 1 - Most widespread mistake

Poorly naming variables, functions, or any such identifiers.

“Inevitably, code comments become lies over time. In practice, few people update comments when things change. Strive to make your code readable and self-documenting through good naming practices and known programming style.”

Source:- https://opensource.com/article/17/5/30-best-practices-software-development-and-testing

I cannot stress this enough but name your variables according to what they are being used for. I have seen some people using variable names like -

var a , final c, const b

this is not at all scalable when you work in a team. For example, suppose you have written a function that doubles a number only if it is even. There are two ways to write the code for that. First I will show you the bad way to name variables.

function double(a){
    if(a%2==0){
        return a*2;
    }else{
        return a;
    }
}

If someone else in the team wanted to use the same functionality and came upon this function they will take time to understand what it does. Since the variable and function names are very random. Now let's take a look at the good way to write the same function.

function doubleEvenNumber(number){
   const isEven = number % 2 == 0;
  
    if(isEven){
        return number*2;
    }else{
        return number;
    }
}

It is clear what the function does just by reading its name. If not then the rest of the variables are named such that just by skimming through the function others can understand what it does. Just think about writing a complex function with bad variable names. Every time you or someone else has to use it or refactor it they will have to decipher the function line by line before you can use it. This seems very basic but in the long run, it is very useful.

Mistake 2 - This takes time to correct

Forgetting important coding principles which ultimately leads to writing clean code.

If you read a lot of coding articles you must have come across the word “Clean code” multiple times but how many times do new developers follow the coding principle. I have come across this line so many times and have heard so many senior engineers repeat this.

It's easy to write code. It's challenging to write good code.

I am not going to go in-depth on how to write clean code or what coding principle one should follow but I will link some good articles that have helped me a lot.
https://mariocervera.com/the-essence-of-clean-code
https://www.callicoder.com/software-development-principles/

I will continue this in the second part of the article.