Your not good at programming - that's fine though because no one is good at programming. Humans are terrible at programming. But it's not our fault. We are expected to execute code in our heads while we write it, and expect that we will be able to do this perfectly without a perfect model of the machine running in our brains. So instead we splat some text into a file and then run it through our compiler/interpreter, watch it explode and then try to figure out why exploded. In the process we improve our understanding of the machine so we can write larger chunks of text before it explodes again. Once we finally get it to not explode we then expect someone else to be able to read that gibberish and understand it perfectly. They don't of course, and therein lies the first big mistake new developers make: rewriting code because they don't understand it.
The best advice I can give here is to try to avoid reading code. If you think the code is wrong, write another much simpler bit of code that will prove you correct. Isolate the code you think is wrong into a large list of possible inputs and the corresponding correct outputs. Then get that small program to brute force execute that list. People call these tests. I don't think it matters too much if you integrate these tests into your automated deployment process or not - that has pros and cons that will take good judgement and experience to decide - but at least do it for yourself. Your tests might not always be right, but they will be more right than you trying to execute the code in your head as you read it.
Second, search for evidence that the code is wrong. If the code being wrong would result in customers calling the company help line, go and talk to a help line agent and ask if they get calls about this. You might get an answer like: "yea, but it only happens once a month and it's really easy to fix". Then you reevaluate if you want to risk breaking it in a worse way to fix the thing that isn't that bad. It's really hard to predict if other bits of code rely on the bug to function correctly. Imagine an incorrect spelling of a status code being relied on for summing in a financial report in a completely separate system invisible to you. Fix the spelling, break the report, you won't even know it's broken.
Once a system is running doing important things, changing it is often like changing the engine on a jet while it's flying. You want to add a new mandatory parameter to an API but you know not all your clients have been updated to send it. So you tentatively deploy the parameter as optional. Life happens and before you know it most of the parameters in your API are optional, and there are tons of hacks to handle when clients don't send those supposed required parameters. Even seemingly simple changes can end up in multi staged migrations. Multi staged migrations tend to not be finished and this leaves a real mess. Try to break it up into small enough migrations that can be completed before your attention gets diverted elsewhere.
Big system rewrites are just massive multi staged migrations with tons of interlocking stages, begging to get into a tangled mess. Writing the new system is by far the easiest part of the process. Never underestimate the ability of a hard "switch over" - if even possible - to cause chaos and carnage. Big system rewrites will almost always have a Frankenstein phase where old and new systems are duct taped together like opposing ends of a magnet, waiting to fly apart on the drop of a pin. The old system is being rewritten because it's unstable and buggy, but the Frankenstein of the two systems is only as stable as the most unstable part of it. How will your data scientists combine data produced from the old with data produced from the new? Will you freeze new features while the migration is happening? Break the rewrite down into many tiny rewrites and be prepared for it to take a long time.
There is a reason why they are still around.
Unlike a builder, you can fit as many tools in your toolkit as you can remember you have. Object Orientation is a tool, not a hammer in a world made entirely of nails. ORM's are not always the best way to get at your data. Sometimes a regular function can stand alone in the world and still be of use. You might not need continuous integration for everything. Microsoft SQL Server is a fine database. PHP is not the devil. Expand your toolkit and keep an open mind. Getting HTML to look consistent in popular email clients requires you to give up hope of keeping your heart pure.
In Star Trek they did not type characters into a text file as a means of getting computers to do what they wanted them to do. "I canne push to the repo capt'n!". There is a massive gulf between how non programmers experience software vs the experience of creating that software. What does creating software even mean? What can it mean? Will we one day write all the software we will ever need, and transition to writing configuration files instead? Is a Python script not just an elaborate configuration file for the Python interpreter? Is a compiled binary not just an elaborate configuration file for a CPU? Will our starships run on SaaS? What are computers even good for, and why do we want them? Why do you want them?