It also means that you have to now treat programmers as the "talent" and not the "workers". Think movie star not factory worker and you'll do a lot better. It may seem retarded, but if you want smart creative people to work for you then treat them like smart creative people. Not like a rivet puncher at a factory.
How to do this depends on the particular kind of work being done, but generally speaking you want maintainable code with lots of tests, and records of the valuable knowledge gained in the process.
It's not easy to get this out of most developers, particularly if you are not a developer yourself. If you ignore it, chances are very good it's not being done at all.
Also, I was really arguing against Mark using it as a filter for ruling out resumes. I just don't think it works in either the positive or negative case. As with most everything in life the answer is more nuanced. If you rule out an entire category of potential employees, you're just limiting yourself.
Disrespect them (low pay, no pay raises, no down time, 80 hour weeks all the time, uncertain/unstable company, etc) and they will leave.
This strikes me as putting the onus on the company to ensure that knowledge isn't monopolized (as a previous commentor suggests) and, perhaps more importantly, to ensure retention of key people.
One way is to provide ownership, perhaps in the case of a startup, literally, of the company and its outcome.
In effect, this is the difference between another (likely unequal share) co-founder and merely an employee. Even if such a co-founder moves on, there's a strong enough incentive not just to "walk out" and leave the company without access to that knowledge.