shantly
Joined 7 years ago
Joined 7 years ago
1) mixed labor (mental, physical)
2) moderate, varied physical labor
3) jobs that are mostly just being present and don't make you pretend to work most of the time
4) mental labor
5) jobs that are mostly just being present but do make you pretend to work most of the time
6) repetitive moderate physical labor
7) repetitive sedentary labor
8) hard physical labor
With 8 being at the bottom mostly due to typically being high-risk and coming with major mid-term harm to health.
The degree to which everything runs on this sort of system is kind of horrifying, once you're exposed to enough things like this for that to sink in.
Relatedly, I guess my contribution to the broader thread would be:
Almost no-one knows what they're doing, let alone is much good at it—so few, in fact, that society and the economy (and everything else) basically run on a massive and super-serious game of playing pretend. Yes, even that big important organization (public or private) where you expect everyone to be pretty damn competent. The difference between them and some normal place is that 5% of their people are impressively good at their jobs, rather than 2%.
[EDIT] if there's one modification I'd really like to make to my diet, it'd be to add fish once or so per week, ideally the fatty, oily, low-on-the-food-chain sort that're supposed to be so heatlhy. I need some kind of guide for how to work up to enjoying fish when you didn't grow up eating it. I can tolerate larger fish when cooked & seasoned very well, but don't really enjoy it at all, and have no understanding of what even to do with the smaller, healthier sorts that isn't stomach-turning (to me) to even consider. Though for some reason I love sushi and calamari, so, go figure.
But you should test your backups and set up useful alerts with the cloud, too.
> Third, nobody needs push-button re-deploy-from-scratch unless they're doing that all the time. It's fine to have a runbook which documents individual pieces of automation with a few manual steps in between, and this is way easier, cheaper and faster to set up than complete automation.
Huh. I consider getting at least as close as possible to that, and ideally all the way there, vital to developer onboarding and productivity anyway. So to me it is something you're doing all the time.
[EDIT] more to the point, if you don't have rock-solid redeployment capability, I'm not sure how you have any kind of useful disaster recovery plan at all. Backups aren't very useful if there's nothing to restore to.
[EDIT EDIT] that goes just as much for the cloud—if you aren't confident you can re-deploy from nothing then you're just doing a much more complicated version of pets rather than cattle.
[EDIT] oh and of course The Cloud itself dies from time to time, too. Usually due to configuration fuck-ups on their absurd Rube Goldberg deployment processes :-) I don't think one safely-managed (see above points) server is a ton worse than the kind of cloud use any mid-sized-or-smaller business can afford, outside certain special requirements. Your average CRUD app? Just rent a server from some place with a good reputation, once you have paying customers (just host on a VPS or two until then). All the stuff you need to do to run it safely you should be doing with your cloud shit anyway (testing your backups, testing your re-deploy-from-scratch capability, "shit's broken" alerts) so it's not like it takes more time or expertise. Less, really.
“Even”? I still hadn’t seen a usb-c anything in the wild when Apple switched their MacBooks to it and dropped all other ports.
Generally: minimize dependencies. External library or API dependencies? Versions can drift, the system can change out from under you in incompatible ways. That goes for the OS, too, of course. Data dependency that you aren't 100% in control of? Same. All are forms of state, really. Code of the form "take thing, do thing, return thing, halt" (functional, if you like—describes an awful lot of your standard unixy command line tools) is practically eternal if statically compiled, as long as you can execute the binary. Longer, if the code and compiler are available.