I really love Kasey's and Mat's answers in this thread and I only have a few more things to add to it.
Seek first to understand
It's really easy to find code that does not look great, especially in old codebases. But it's important to try to understand context before lashing out. There are legit cases where it was a job being poorly handled, but a lot of the time the answer is more subtle. Priorities, budgets, technical constraints, maturity... There are many reasons why you might be looking at something and thinking - oh my god, why did they do it that way?!
Hope for the best, prepare for the worst
Make sure that you know what could go wrong with your product. It does not mean having a fix for every possible problem, but it means having estimated the risks and knowing which ones need a mitigation plan. This is especially true if you're dealing with private data (probably 90% of apps today...).
Build for the refactor
You'll rarely see code that doesn't need to be changed. That's because software is built on moving foundations. Technology evolves, user behaviors change and you need to adapt to it. So make your code easy to replace because even if it's perfect now, there's a high chance that it'll be changed in the future. Pick clarity over cleverness.
Do retrospectives
The single, most powerful tool I've seen used in my experience is the practice of retrospectives. There are many ways to run them but no matter how you do them they bring amazing benefits. They naturally force you to stop, look back and improve of your work - and they give your team an excellent opportunity to provide feedback. Embrace them!
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.
I really love Kasey's and Mat's answers in this thread and I only have a few more things to add to it.
Seek first to understand
It's really easy to find code that does not look great, especially in old codebases. But it's important to try to understand context before lashing out. There are legit cases where it was a job being poorly handled, but a lot of the time the answer is more subtle. Priorities, budgets, technical constraints, maturity... There are many reasons why you might be looking at something and thinking - oh my god, why did they do it that way?!
Hope for the best, prepare for the worst
Make sure that you know what could go wrong with your product. It does not mean having a fix for every possible problem, but it means having estimated the risks and knowing which ones need a mitigation plan. This is especially true if you're dealing with private data (probably 90% of apps today...).
Build for the refactor
You'll rarely see code that doesn't need to be changed. That's because software is built on moving foundations. Technology evolves, user behaviors change and you need to adapt to it. So make your code easy to replace because even if it's perfect now, there's a high chance that it'll be changed in the future. Pick clarity over cleverness.
Do retrospectives
The single, most powerful tool I've seen used in my experience is the practice of retrospectives. There are many ways to run them but no matter how you do them they bring amazing benefits. They naturally force you to stop, look back and improve of your work - and they give your team an excellent opportunity to provide feedback. Embrace them!