I've heard "wins the lottery" as a less morbid metaphor for the same concept: one of your employees stops working in a low-probability event. Of course the higher-probability event is leaving their job (but somehow it's less polite to just say that); you usually get two weeks to hurriedly start documenting things, and with the current state of employee/employer relations you might easily get less. Or they might have several days of vacation saved up.

“Guys, I have some bad news. Brian, our star programmer, is leaving to work for a competitor.”

‘Oh no! We depended on him so much!’

“Hah! I’m just messing with you. He was hit by a bus and died.”

‘Phew! I was worried I had a job that didn’t pay competitively!’

Occassionally a 2 year stint just so some Gen X-er that reviews their resume’ doesnt consider them too noncommittal

No need to mince words about people leaving

It's definitely not unusual for developers to stay in roles for a decade or more. Especially very good ones.

There is just a lot of stuff to build and a salary that needs to increase 30% every other year

If I posted the job offers I've received for having experience with Spark/Hadoop, building / productionizing machine learning models (since 2011 even), an AWS certificate, and 15 years worth of other worthwhile skills, people here wouldn't believe me because they are so low. Definitely well below the startng salary of someone at Google. Yet I've had three, all of which were basically identical.

https://insights.dice.com/2016/07/08/how-long-do-tech-pros-s...

Personally, I'd be disinclined to interview a candidate with >= 3 jobs on the resumé, none of which lasted longer than 2 years. Taking into account the time spent for them to get up to speed, and the time their successors would have to spend taking over their code, it seems unlikely that their tenure would make much of a positive impact.

Furthermore, a key driver of experience in software engineers is maintaining their own code over multiple product cycles. Job hoppers not only don't acquire that experience, but may actively fall into a habit of bailing as soon as they get sick of their own code.

- Salary compression especially early on in your career is real. Most companies don’t do market adjustments after you are hired and only adjust salaries by a predetermined very low amount. The only way to get market salaries is by frequent job changes.

- If you have a job and people are willing to hire a job hopper, why not leave? At some point it will be a negative but when that time comes, just stay at a job until you get a better one. Also, if you do change jobs make sure it’s for the right reasons. For me, it’s technology, environment, and money in that order.

Maybe some people stop wasting their lives tallying the years instead of tallying those 000s

In b4 “but I like my manager and team”

http://wiki.c2.com/?LotteryNumber vs http://wiki.c2.com/?TruckNumber

if I suddenly could retire without a care in the world, I probably wouldn't mind dropping in for a day or two every now and again for knowledge transfer, even if I didn't like the company overall, to help my teammates..

In some key-person areas long notice periods (3months, for instance) are the norm. However this is never going to be the most productive 3 months of anyone's life! Serving 3 months notice becomes very dull by the end...

By contrast, a person being struck by a bus and killed has a definite finality to it. There is no going back. There is no hope of extracting knowledge from the once living individual. There is not even time to prepare. Their existence and their output has ceased and everyone alive must now live in this new reality.

> How much did they win? Maybe they’ll still keep working? Maybe they’ll go off to start their own company and take a bunch of key employees with them? Maybe they’ll be broke in a year and come back to their job? Maybe they don’t leave right away?

Well exactly. You don't know, and now you've given yourself four scenarios to think through:

1. Employee remains.

2. Employee leaves forever, maybe with others.

3. Employee leaves for a while but would come back.

4. Employee leaves, but with some time to plan.

1 should not be a difficult thing to plan for, and 2-4 all ask the same major question of "what if they leave". There's perhaps a slight benefit of not having to say "well assuming you are dead..." - I know I've had some time this year where I was trying not to focus on a death.

The key point is the risk. If your answer to "what if X wins the lottery" is "well as long as they don't want to leave..." then you're already setting yourself up to answer the question it's intended to propose - what if they are no longer working for the company?

That's not to say folks should be callous about it. But failing to think about things like this is also unfair and stressful to employees who are not dead.

Winning a lottery prize large enough to never talk to anyone again, and getting hit by a vehicle, are both very low-probability events. Employees (especially good employees, and perhaps in groups) leaving is a much more pressing risk.

It is an interesting phenomenon that I hear several times per year 'but what are the chances of this actually happening?'. The chances in any particular case are pretty good. But with 43 companies we looked at in 2018 and 100+ over the last years there are multiple such instances that I can refer to so even if the chances are not super high they probably are a lot higher than you think they are!

I do agree with other commenters that your procedures should keep you safe in case of regular churn (say 1 in 3 to 1 in 10) or even non-regular churn (say due to a toxic team-lead and a whole team quitting).

Ideally procedures should be in place that treats all these events quite equally and favor robust practices.

It started to get really frustrating and upsetting. I'm not exactly a "pair programming" zealot but I definitely find value in overlap of responsibilities.