Before telling whether someone is good at programming there needs to be a definition of what is "good". The problem here is that this is always subjective. Here are some examples where there are different opinions: Use language X or Z, write automated tests or not, write automated tests before or after the production code, use mockist or classic style for for test-driven development, and maybe not everybody agrees on the guidelines in the "Clean Code" book or "code smells" classified in the "Refactoring" book.
However, a lot of interesting criteria where mentioned in the previous comments, the article linked in the question, and other resources like the The Programmer's Oath from Uncle Bob.
Here is my excerpt:
The problem at hand is solved and promises to customers are fulfilled
The benefit/cost ratio is greater than 1
The logic is correct and there are no unintended side effects
Respectful collaboration with team-mates and all other stakeholders
Others can understand and extend the code
Delivery of implicit requirements, e.g. performance and legal compliance
Effective strategy for life-long learning
Knowledge and application of modern best practices and tools
However, it is said that you "cannot measure productivity" of software developers. This doesn't mean that productivity doesn't vary, just that no-one can tell it for sure. Still there are some possibilities to find out whether you are a good programmer:
Get feedback from someone who has mastered the field
Do "benchmarks" to find out how you perform compared with peers, e.g. at hackathons or code retreats
Ask your boss for a raise
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.
Before telling whether someone is good at programming there needs to be a definition of what is "good". The problem here is that this is always subjective. Here are some examples where there are different opinions: Use language X or Z, write automated tests or not, write automated tests before or after the production code, use mockist or classic style for for test-driven development, and maybe not everybody agrees on the guidelines in the "Clean Code" book or "code smells" classified in the "Refactoring" book.
However, a lot of interesting criteria where mentioned in the previous comments, the article linked in the question, and other resources like the The Programmer's Oath from Uncle Bob.
Here is my excerpt:
However, it is said that you "cannot measure productivity" of software developers. This doesn't mean that productivity doesn't vary, just that no-one can tell it for sure. Still there are some possibilities to find out whether you are a good programmer: