ashrk's comments

Yeah, I've got three of the little buggers. Thanks for keeping it civil, I could have been less blunt in my initial response.

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.

> Sometimes your kid will only eat sugary cereals for breakfast

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".

I spent a lot of time a few years back reading some Russian world traveller's photo blog (he looooved taking photos of signs and fire hydrants and such, which I wasn't super into but was sometimes interesting, but also posted plenty of other things—I misplaced the URL long ago or I'd link it) and the rule for off-the-beaten-path tropical paradises seemed to be that they were incredibly poor and absolutely covered in litter and improvised garbage dumps. If there were touristy sections it'd be every square meter of the place off the tourists' beach that looked like this.

In order—and mind I'm not like amazing at this so take none of this as best practice:

- 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.

Mobile, probably a lot of data-analysis jobs provided you get to present results. Desktop work if you can get it. Non-traditional UI like voice. You can spend (what will seem like) a silly amount of time selling what you've done in backend work, even, it's just a harder path.

Sure, and man are the easy wins satisfying. Fixing shitty data access methods/patterns is one of the easiest ways to get a "WOW!" out of a client or product owner if you're stuck in the low-visibility silo of backend dev[0]. I've just been repeatedly surprised over the years at how very, very many people are making real money, and consistently finding work, yet don't seem to know which way is up. And I don't mean greenhorns, though often they're given comical levels of responsibility (typically by the cash-strapped or cheapskates) resulting in some real messes, which has a similar effect to when an incompetent "lead architect" or an experienced team nonetheless without a clue between them is set loose, which is just as common.

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.

No (or long-broken) tests and no easy (at least partially automated and otherwise documented) way to build and/or run the code locally are the norm for others' codebases I've inherited. Those two things qualify it as "awful" I'd say, all on their own. Especially in languages like Ruby or JS where you're practically crippled in an unfamiliar codebase without tests and/or being able to poke around in the running application. Both being absent is a near-perfect signal there are tons of other problems, of the screw-up sort and not the we-had-to-cut-corners-for-actual-reasons sort.

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.

I see it on here from time to time on here but have never heard a person in real life mention it, so... maybe?

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.

Pretty sure it's from The Gateless Gate (I recognize it, which means it's probably from there).

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.

The difficulty is you have to achieve traction and scale to compete with a company that's making tons of money exploitatively and user-hostilely strip-mining their own system and running on low margins with high reinvestment due to their scale and (stock market) reputation. Good luck.

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)

I'm not sure what exactly you're referring to, but as someone who's used Google since back when it had a bunch of serious competitors, I'd also pick 2008-2010 as about the time they stopped even appearing to match words with actions and became just another company, from an outside perspective, at least. It surprises me that people are just now forming this opinion about them.

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.

> HTML is the most popular language in the world.

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).

The most valuable ones mostly aren't ad supported or paid anyway, and without competition from ad supported sites even more free ones for more purposes would exist and thrive (e.g. if Reddit died all those free volunteer run forums that used to be such a big part of the Web would come back)

HTML did stagnate, in part because JS was available. How many sites expose the built-in file upload element these days? It's clearly terrible, yet hasn't improved in many, many years. Tables should have (optional) built-in sorting, obviously, but it's not there because you can just use Javascript. And so on. All they've done for, what, going on 20 years now, is prettify the tag names a bit. HTML is de-facto dead anyway, or at least on life support, just a supporting technology for a spying platform that's only there because no-one can be bothered to replace it with something better suited to that purpose. Meanwhile there's no safe-by-default way to browse hypertext. That's dead. Mixing it with app distribution already killed it. There's nothing there to lose.

I think a hypertext browser that, by default, lets any document you load also spy on your session as clearly as if there were a camera over your shoulder is nuts, but inevitable without harshly crippling any document-accessible scripting language available. Which is what should have happened. Most of the best things that JS provides from a user perspective could have been added to HTML and browsers themselves, e.g. better file/image upload, better tables, frames that don't suck, field validation. Mixing "apps" indiscriminately with hypertext browsing has left both in a pretty bad state.

Yeah, you'd have to prevent JS from catching a broad set of user events at all, and disallow modification of most of the DOM by it. Again, basically restrict it to tightly-context-constrained functions to do stuff like custom sorting. There'd still be security issues with it from time to time, but they'd be bugs rather than baked-in insecurity that's part of its feature set.

HTML stagnated badly and this was exacerbated by the "we can just let Javascript and/or CSS handle it" effect. With a less-free Javascript it'd have been necessary to add things like sortable tables and better form elements to HTML itself. Frames might have been improved to fix the various known problems with them, rather than abandoned. Social networks could still exist just fine and, judging from how things like Basic HTML Gmail or Craigslist or HN compare to more "advanced" websites, would have performed a whole lot better.

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.

> I was once asked by a client if we could capture people's email addresses in a sign-up form even if they didn't hit submit, so we could email them later. I am still quite proud of my response, which was, "Yes, we absolutely can! No, we absolutely won't help you do that!"

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.

I just want to be able to have multiple, suspendible desktop sessions with different apps running and/or installed and different files available. Ideally I should be able to kick up more than one at a time to let them exchange data. Preferably without having to run a full VM per session. Bonus points if I can ship them between physical machines, though I know that's a long shot.

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.

Seems like there's either a speed of light and things can happen before we see them, or light's transmitted instantaneously. Doesn't make sense to talk about light's speed if the thing producing the light doesn't "happen" until the light reaches the observer.