3 ms·

The graveyard is full of indispensable people. I felt indispensable at my last job - company is still alive years later, and I wish I had left sooner. It's ofte

The graveyard is full of indispensable people. I felt indispensable at my last job - company is still alive years later, and I wish I had left sooner. It's often hard to have perspective if you are The Person, or rely on The Person, but if the projects are important (Linux) they will evolve some kind of continuity and, if they aren't, they will die and other projects will replace them. If you care a lot about a specific project and want to prepare then it's similar to preparing for any other disaster. * Documentation and written processes for everything. People like to feel irreplaceable, but it's far more valuable to make yourself unnecessary. In high stress situations, people make bad decisions, so having well-oiled play books is important. E.g. see [0]. * Practice and simulations: at large companies people are sometimes put on surprised forced vacation and are not allowed to communicate with their team. * Foster a culture of encouraging people to step out of their box - if Important People's decisions can be questioned, then the rest of the team will better understand them and will be able to cope better with making them if necessary [0] https://www.atlasobscura.com/articles/pointing-and-calling-japan-trains https://www.atlasobscura.com/articles/pointing-and-calling-j...

londons_explore 4y ago
> Documentation and written processes for everything. There are upsides and downsides to this. Foster a culture of 'document everything', and you'll quickly end up with a corporation which runs like molasses as everyone has to spend time writing up meeting minutes and spends 90% of their time updating documentation and arguing over if something is allowed within the XYZ procedure. In my orgs, I generally say "a 1 pager quickstart guide on how each subsystem works, and everything else is docstrings and comments in the code". If the system is too complex for that to be enough for a new engineer to understand whats going on, then your system should be redesigned to be simpler. We're designing apps and web services. If it's complicated, then you're doing it wrong.
- Aeolun 4y ago
  > If it's complicated, then you're doing it wrong. You still need to do something even if you know this. Replacing the system is not an option, since the next one will be just as bad.
  - londons_explore 4y ago
    Normally an overly complicated system is the result of: * evolving requirements over time (a rewrite fixes this) * A tech lead overcomplicating things for job security or to justify expanding the team or a promotion. This is rarely easy to fix, because typically now things will depend on crazy complex semantics... "We extended our pubsub system into a probabilistically lossy data caching layer!" I normally fix it by moving the project to 'maintenance mode' and reducing headcount to 0.5 or so. Obviously it's best to have enough oversight that that kind of thing doesn't happen in the first place.

londons_explore 4y ago

> Documentation and written processes for everything. There are upsides and downsides to this. Foster a culture of 'document everything', and you'll quickly end up with a corporation which runs like molasses as everyone has to spend time writing up meeting minutes and spends 90% of their time updating documentation and arguing over if something is allowed within the XYZ procedure. In my orgs, I generally say "a 1 pager quickstart guide on how each subsystem works, and everything else is docstrings and comments in the code". If the system is too complex for that to be enough for a new engineer to understand whats going on, then your system should be redesigned to be simpler. We're designing apps and web services. If it's complicated, then you're doing it wrong.

Aeolun 4y ago
> If it's complicated, then you're doing it wrong. You still need to do something even if you know this. Replacing the system is not an option, since the next one will be just as bad.
- londons_explore 4y ago
  Normally an overly complicated system is the result of: * evolving requirements over time (a rewrite fixes this) * A tech lead overcomplicating things for job security or to justify expanding the team or a promotion. This is rarely easy to fix, because typically now things will depend on crazy complex semantics... "We extended our pubsub system into a probabilistically lossy data caching layer!" I normally fix it by moving the project to 'maintenance mode' and reducing headcount to 0.5 or so. Obviously it's best to have enough oversight that that kind of thing doesn't happen in the first place.