I agree that it can be frustrating, but you don't know the constraints that the previous programmers were under, or if it's part of the "prototype" phase. The

I agree that it can be frustrating, but you don't know the constraints that the previous programmers were under, or if it's part of the "prototype" phase. The best thing to do is to gradually rewrite it by always leaving the code in a better state than it was before. For example, you're tasked with a non-trivial adjustment to an API endpoint--instead of adding to the mess, extract the endpoint out into it's own file and rewrite/clean it up. Write tests beforehand if that makes you more comfortable. Using this technique, my current team has been able to slowly rewrite our codebase from spaghetti JS (read: thousand line JS files) into a more structured TypeScript project. It has a long way to go, but doing an incremental rewrite works wonders. And like another poster said, being able to read legacy code is a good skill to have. After all, you'll need to understand it before rewriting it.