(assuming production code)
I tend to go a bit further. I've written about making programs "idiot proof", but I don't always qualify that: I write a lot of code that other people will not see or work with (at least, that is the expectation when it is written). I am the idiot I am trying to defend myself from in that case. It's a good thing when your program detects problems for you, and the problem has been simplified so much that it's quite obvious that there is an error, and its origin. The truth is, implementation details are obvious when you write a program (unless you are implementing it prematurely), but they should be abstracted and error resistant for clients (even when module locality exists). The reason is that programs become very complex. Sometimes you can separate problems, but not all the time. If you keep your components very strict, simple, well encapsulated, and idiot proof, they do tend to scale well and most defects are detected before they are shipped. It's easier to reuse, and you have more confidence and an easier time reusing the programs, As well, those complex programs that you write only become more complex (even to you) after some time away from the program. When you read it in 6 months, it can take an absurd amount of time to understand and debug compared to the idiot proof version. If a component introduces a breaking change, it can go undetected for a long time otherwise. Programs are complex; you can't escape that reality, but you can make it idiot proof, which will make your life a lot easier when something goes wrong or when it must be reused or altered. Therefore, the idiot proof approach means that your software can be understood, reused, or maintained by your juniors or people newer on the team as well (not just somebody as good/experienced as you). Replacement is a separate concern: If people love working with your programs, you're doing a good job -- don't worry about replacement. Sure, I could come up with scenarios where unintelligible programs could save your job, but writing a good program others can use and maintain is clearly the lesser evil (look at the others' resopnses). If I catch myself writing something that is not idiot proof, I try to fix that.
Apart from the scenario, where you need some documentation for yourself in order to continue a project after 6 months of pause, there seems to be a clear conflict of interest here between the developer and the software company.
You really have no idea what you were thinking some of the time when you revisit dormant implementations. When you are really experienced, then the problem is simpler because you can rely more on established methodologies or approaches which you use. That, however, also assumes these methodologies are invariant. Even though the documentation may lax, you still have to be defensive in your implementations (e.g. you know better than to pass NULL in this scenario -- test that condition).
So as a programmer, should you really write excellent documentation and easily readable code for everyone; or should you write code and documentation in a way that it does the job and you yourself can understand it, but another person may have trouble understanding it?
I recommend the idiot proof approach, which is even clearer and more error resistant than the bus factor approach. Write your programs and documentation such that it is easily understood by somebody external to the project -- it's good for you too. Doing so will increase your value to your company and team, they will not want to replace you.