Experience in software engineering comes with the number of years you are in the profession. The statement is true to a certain extent. However, the number of years in a job does not make you gain the right experience by default.
I have seen people behave amateur-like, even after working in their job for a good number of years. They hardly learn the basics of software development. Their growth stagnates after an initial couple of years, but they do not understand what they are doing wrong.
I have seen people behave amateur-like, even after working in their job for a good number of years. They hardly learn the basics of software development. Their growth stagnates after an initial couple of years, but they do not understand what they are doing wrong.
At the same time, I have worked with developers with just a couple of years of experience who show an incredible amount of growth potential. They possess the right attitude and know-how to avoid incompetent behavior.
Based on certain traits developers exhibit, you can easily find out who is experienced and who is not. Let’s dive into seven signs of an inexperienced programmer that every software engineer should be aware of to avoid making similar mistakes that can hinder their career progression.
List of signs of a bad programmer
1. Creates large pull requests
Have you ever got a code review request with so many changes in it that you don’t feel like reviewing it? Yes, that’s precisely what inexperienced developers do. They will bunch together a lot of changes in one single pull request. On top of that, they will expect you to prioritize their code review.
I have seen this habit of creating big pull requests with many senior developers too. They will code for days without feedback. When you finally review their code, they would have already built the whole functionality around it. Thus any review comment you give necessitates significant changes.
I have seen this habit of creating big pull requests with many senior developers too. They will code for days without feedback. When you finally review their code, they would have already built the whole functionality around it. Thus any review comment you give necessitates significant changes.
When I get such pull requests, my first reaction is to return them to the developer to break them down into smaller, logically divided PRs. I often just put comments in the first issue I find and send it back to the developer. If I feel incredibly generous, I will ask them to set up a call and review the code live.
What you can do:
- Create smaller pull requests. As a good practice, never leave a day's work without checking it in.
- Never check in the code that does not compile or breaks the build.
2. Writes spaghetti code
Inexperienced developers write the exact opposite of beautiful code. Their code will be all tangled and scattered across all over the place in the codebase.
If you ever try to read the spaghetti code, you will constantly get lost in it. You will forget where you started, what you are looking for, and what exactly the code is trying to do.
With experience, the developer should know how to plan their coding. Unless it is a straightforward functionality, put your understanding and the flow on a paper first. Do a dry run to visualize it end to end. Once you are crystal clear about the changes, then start on the implementation part.
If you do not follow the above process, you will have pain reading your own code. It will be hard for yourself and the whole team to troubleshoot or enhance the piece of the puzzle you wrote as code.
If you ever try to read the spaghetti code, you will constantly get lost in it. You will forget where you started, what you are looking for, and what exactly the code is trying to do.
With experience, the developer should know how to plan their coding. Unless it is a straightforward functionality, put your understanding and the flow on a paper first. Do a dry run to visualize it end to end. Once you are crystal clear about the changes, then start on the implementation part.
If you do not follow the above process, you will have pain reading your own code. It will be hard for yourself and the whole team to troubleshoot or enhance the piece of the puzzle you wrote as code.
What you can do:
- Have a clear understanding of the feature before you start to implement it. You can ask as many questions as you want to have a clear idea of the requirement.
- Keep your code simple and well structured. Your teammates should be able to read the code and understand its intended use it.
3. Tries to work on a lot of tasks at the same time
Inexperienced developers do not know where to start a task, how to proceed, and when to call it done. They try to solve a lot of stuff at the same time. They have no clue how to chunk a big task into smaller logical divisions to make it easy for implementation.
If you assign them a task, they will jump into coding immediately without verifying with you if they even understood the ask. Neither will they review their progress with you to make sure they are on track. They will get back to you only once they think they are done. By that time, you can only pray to have an accurate implementation for your requirement.
Another sign of inexperience is that such developers put their hands in too many things simultaneously. They will pick up tasks from unrelated features, volunteer themselves to troubleshoot production issues and promise to help others in the team.
In the end, these developers do not deliver any of the committed tasks in their entirety. This attitude might be well-intentioned most of the time, but the result is disastrous for the team. Ultimately the team loses a lot of time and has to complete all the tasks on a war footing.
If you assign them a task, they will jump into coding immediately without verifying with you if they even understood the ask. Neither will they review their progress with you to make sure they are on track. They will get back to you only once they think they are done. By that time, you can only pray to have an accurate implementation for your requirement.
Another sign of inexperience is that such developers put their hands in too many things simultaneously. They will pick up tasks from unrelated features, volunteer themselves to troubleshoot production issues and promise to help others in the team.
In the end, these developers do not deliver any of the committed tasks in their entirety. This attitude might be well-intentioned most of the time, but the result is disastrous for the team. Ultimately the team loses a lot of time and has to complete all the tasks on a war footing.
What you can do:
- Focus on shipping small. Break your assignments into smaller logical chunks. Get it clarified and then deliver the smallest possible block of working functionality.
- Take one task assignment at a time and complete it. Commit to a new task only when the previous task is delivered as requested.
4. Full of arrogance
Arrogance is a dead giveaway of an inexperienced developer. They are so full of themselves that they do not understand what they are doing wrong. You give them feedback on their code or presentation; they will take it as a personal comment on their ability.
Many freshers show off their arrogance, mostly due to their ignorance. They are fresh out of college and are yet to understand that the professional world is entirely different than what they learn in college. The smart ones actually stay quiet and show a keen interest in learning the ways of the corporate culture.
It is not just the freshers — some arrogant developers already have several years behind them in the software industry. It might be due to some of their professional achievements, or maybe they have not yet worked with people smarter and talented than them.
In either case, arrogant behavior shows a clear indication that such developers lack the right experience. Their ego blinds them from learning the right approach towards their career. Eventually, no one likes to work with an arrogant team member. Once the growth slows down, the arrogant developer blames others for their failure.
Many freshers show off their arrogance, mostly due to their ignorance. They are fresh out of college and are yet to understand that the professional world is entirely different than what they learn in college. The smart ones actually stay quiet and show a keen interest in learning the ways of the corporate culture.
It is not just the freshers — some arrogant developers already have several years behind them in the software industry. It might be due to some of their professional achievements, or maybe they have not yet worked with people smarter and talented than them.
In either case, arrogant behavior shows a clear indication that such developers lack the right experience. Their ego blinds them from learning the right approach towards their career. Eventually, no one likes to work with an arrogant team member. Once the growth slows down, the arrogant developer blames others for their failure.
What you can do:
- Be humble in your approach. Politeness goes a long way in building a successful career in software development.
- Treat everyone, irrespective of their designation, with respect. Refrain from getting into an argument over disagreements.
5. Does not learn from their mistakes
I always consider the feedback mechanism as one of the most effective tools for a software developer. Feedback helps us to understand our shortcomings and how to improve on them. A smart developer knows how to use the feedback to enhance their productivity.
You can easily spot an inexperienced developer based on their reaction to constructive feedback. They will never accept any improvement comment on their performance. They even take the code review comments personally.
Many years back, we had a teammate who wrote me a lengthy email on how I should review the code. He was infuriated by the review comments I gave for his PR. His main contention was I should not worry about the coding standard as he knows how to code. He wanted me just to review if the code meets the functional requirement.
If the developer feels insulted because of review comments, that is a clear sign that they have not learned anything from their experience. They continue to work year over year with an incompetent attitude and wonder why no one ever values their contribution.
You can easily spot an inexperienced developer based on their reaction to constructive feedback. They will never accept any improvement comment on their performance. They even take the code review comments personally.
Many years back, we had a teammate who wrote me a lengthy email on how I should review the code. He was infuriated by the review comments I gave for his PR. His main contention was I should not worry about the coding standard as he knows how to code. He wanted me just to review if the code meets the functional requirement.
If the developer feels insulted because of review comments, that is a clear sign that they have not learned anything from their experience. They continue to work year over year with an incompetent attitude and wonder why no one ever values their contribution.
What you can do:
- Keep a positive attitude towards every feedback. You can choose which one to accept and which one to discard. But give an impartial review before you decide to discard it.
- Have an open mind to learn from your mistakes. No one is right all the time. Use learnings to improve your performance.
6. Spends work hours on personal tasks
There are always a few team members whom you can find doing their personal work during office hours. They will be browsing through social media, scanning through online shopping sites, or playing games.
We had a team member who used to trade in the stock market during office hours. It hurt his delivery as he was always focused on how his day trade is doing. Other team members raised concerns about this behavior as they were the ones who had to put in extra effort to meet the deadline.
When the manager warned the said developer, he mended his way for a few days but got back to trading again. Eventually, the company had to let him go due to this behavior.
Such behavior is unethical and shows clear signs of the developer’s inexperience. It would be best if you were sincere towards the profession that helps you earn your livelihood.
We had a team member who used to trade in the stock market during office hours. It hurt his delivery as he was always focused on how his day trade is doing. Other team members raised concerns about this behavior as they were the ones who had to put in extra effort to meet the deadline.
When the manager warned the said developer, he mended his way for a few days but got back to trading again. Eventually, the company had to let him go due to this behavior.
Such behavior is unethical and shows clear signs of the developer’s inexperience. It would be best if you were sincere towards the profession that helps you earn your livelihood.
What you can do:
- Limit your personal tasks during office hours to a bare minimum. You can always take permission from the manager if you have to take a couple of hours off to attend to unavoidable personal issues.
- You can use your breaks to check your social media. Take your lunch to
the desk and do stock trading during lunchtime, if you want to.
7. Often runs behind hyped technology
A given sign of an inexperienced developer is how they run behind the hyped technology. You will find them always talking about the next big thing. As soon as there is a new fad in the market, the developer will drop the previous one and jump on the latest bandwagon.
Inexperienced developers also master the art of doing tutorials. No doubt, tutorials are useful learning tools. But just following tutorials without any practical use for it is a waste of time. It might give a false sense of accomplishment, but the actual test of knowledge is in using it for real-world usage.
You will seldom see the developer using the hyped technology or the knowledge acquired from tutorials to implement anything new. They just do it to satisfy their ego. Also, many inexperienced developers fall into this trap due to their fear of missing out.
Inexperienced developers also master the art of doing tutorials. No doubt, tutorials are useful learning tools. But just following tutorials without any practical use for it is a waste of time. It might give a false sense of accomplishment, but the actual test of knowledge is in using it for real-world usage.
You will seldom see the developer using the hyped technology or the knowledge acquired from tutorials to implement anything new. They just do it to satisfy their ego. Also, many inexperienced developers fall into this trap due to their fear of missing out.
What you can do:
- Spend your time and effort to learn technologies that you can actually use to implement something in your workplace or your personal project.
- Use the learnings from tutorials and perform the hands-on practice. You
will learn more from implementing something on your own than following
any tutorial.
Final Thoughts
Inexperienced programmers bring down the productivity of the whole team due to their inefficiency. Their incorrect approach towards the job makes them miss the opportunity to grow in a highly rewarding software career.
It is wise to know the self-destructing attitude early in the career and avoid them. The more you get into the habit of the behaviors mentioned above, the more difficult it becomes to come out of it in your profession's later years.
Thanks for reading the article. I hope you can avoid the pitfalls and achieve the career growth you desire.
It is wise to know the self-destructing attitude early in the career and avoid them. The more you get into the habit of the behaviors mentioned above, the more difficult it becomes to come out of it in your profession's later years.
Thanks for reading the article. I hope you can avoid the pitfalls and achieve the career growth you desire.
Tags
bad programmer's sign
how to become good programmer
signs of bad programmer
signs of bad web developer
signs of programmer
signs that you are bad programmer
Signs that you're a bad programmer