3 ms·

This is unrealistic. The people writing stuff always vastly outnumber you, whether you are a company, a developer, or the on-call fireman. Figuring out things

This is unrealistic. The people writing stuff always vastly outnumber you, whether you are a company, a developer, or the on-call fireman. Figuring out things you neither wrote nor fully studied beforehand, without breaking everything, is not some waste of valuable time, that IS the valuable expertise itself. If you don't like doing that then that just means you're not a good fit for that role, not that there's some failing somewhere else that it's even needed. It's not possible to document everything, and even if it were, no one would ever be qualified to do the job by this standard, because 3 things changed in production just while the on-call was making coffee. This story was utterly normal and the only bad thing in it is just generally how tall and shaky and complex "normal" has become by now. But that's not anything any single company can do much about. Large web services need load balancing and orchestration and a lot of different moving parts, and every one of those parts are changing every minute because somewhere in the world a productive developer just committed a new line of code in something you use.

morelisp 4y ago
> But that's not anything any single company can do much about. Well, one company can certainly make it worse, by e.g. ignoring years of API ergonomics around process spawning and give you a vaguely-specified "command" string, then pumping VC money into their marketing budget to make themselves an "indispensable" daily tool. (Mostly I agree with you - just want to point out that in addition to the necessary complexity, the tooling around it also produces a lot of unnecessarily wrong-by-default behavior.)
- Brian_K_White 4y ago
  " the tooling around it also produces a lot of unnecessarily wrong-by-default behavior." It does. What I meant by one company doing something about it was, in realistic terms, no one can do much about the fact that the rest of the world uses a lot of complex systems that aren't as robust as earlier simpler systems. You have to use the current tools and that's just how they are now. You can try to be less stupid as possible, but you can't change the ecosystem you need to live in and interoperate with.
darkwater 4y ago
> Figuring out things you neither wrote nor fully studied beforehand, without breaking everything, is not some waste of valuable time, that IS the valuable expertise itself. Amen to that! It's basically how you start understanding how complex systems work in real-life and the lessons you learn while there can and will help you in every job you will have afterwards. Personally I also think it is what makes remarkable developers vs developers that just stay in their (usually tiny) domain.

morelisp 4y ago

> But that's not anything any single company can do much about. Well, one company can certainly make it worse, by e.g. ignoring years of API ergonomics around process spawning and give you a vaguely-specified "command" string, then pumping VC money into their marketing budget to make themselves an "indispensable" daily tool. (Mostly I agree with you - just want to point out that in addition to the necessary complexity, the tooling around it also produces a lot of unnecessarily wrong-by-default behavior.)

Brian_K_White 4y ago
" the tooling around it also produces a lot of unnecessarily wrong-by-default behavior." It does. What I meant by one company doing something about it was, in realistic terms, no one can do much about the fact that the rest of the world uses a lot of complex systems that aren't as robust as earlier simpler systems. You have to use the current tools and that's just how they are now. You can try to be less stupid as possible, but you can't change the ecosystem you need to live in and interoperate with.

darkwater 4y ago

> Figuring out things you neither wrote nor fully studied beforehand, without breaking everything, is not some waste of valuable time, that IS the valuable expertise itself. Amen to that! It's basically how you start understanding how complex systems work in real-life and the lessons you learn while there can and will help you in every job you will have afterwards. Personally I also think it is what makes remarkable developers vs developers that just stay in their (usually tiny) domain.