These are all good points, but when I think of what it takes to be a good programmer, I usually think about how your abilities relate to the tasks your trying to accomplish. Nobody is good in a vacuum. Not that the article doesn't make that point, but I'd like to go further with that.
I think being good at programming is an ability to understand the problem at hand and take the appropriate steps to solve the problem. More novice programmers don't quite have the ability to understand the current and future problems, and might not come up with the right solution, even if it is technically correct on some level.
Part of solving the problem has to do with the team's makeup. If you're on a solo project, your role and plan of execution is a lot different than if you are on a team of 20 working together on something. Understanding your own strengths and weaknesses, communicating them with the team and finding ways to be productive are all part of it.
Beyond writing extensible code in and of itself, being good at programming is about having developed the toolset to be able to take on a problem with your full creativity, and not be hampered by the basic "how do I even start to approach this?" questions you might have at an earlier level. When you are good, you can see a problem and develop a coherent path to appropriate solution, then execute on it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
These are all good points, but when I think of what it takes to be a good programmer, I usually think about how your abilities relate to the tasks your trying to accomplish. Nobody is good in a vacuum. Not that the article doesn't make that point, but I'd like to go further with that.
I think being good at programming is an ability to understand the problem at hand and take the appropriate steps to solve the problem. More novice programmers don't quite have the ability to understand the current and future problems, and might not come up with the right solution, even if it is technically correct on some level.
Part of solving the problem has to do with the team's makeup. If you're on a solo project, your role and plan of execution is a lot different than if you are on a team of 20 working together on something. Understanding your own strengths and weaknesses, communicating them with the team and finding ways to be productive are all part of it.
Beyond writing extensible code in and of itself, being good at programming is about having developed the toolset to be able to take on a problem with your full creativity, and not be hampered by the basic "how do I even start to approach this?" questions you might have at an earlier level. When you are good, you can see a problem and develop a coherent path to appropriate solution, then execute on it.