1) Ship it. The best software teams I have worked with focus on shipping.
2) Communicate. It's cliche, but true. If a problem appears to be on the horizon (missing a deadline, over-budget, etc.), it is better to bring it up now than to wait.
3) Write tests, but it doesn't need to be for everything.
4) Red, Green, Refactor...in that order.
5) Occam's Razor. The simplest answer is usually the best. I face more challenges changing code which is over-engineered than I do code which simply uses basic best practices and straightforward refactoring methods. This is because, while maybe the original intention of the over-engineered code was good, a slew of edge cases has made the design indecipherable, and thus, difficult to change. To be fair, I did this as well as a junior dev.
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.
1) Ship it. The best software teams I have worked with focus on shipping.
2) Communicate. It's cliche, but true. If a problem appears to be on the horizon (missing a deadline, over-budget, etc.), it is better to bring it up now than to wait.
3) Write tests, but it doesn't need to be for everything.
4) Red, Green, Refactor...in that order.
5) Occam's Razor. The simplest answer is usually the best. I face more challenges changing code which is over-engineered than I do code which simply uses basic best practices and straightforward refactoring methods. This is because, while maybe the original intention of the over-engineered code was good, a slew of edge cases has made the design indecipherable, and thus, difficult to change. To be fair, I did this as well as a junior dev.