Rewriting is tricky because you're unlikely to know it well enough to make sure you replicate all of the important functionality. In fact, the messiness of the code makes it harder for you to understand it well enough to rewrite it. Plus rewrites take a lot of time!
Skipping is actually a pretty solid option if you don't need to change the code. The code may not be great, but if it's doing its job and you don't need to modify it to fix bugs or add features then by all means just leave it be.
Telling your boss doesn't necessarily help, but might be helpful if it means you can secure extra time to clean it up while you're working in it.
In my experience, the best approach is to clean it up as you work in it, making lots of small, safe refactors. Hopefully it's under test, but if not then you can start writing tests for the parts you're working on so that you can more safely and aggressively refactor it. Eventually you can get the system under control and totally clean, but it takes time and elbow grease. And getting it totally clean may not even be the right investment for your company to make. So often times it's good to spend some percentage of your time cleaning it up as you add features or fix bugs. Alternatively, you can invest time in fully cleaning up just the parts you need to modify for the work you're doing. That way you're not spending time cleaning up code unnecessarily and the parts you're changing are well-factored and easy to work with.
It's also worth noting that many developers (myself included) can get personally invested in their code. So if you have to work in someone else's dirty code then it's worth investing in building a relationship with them, asking about how they'd change the code, and starting with small changes to build trust before moving on to larger refactors.
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.
Rewriting is tricky because you're unlikely to know it well enough to make sure you replicate all of the important functionality. In fact, the messiness of the code makes it harder for you to understand it well enough to rewrite it. Plus rewrites take a lot of time!
Skipping is actually a pretty solid option if you don't need to change the code. The code may not be great, but if it's doing its job and you don't need to modify it to fix bugs or add features then by all means just leave it be.
Telling your boss doesn't necessarily help, but might be helpful if it means you can secure extra time to clean it up while you're working in it.
In my experience, the best approach is to clean it up as you work in it, making lots of small, safe refactors. Hopefully it's under test, but if not then you can start writing tests for the parts you're working on so that you can more safely and aggressively refactor it. Eventually you can get the system under control and totally clean, but it takes time and elbow grease. And getting it totally clean may not even be the right investment for your company to make. So often times it's good to spend some percentage of your time cleaning it up as you add features or fix bugs. Alternatively, you can invest time in fully cleaning up just the parts you need to modify for the work you're doing. That way you're not spending time cleaning up code unnecessarily and the parts you're changing are well-factored and easy to work with.
It's also worth noting that many developers (myself included) can get personally invested in their code. So if you have to work in someone else's dirty code then it's worth investing in building a relationship with them, asking about how they'd change the code, and starting with small changes to build trust before moving on to larger refactors.