> Your code will get refactored or rewritten. Docs will be superseded, then lost in some CMS migration. Before long, it will be as if you have never worked there.
The exception is if you build a fundamental component of the system, and that component is so unique in what it does that nobody who comes after you will even consider the idea of ground-up reimplementing it, but instead just has to immerse themselves into your mindset, trust your docs, etc, whenever they're maintaining that component, forever.
---
The bad/painful version of this, is when the component relies on unique hardware (e.g. a mainframe's native IO-acceleration capabilities), and was designed by someone who was immersed in that ecosystem and understood how to write code to take advantage of it. So the code is incredibly non-portable, written in terms of the low-level abstractions of the hardware, that nobody else in the company will ever understand to the same level the original programmer did. This is e.g. flight booking.
You should hope to never encounter these, since they make the rest of your service that has to interact with this thing into a tar pit of low momentum, from your lack of ability to effect change on this component.
--
There is a good version of this, too, though: when the component relies on unique concepts and math (say, doing static analysis by generating constraint statements and solving/simplifying them using a prover) that are portable, and could in theory be reimplemented in a new codebase if desired... but which were literally invented by the programmer in the process of implementing the code, at the climax of months of lateral thinking about how to solve the problem. This is an engineering True Dweomer.
There's usually nothing wrong with codebases containing True Dweomer code; they're not any less maintainable than usual. And they solve a problem that isn't solvable with simpler solutions — that's why such a weird solution was arrived at in the first place. So they usually tend to stick around.
But everyone who arrives at the company will nevertheless be slightly afraid of touching the True Dweomer code. They don't understand it, even though they know they could understand it given enough time (and prerequisite textbook reading.) Unlike mainframe code, people might look fondly on the code, looking for opportunities to be assigned to a project that requires that they come to grips with it... but the project usually ticks along by itself, not requiring much maintenance.
(What you'll actually hope for, is that whoever writes the True Dweomer code requests to lift it out, out of whatever project it's a part of, out of the company itself, into an open-source project. Because that way, that person who does understand it, can keep maintaining it, even after they leave.)