Reconcile or seek?

Question

Project management

I've been a PM for a year and a half.
For all the time there were and are projects that were developed before me.
They are implemented through the n-th place, a lot of bugs and other things.
I understand that this is a common thing and this is not news in digital.
I read a bunch of articles on this topic, studied the reasons and advice.
Question to the PMs:
- Accept this state of affairs and take it for granted? If so, how did you come to this? Did you manage to come to terms and worry less about such things?
- Or are there still projects that are less problematic and can be developed / supported with less hassle?

The very management of projects is a hassle, this is the essence of the PM business.
But when you see projects from which you want to gouge out your eyes, you stand in a stupor ...
From that, I need an understanding of how to deal with this or how to relate to this on the path of Pm-a.
Thank you!

Answer 1

But when you see projects from which you want to gouge out your eyes, you stand in a stupor ...

Work is like that. Report to the manager on each project the costs. And what solutions do you offer. The leader will decide what to do with it.

Answer 2

You can take the architect/analyst and team leader as allies and put the projects in order. With this result, you can safely look into the future.

Answer 3

There are projects where you don’t want to gouge out your eyes, but they are boring and uninteresting.
There are projects where you want to, but they are interesting to work on.
Try to understand why it upsets you? You don't like that no one cares? Become the one who doesn't. You don't like working with incompetent people? Build a resume and change jobs. You can’t be humble, but your “unhumbleness” should not be just a pose. You must not only offer improvements, but also sell them to the customer (it can be both internal and external). Why does he need it, how will it change his business? This bug has existed for 3 years and does not affect business performance in any way. Why clean it up?
Perhaps the reasons for problems on projects are compromises, bugs and shortcomings could happen not because someone is bad or clumsy, but because of deadlines / budgets / tasks. (Although it is possible, of course, someone and krivorukov).
I will quote Fedor Borshchev here , although this text is for programmers, it seems to me that this is a partial answer to the question:

Question: I wrote code based on what was already in the project, but at the review I was told that this code was bad and needs to be improved. How to immediately understand whether you write good code or not?
Answer: I do not have universal advice on how to distinguish good code from bad - in each team and each project, the requirements are unique. They are due to the engineering culture, the ability of the guys to negotiate with the business and hire the right people, the specifics of the business domain and a bunch of other things.
I can give another advice - try to improve everything. If you are older than middle, approaches to coding on a project can no longer be a constant for you. Even on the cleanest project with the highest engineering culture, all the code you see is the result of a compromise over time. If code were written without compromise, most likely the company you work for would no longer exist.
Regardless of the conditions under which your predecessors made their compromises, now the conditions are completely different, and you are making a completely new compromise. So, without forgetting about common sense, start by making yourself comfortable