I envision your comment will be taken out of context to literally justify adding mountains of code written by other people. Invented Here Syndrome
Not necessarily a bad thing, if you are good at selecting dependencies.
But it can be a very, very bad thing, if you are not so good at selecting dependencies.
That said, the worst codebases I've worked with were examples of the former. So it's definitely a tricky balance.
It's not because the code is bad. Quite the opposite, really. It's well-structured, and incredibly well-documented.
It's because I tend to do some fairly ambitious things, and write in a modular, layered fashion that can distribute functionality throughout the stack.
I also tend to write in a fairly asynchronous fashion (would you call it "reactive"? I dunno. I've been writing code like that since long before "reactive" was an official buzzword).
Can be hard to grok.
+ simplify it + reduce it + make the code more readable
When not possible, make at least more readable, like choosing the right method & variable names.
I'll sometimes spend a couple of hours on a method, removing unnecessary code.
It does NOT always end up with more performant code (sometimes, the opposite), but it does reduce the "I don't wanna remove all that code" surface, and it usually* makes the code easier to understand.
* I write Swift. Sometimes, less code is more obscure code, and I often have to go back and put code I removed back in, to make it more understandable.