ashrk
I'm a little sensitive to this one because my wife and several of my friends are teachers and I gather it's really, really common for even fairly well-off kids' breakfast, every day, to be a couple pop-tarts. Which is a dessert, and isn't even on the healthier end of that category. As long as that continues to be as normal as it is, our obesity epidemic's going no-where.
Definitely don't blame low-income folks for doing what they need to do to get through the day, and yeah, food waste can really suck when you're not handing your kids hyper-palatable food for every meal, with the extra kick in the teeth that the hyper-palatable stuff's often easier to prepare. I mostly just weep for the future when I hear about the clearly-middle-class-or-higher folks doing that, or see them feeding their kids snacks (almost always crackers or similar) in the store to keep them docile, or whatever.
> If I ever have children, this is my plan. But I have also heard that plans don't survive contact with the enemy...
It's for sure harder to do it right. Snacks do shut them up, and in that weeks-to-months period when they just won't STFU at the store damn it, you do wanna just shove some crackers in their face so they'll quit making a scene. But if you do you'll have to keep doing it and then you're the parent with the six-year-old still snacking in the store. They will eat crap for any meal at all, or between meals, because it's crap and tastes freakin' amazing. That's the point of it. You just gotta suppress fear of judgement and keep in mind that the (medical) pros say skipping or picking at 50-60% of meals is totally normal for kids, and they will not starve themselves into ill health just because green beans don't trigger the same primal OMG-I-need-more-of-this responses as Doritos do.
The only place this is hard for us is with the grandparents. OMG there's no stopping them short of just cutting them off, which is too harsh for us to stomach. So much junk food. But that's how they eat too—they just don't get it, and that kind of deep cultural difficulty with food is why it's such a pain to do things right on an individual level. And school-provided lunches are pretty bad. The ones around here, at least, are clearly designed to shove as many calories as possible into the poorer kids, damn the nutrition and good eating habits.
Present healthy food. Vary it day over day in case they really do have some strong dislike for something. If they don't eat it, they weren't very hungry. They will eat cereal every time you give it to them, no matter how hungry they are, which is part of the problem. Do not feed them crap because "that's all they'll eat".
- Stepping through with a debugger. Static analysis call graphs in stricter languages[0]. Runtime call traces and visualization in dynamic languages. Often you can find some tool for it[0]. If it's that bad you're probably not gonna be able keep your head wrapped around it long term, so you'll be falling back on those tools often until/unless you refactor.
- Similar. Find a way to trace requests (you are really, really gonna want such a tool when things go wrong anyway if you're microservice-heavy) and record what happens, if it's so confusing you can't figure it out otherwise.
- Not much to do but isolate and replace piece by piece or screen by screen as the opportunity presents itself. Hardest part of this is that your new stuff may well look and work better than the old, which can lead to UI inconsistency, so it ends up being an exercise in inconsistency tolerance or management.
- Just gotta leverage tools to tell you more about the codebase than you might get from just looking at it (as in point 1) and do a lot of probably-boring and hard-to-measure difficult work. If it's still under development that means someone ought to be able to tell you what each largish part (feature, screen, section) should do, at least from the perspective of the end user, which may be useful. If no one can tell you that then why are you maintaining it, right?
Jumping off that fourth point: a great preventative measure for ending up in this position (or putting someone else there) is to make sure your code is written such that tools can more easily tell the reader facts about the project. Typescript over raw JS, that kind of thing. Static types are communication. They're communication that can be verified by a machine to be correct, more or less. They're great. Tests fail or pass. They tell you what the test writer expected to happen, and whether that's happening. They are communication. If all your comments get stripped and no-one updates the docs for two years and you get hit by a bus your types and tests still communicate. Even outdated test suites aren't totally useless. And static types pretty much can't go stale like docs or tests can.
[0] https://github.com/TrueFurby/go-callvis
[1] https://github.com/jamesmoriarty/call-graph (no endorsement, haven't used it, just an example.
I harbor no ill will toward these folks. Hell, selfishly, I'm glad there are so many. Having half an idea what you're doing is guilt-inducingly easy, pays amazingly well—especially after the confidence-boost and resulting swagger and negotiating attitude that comes with seeing this kind of thing over, and over, and over, for years on end—and it's disturbingly easy to be a or the "smart one" in the room when you're kind of a dummy, in fact.
[0] Dear backend devs: if you don't simply love backend work and/or if you aren't very well appreciated compensation-wise, and especially if you have long-term career aspirations that involve shifting more toward the biz/architect/management side for the extra social status and higher late-career pay (in most of the industry outside the huge West-coast tech companies, anyway), consider moving to more high-visibility pastures—though ideally not web frontend, as, incredibly, it's still a trash fire and comp is so-so, mostly. Unless you just like trash fires, which some people do.
Comically bad security holes, actual or implicit (framework-created) SQL queries in a for loop for no good reason (well, because the developer had no idea how to use SQL, and hadn't developed an appropriate allergy to unnecessary network communication, are probably the reasons), hilariously misguided attempts to fix the wrong thing to improve performance ("we'll move it to jruby!" well sure but your actual problem is you chose an inappropriate database and are using it poorly, but at least you made your build pipeline worse for marginal benefits, so there's that). Ruby in your node project just to run a very basic task queue (!?). Et c., et c., c-beams off the shoulder of Orion, tears in the rain, et c.
Inheriting something even half-decent is really, really unusual. I wouldn't bad-mouth half-decent. I just rarely see it.
[EDIT] this probably varies a great deal by platform. I imagine it's a bit less common to have a total train-wreck of an iOS app, to pick another platform I've worked on, than something server-side.
Incidentally, I'd pick map & navigation data as the one big Web thing that really ought to be handled by government. Up-to-date, freely (or very cheaply) available map data should be considered infrastructure, and government(s) ought to already be generating/collecting it. Let the private market get it to consumers, but governments ought to be providing good-enough data that there's no need for private collection of it, in the general case. Leave street view and business reviews and such to Google and friends, but enough data to build a pretty damn good navigation app should just exist for anyone to use. It's a huge waste of effort to have multiple organizations trying to put all that together and it's something governments should to already have the data to provide, given some coordination—great candidate for a government service, or at least one of those government-coordinated public-private shared-cost-shared-benefit projects, post-war Japan style.
Zen tales tend to present a couple major challenges to the reader:
1) Going into them cold isn't exactly intended. The characters are usually named for a reason, and it's expected that the reader/hearer will already know some things about the historical persons in the story, possibly some other tales about them, from reading histories and lineages, and so on, providing more context than is apparent at first if you take the stories per se.
2) There's often at least one relatively easy-to-pick-out though rarely explicitly stated lesson in them, but also one or more metaphorical or allegorical readings, at least one of which will be a "canonical" reading, i.e. your teacher will expect you to come up with it after some consideration before moving on to the next koan/tale—they don't expect that every student, or even many, will come up with a totally new and valuable metaphorical/obscure insight to the koans they present them, as that's just not realistic and no-one would ever advance if that were the expectation.
An easy example of 2 is (from memory so this wording will suck compared to the real thing) the "what should I do now?" "have you eaten your rice" "yes" "then clean out your bowl" one from (IIRC) Gateless Gate—simple surface reading of first-things-first and the importance of routine-following, but one available deeper reading of this as a Zen "challenge" (many of the koans/tales are) where the question "have you eaten your rice?" is actually asking, as understood by both characters, "have you attained enlightenment?" or similar, and "then clean out your bowl" has to do with banishing hubris or something along those lines.
Point 2 especially fairly speculative and arrived at purely second hand—I've not practiced Zen Buddhism—though I'm confident enough in it to present it here. Take that for whatever it's worth.
[EDIT] further, the point of their contemplation is in taking the journey to the answers, in part for the value of the journey and (one supposes) in part to train in the kind of lateral thinking that's so vital to these "zen battles". So just having a list of "answers" alongside the text kind of defeats the purpose, though they're definitely not intended to be as obscure and hard to follow as they are if you go into them with no background on (basically) Buddhist historical trivia.
See also: voice interfaces. Your nifty paid version that's entirely local? Good luck competing against free, cloudy, and data-stealing, especially when the data-stealing helps the competing services get better. There's a reason local voice-to-text seemed to be getting really good for a while then suddenly dropped into obscurity.
See also also: any paid (or even free and volunteer-based!) website or service that might compete with ad-paid and/or information-harvesting and free. Uphill battle to gain user-share. You'll almost certainly fail, because information-harvesting is a possible business model and no matter how much people hate it they can't organize to stop it, realistically, because game theory (ahem, which is we have governments, in the short-short version)
Perhaps not coincidentally that's about when the fundamentally-a-bad-idea service of Facebook started to get huge as it grew past college campuses, and showed it was really easy—like, incredibly easy—to convince all these new Internet users to give strangers tons of information about themselves, in gross violation of previous Internet norms of avoiding posting personal info anywhere, and that one could make stupid amounts of money by facilitating these poor choices.
Like x86 assembly is, sure. Though way less well-suited to its modern purpose than that is. It's alive by accident and momentum, purely.
If it did what we needed it to do we wouldn't have burned who knows how many (tens of?) thousands of person-hours creating half-complete solutions to its various plain-as-day shortcomings. Input wrappers, table sorters, sequential image viewers, and so on. We did finally get video but it's still usually wrapped in custom UI driven by JS. It's not complete and featureful enough to exist as a good rich document format without JS (due to its long stagnation) but is also really far from being a good choice for laying out and describing applications (because it was never meant to be).
Agree that browser vendors are the ones who'd have to fix all this. The time for that passed a long time ago, of course. I just think it'd be nice to have a hypertext document network that doesn't have on-client spying as a first-class, built-in feature that you have to go way out of your way to even partially avoid. Creating Javascript and giving it such wide access was what killed any hope of that. I consider that the original sin of the modern web, that the platform itself is fundamentally and irreparably insecure (from the end user's perspective).
That a cross-platform application distribution platform might have arisen anyway is beside the point. It'd have been nice to keep that separate from the locked-down hypertext platform that keeps the user in control. We've lost the latter in gaining the former, rather than having both.
[EDIT] I'm with you on humans being the problem over technology in general, but in this particular case I think there were technical reasons that Web 1.0 was destroyed in the creation of Web 2.0 and we were left with one crappy platform that constantly betrays and tricks its users rather than two, at least one of which isn't capable of betraying its users the way this one does. We're where we are because no-one treated Javascript (or anything else with its capabilities and liberties in the browser) as the fundamentally terrible idea and permanent trust-ruiner that it was. It's inherently and unavoidably a security disaster for the Web, not in terms of secure communication between client and server or whatever, but in terms of practical personal security for the users and their data.
1) letting Javascript initiate network connections without explicit user interaction with a narrow set of elements (say, a submit button) was a mistake.
2) not having a browser-provided summary of the data a form is about to submit before it's transmitted was a mistake.
Basically letting Javascript escape from a little box of tightly-scoped input validation handling and maybe defining sort functions for tables was a mistake.
That's more interesting to me than individually-containerized applications. I want to have per-project and/or per-task-group desktop sessions that are right where I left them when I spin them back up, within reason. That's the one big "killer feature" I feel lacking in every modern desktop OS I use.
Duke Mu did so, and subsequently despatched him on the quest for a steed. Three months later, he returned with the news that he had found one. 'It is now in Sha-ch'iu,' he added. 'What kind of a horse is it?' asked the Duke. 'Oh, it is a dun-coloured mare,' was the reply. However, on some one being sent to fetch it, the animal turned out to be a coal-black stallion! Much displeased, the Duke sent for Po Lo. 'That friend of yours,' he said, 'whom I commissioned to look for a horse, has made a nice mess of it. Why, he cannot even distinguish a beast's colour or sex! What on earth can he know about horses?'
Po Lo heaved a sigh of satisfaction. 'Has he really got as far as that?' he cried. 'Ah, then he is worth a thousand of me put together. There is no comparison between us. What Kao keeps in view is the spiritual mechanism. In making sure of the essential, he forgets the homely details; intent on the inward qualities, he loses sight of the external. He sees what he wants to see, and not what he does not want to see. He looks at the things he ought to look at, and neglects those that need not be looked at. So clever a judge of horses is Kao, that he has it in him to judge something better than horses.'
When the horse arrived, it turned out indeed to be a superlative horse.
- Liezi
I'm pretty sure this is why I've never had trouble with programming, despite feeling the way I imagine a dyslexic must when I try to read very "mathy" material even about things that I already understand. Programming's algorithm-first. Except the few languages that aren't, and I bounce off those, too.
And all of it looked pretty bad. I'm a fan of (though not insistent upon using) "ugly" old school interfaces, so it's not that it wasn't "flat" or "beautiful" enough or whatever the current trend is, just lacking consistency and the result of a whole bunch of small, poorly-chosen defaults adding up to a big stew of gross. I could overlook that if it weren't also crash-prone and janky as hell, but it is.
So I'm still stuck on Mac for anything serious, and my gaming desktop sits in storage because I can't be bothered these days to screw with either Windows post-10 or Linux. Sigh.
FWIW my favorite desktop I've ever used, as far as core software, stability, desktop UI/X, compared to its contemporaries, was BeOS.
For my part, I've discovered since switching to Mac that I don't like having system packages managed alongside user packages.
It's one thing when I'm all-in on handling everything from the kernel up (it was fine back when I used Gentoo, for example) but the middle ground of massive meta-packages and such mingled with user-installed individual packages on e.g. Ubuntu is a train wreck. MacOS w/ homebrew's great. I can delete the entire directory with my brew installed crap in it and the system's unaffected. System upgrades are separate from my stuff. That plus the occasional drag+drop installed program cover my needs nicely, and better than everything's-a-bespoke-GUI-installer on Windows.
https://wiki.postgresql.org/wiki/Foreign_data_wrappers
In fact, seems it has several.
Maybe it's a branding thing, and French wine's got enough power in that department that they don't need to send us good stuff to move product, at least at the lower end. Maybe with some French writing on the label low-price-shopping consumers are equally likely to buy it whether or not it tastes good, so there's no reason to send anything but the worst they have. Other European countries seem to have no trouble shipping us nice wine in the lower price tiers, but then they're not France.
Distributing responsibility for determining which companies are being ultra-shitty but not breaking the law imposes far too much time-cost on consumers to be reasonable, on top of the regular costs of participating in boycotts. They're not an effective means of enforcing society norms. Regulation is—making being ultra-shitty illegal works way better than imposing a cost of ((time it takes to keep up with and track shitty-company news)+(cost of participating in boycotts)) times (number of consumers) across your entire society. That's clearly untenable and it's not really the fault of individual consumers that boycotts don't work for enforcing social norms, since they can't really work, in the general case, once your economy scales past the local cottage industry level. It's impractical in a global, or even national economy. Then there's game-theoretical pressure to defect from a boycott, et c.
Even the highly-engaged consumer will catch and (weakly, ineffectually) punish maybe single-digit percentages of the awfulness occurring in their economic footprint, at great time and probably monetary cost, unless they check out from the economy almost entirely.
I read all three volumes of Lichtheim's Ancient Egyptian Literature first, though, so that may have spoiled me. It's dry as hell but way better than either of those other volumes. Was good enough that I remember quite a few details and individual works from it years later, unlike those.
I've got about seven volumes of ultra-early literature (the last 1.5 or so of Lichtheim aren't that early), six of which I've read or attempted (haven't made it to the Indian philosophy sourcebook yet, some of which is quite old) and of them the only one I'd recommend to the general reader is Stephen Mitchell's Gilgamesh, which was entirely excellent and so wildly better than any of the other Mesopotamian work from that time that I suspect Mitchell embellished heavily (IIRC reviews indicate he didn't, but still) or the modern version of the work was much improved by the time any of the copies or large fragments we have were written/chiseled. It's crazy good. A couple later Egyptian tales were of similar (though definitely lesser) quality but absolutely nothing else Sumerian or Akkadian's even got a hint of anything like that, from what I've seen.
I'm not sure I'd recommend the Sumerian or Akkadian collections to anyone, really, unless that's their specialty in which case they don't need me to recommend things to them. It's possible I just chose poor collections, though. Certainly the Akkadian one was no good, though I'm not sure there's any better in English.