There are a lot of good answers here, but I'll add another perspective, which is that the code and the organization (probably) isn't the problem here. Your desire to fix every problem may well be, along with what sound like some either tool or process issues.
First and foremost, you have to realize that you're working for a company now, and most likely, that company needs to make money. Therefore, at some level, every decision that is made should be one of cost versus reward. While the software may well have bugs in some sense, unless those bugs are somehow impacting the business, they're only theoretical bugs. It's entirely possible that people/other processes have come to rely on those bugs, for example. So before you go changing anything, you need to have a business case to make a change.
That business case may be that the bug is really impacting something else, and thus needs to be fixed. Or the business case needs to be that fixing bugs in general is so difficult in the code that by restructuring the code, you'll be saving time going forward. And if it's the latter case, that you're restructuring the code to make things easier going forward (ie, paying down technical debt), there's a lot of work you'll need to do before making those changes. Some of the books/links pointed to in other answers will cover this, but in general, you'll need to make sure that you have a very comprehensive regression suite, so that you can be sure that the change you are making doesn't impact anything else. If such a regression suite doesn't exist, you'd be much better served by building one before you go making any changes to the production program. Is that much less fun and satisfying than fixing bugs? Yes, but it means that in the future, when you do fix bugs, you'll be able to do so safely.
I'd also like to address your statement
When 2 hours later I explained that I cannot give a guarantee to fix
this within a week he started to get slightly angry, also pointing out
he wants to present it on Friday and "the software used to work".
There are a number of potential concerns here. First, does this mean that the program is now broken in production? That should never, ever happen for a voluntary code change. If it's some sort of emergency hot fix, it's not a great situation, but it's sort of understandable. But otherwise, from their point of view, you just violated the "if it ain't broken, don't fix it" rule. The code may be awful, it may perform badly, and so on. But it was performing an important service, and now it isn't. So, again, like the regression suite, your time would be much better served figuring out how to build a test environment where you can test changes prior to rolling out anything in production. And, second, this also suggests a lack of source code control, which, again, if you don't have, your time would be much better served building, prior to making any code changes.
Don't get me wrong, speaking as a pure computer programmer, it's really irritating to know that something I wrote isn't perfect. I look at code I wrote five years ago with some amount of horror, and I really want to go back and rewrite it. But as a software engineer, a large part of the job is making tradeoffs, and that code is still doing what it was designed to do, and rewriting it would mean that I wouldn't be working on new programs that are solving new problems. From a business point of view, it's much better for me to solve a new problem instead of solving an already solved problem in a slightly better way, in a way no one else will notice.