Knowing these behaviors will help you avoid making the same mistakes in your career as a programmer.

Work experience in the software industry is directly related to how long you have been in the industry. This is true to some extent, but the number of years you’ve been on the job doesn’t necessarily mean you’ve got the same number of years of experience. As the saying goes, “We think we’ve been on the job for ten years, but we’ve only got one year of experience, and we’ve just reused nine years.”

There are people who have been working for years, but they act like they’re just getting started. They learn little about the basics of software development. They grew in the first few years, but then they stagnated, and they didn’t understand why.

At the same time, I’ve worked with developers with only a few years of experience and they’ve shown incredible growth potential. They have a good work attitude and know how to avoid incompetent behavior.

Based on some of the habits of developers, it’s pretty obvious who’s more professional and who’s more amateur. Let’s take a closer look at seven ways that the amateur developer can make mistakes that every developer should take heed of, and that can hamper our careers.

1. Commit a lot of code at once

Have you ever run into someone who submitted so much code at once that you didn’t want to do a code review? Yes, that’s what unprofessional developers do. They will include changes to multiple modules in a single code review request and will urge you to review their code first. Yeah, can we wait? Back up. We still need to resolve code conflicts. This problem also exists among many senior development engineers, who do not commit during feature development and commit all changes only after the feature is complete, so any comments in the code review can cause a large number of changes.

When I encounter a code review request like this, the first thing I do is ask the submitter to break it up into smaller requests by functional module. I only review the first functional requirement in issues and then refer it back to the submitter. If I have time, I will link up with the submitter for a real-time code review.

What you can do:

  • Make small code submissions. A good practice: Commit your code every business day.
  • Do not commit code that does not compile or will cause the build to fail.

2. Poor code writing

Inexperienced developers don’t write beautiful code; they write messy code that is distributed throughout the code base.

When you try to read this kind of code, it feels like you’re in a maze. You gradually forget where you started, what you were looking for, and what the code accomplished.

Experienced developers know how code is designed. Unless the functionality to be developed is obvious, first write your understanding of the requirements on paper and draw a flowchart (a simplified specification specification) to get a complete idea of the code in your mind. Don’t start writing code until you’ve thoroughly figured out how to change it.

If you don’t follow the above rules, it will be painful to look back on your code. It can also be tricky to fix problems or add features later.

What you can do:

  • Before writing code, have a clear understanding of the functionality you are implementing. Ask as many questions as you can to get a clear understanding of the requirements.
  • Keep your code simple and elegant. Other team members can read the code and understand what it is intended to do.

3. Multitask

Inexperienced developers don’t know when to start a task, how to proceed, and when to finish. They try to multitask in parallel. They don’t know how to break down a large task into smaller chunks that make implementation easier.

When they receive a task, instead of checking in with their superiors, they start programming immediately, and during the task, they don’t communicate with their superiors about the progress of the task. Only when the task is complete will they give you feedback. Until then, you can only pray that the function they accomplish is the one you want.

Another sign of inexperienced developers is multitasking. They tend to work on multiple tasks at once, such as implementing multiple function points that are not closely related, solving production environment problems, assisting other colleagues, etc.

In the end, you don’t get effective output from them. Although their attitude and intentions were good, the results were disastrous for the entire team, wasting a lot of time and forcing the team to work day and night.

What you can do:

  • Focus on small tasks. Break the tasks you receive into small chunks, prioritize your requirements, and work on them in small chunks.
  • Take a task and finish it before starting a new one.

4. Arrogance

For inexperienced developers, arrogance can be deadly. Arrogance makes them unable to accept criticism and advice from others. When you comment on their code or presentation, they think you’re questioning their competence.

Many a newcomer, out of ignorance, displays this arrogance. Fresh out of school, they are full of confidence and do not realize that what they have learned in school is far from what society requires. The smart ones will quickly adjust to zero, learn hard and adapt to the company culture.

It’s not just newcomers — some developers with a few years of experience can also exhibit this arrogance, partly because they’re satisfied with their professional accomplishments, and partly because they don’t have the opportunity to work with great people.

In addition, arrogant behavior is another way to prove that such developers are really inexperienced. Such behavior can cause many obstacles to their career development, because no one likes to work with an arrogant person. When growth slows, they blame others more than themselves.

What you can do:

  • Be humble as you go. Being polite to others will get you far in your software development career.
  • Treat everyone with respect. When disagreements arise, treat the other person, no matter who they are, with respect when you voice your opinion.

5. Not learning from previous mistakes

I’ve always found feedback mechanisms to be an effective tool for software developers. Feedback from others helps us understand what our weaknesses are and how to improve them. A smart developer knows how to use feedback to grow.

You can tell if a developer is inexperienced by how they respond to constructive suggestions. An inexperienced developer will not accept any constructive suggestions, even comments in a code review, as a personal attack.

Many years ago, I had a colleague who wrote me a long email telling me how to review code. He was furious at the comments I gave him about his code. His main point was that I shouldn’t care about coding standards, because he knew how to code, and I should only care about whether the code met the functional requirements.

If a developer is offended by comments about his code, it shows that he has no real development experience. He held the attitude of doing a day monk hit a day bell work, but feeling did not meet the appreciation of their own bole.

What you can do:

  • Be positive with every feedback. For each response, you can choose to accept or reject it, but do so with peace of mind.
  • Learn from your mistakes. No one can be right all the time. Lifelong learning is what keeps you strong.

6. Handle personal matters during work hours

In my daily work, I often find that some members of my team are doing personal things during work time, such as reading social media, browsing shopping websites, and playing games.

I had a former team member who traded stocks on the job. Because he needs to pay attention to the K line of the stock from time to time, resulting in low quality of personal output. Other colleagues were annoyed with him because they had to spend more time to meet deadlines.

When the development manager talked to the developer, he changed for a while, but soon relapsed. Eventually, the company had to fire him.

Dealing with personal matters during business hours is against business ethics and shows unprofessionalism. We need to be dedicated to our work. After all, we have to make a living from it.

What you can do:

  • Try not to deal with personal matters during work hours. Ask your manager for leave when you need to leave for a few hours to attend to personal matters.
  • Use breaks to browse your social media. If you must order takeout or trade stocks, use your lunch break.

7. Chasing the tech bandwagon

Another sign of developers’ inexperience is their attitude toward technology trends. You’ll find them talking about technology trends all the time, and when a new trend comes along, they will immediately throw the old trend away and jump into the new one.

Inexperienced developers are always learning tutorials. Tutorials are undeniably a useful learning tool, but simply following them step by step without doing anything hands-on is a waste of time. It makes you feel like you have it all, but that knowledge needs to be tested by a real project.

Developers rarely use hot technology or tutorials to implement new things. They use hot technology or tutorials to satisfy their vanity or to worry about missing out.

What you can do:

  • Spend time and effort learning skills that you can actually use on the job or on a real project.
  • Learn from tutorials and practice them in time. You can learn more by implementing a feature yourself than you can from a tutorial.

Inexperienced developers can reduce the efficiency of the team by being inefficient themselves. His wrong attitude towards his job will cause him to miss many opportunities in his career.

It is wise to understand and avoid these wrong attitudes and ways of working. If you’re unlucky enough to pick up any of these bad habits, they’ll be harder and harder to get rid of over time.