In my short engineering career, I got the opportunity to work with people of different levels of experience, from fresh out of college, to people with greater than 15 years of technical working history.

Here are a couple of traits I have seen with people who lack experience. This is not in any way a bad thing, everyone will get a chance to realize their mistakes and correct it.

I found these because I have made some of these mistakes in the past and when I saw other people doing it, I was able to experience déjà vu.

Keep in mind, someone showing one or more of these traits doesn't always mean ill experienced, it just gives a higher chance. Some times it means that they haven't learned from their past. Also, there will be outliers for sure. I am just listing down the common traits I have noticed.

Simplifying the code base

You may be having a code base which has been worked for a couple of years, but still when they start looking at the code, think the db, structure, and logic can be simplified, or they think the program itself is simple, current engineers just made it complex.

Most of the time, what will happen is, they lack the full understanding of the project - they will understand the intricacies when they work on the project for a couple of months.

Once they prematurely start simplifying, either reach the same level of understanding that you are or they may reach a worse code structure than what you are having right now.

Assuming that current team doesn't know better

This is especially common among fresh out of college engineers who learns a couple of new technologies and assume that the existing team is not up to date, informed about it.  It can be new frameworks it can be libraries.

With experience, you get to learn that everything doesn't need to be using the bleeding edge technology or bleeding edge framework. Also experience gives you better understanding of the newer things, and you'll be able to make a decision when it needs to be adopted.

Assuming that current team doesn't know the flaws

A team who actively worked on the project for a longer period of time, will be aware of most of the flaws in the system, but they don't want to fix everything right away because of certain reasons. A person coming from outside, might assume that these things were never came to notice of the team.

What experience gives you is, the understanding of priority of each flaw in the system. If you are running a program for 100 rows of data, you don't have to write a complex algorithm to handle millions of rows. A priority for that might be lower when several new important features or higher priority tasks need to be worked on.

Believing design choices are incorrect

Another common trait I have seen is blindly believing whatever design choices made are incorrect. It is also because of lack of working with wide variety of projects.

Not all project needs to have the same kind of structure/design that you have seen in the past.

Trying to apply familiar project structure

Each project can have its own structure, some projects can use functional structure, some can use object-oriented. Like that, people can use the same framework and can have different project structure.

Someone with lack of experience might assume that everything needs to be done the same way as he/she has worked in the past. This happens especially when they start reading the code and find that it is not similar to other projects they have worked on, assume this way is incorrect and starts converting into the form they have been doing in earlier projects.

Reading more code from a wide variety of projects help you to avoid making this mistake.

What you should do

Here are my suggestions on how to handle the situation when you are beginer and find that current design choices and code structure are in fact bad.

• Don't introduce your points in a confrontational way.
• Try to ask existing engineers what went into making a particular design decision.
• If something is bad, instead of blaming it, ask why this particular issue was missed, or ask whether it came into others notice in the past.
• Try to understand current teams point of view before making any judgments.
  
  

Icon Attribution: Teacher by glyph.faisalovers from the Noun Project