The key to #1 is the "over" in "overcomplicate". In my line of work I see the reverse far more often, a reluctance or refusal to attempt complexity. As a result I see problems going unsolved rather than solved poorly.
The catch though is that I don't have any better way of being able to tell the two apart - the complicated and the over-complicated - than experience.
At the other end is where I agree, that having made a solution which is complicated, the next task is to attempt to reduce it to something less complex. I'd even suggest that step is more important than the documenting, because usually the person who crafted the complexity is well placed to know which parts proved to not be needed. On reflection that's perhaps the ideal point to bring in someone else, as a pair programmer, to help prune the code deadwood.
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.
The key to #1 is the "over" in "overcomplicate". In my line of work I see the reverse far more often, a reluctance or refusal to attempt complexity. As a result I see problems going unsolved rather than solved poorly.
The catch though is that I don't have any better way of being able to tell the two apart - the complicated and the over-complicated - than experience.
At the other end is where I agree, that having made a solution which is complicated, the next task is to attempt to reduce it to something less complex. I'd even suggest that step is more important than the documenting, because usually the person who crafted the complexity is well placed to know which parts proved to not be needed. On reflection that's perhaps the ideal point to bring in someone else, as a pair programmer, to help prune the code deadwood.