I used to take this approach when building new integrations. Then I realized (1) most documentation sucks (2) there's far too much to remember (3) much of it is conditional (4) you don't always know what matters until it matters (e.g. using different paths of implementation).
What works much better is having an intentional review step that you come back to.
Most of the time QA can tell you exactly how the product works, regardless of what the documentation says. But many of us haven’t seen a QA team in five, ten years.
You say this like trivial misstakes did not happen all the time in classical engineering as well.
If there is a memory leak, them this is a flaw, that might not matter so much for a specific product, but I can also easily see it being forgotten, if it was maybe mentioned somewhere in the documentation, but maybe not clear enough and deadlines and stress to ship are a thing there as well.
Just try harder. And if it still breaks, clearly you weren't trying hard enough!
At some point you have to admit that humans are pretty bad at some things. Keeping documentation up to date and coherent is one of those things, especially in the age of TikTok.
Better to live in the world we have and do the best you can, than to endlessly argue about how things should be but never will become.
Shouldn't grey beards, grizzled by years of practicing rigorous engineering, be passing this knowledge on to the next generation? How did they learn it when just starting out? They weren't born with it. Maybe engineering has actually improved so much that we only need to experience outages this frequently, and such feelings of nostalgia are born from never having to deal with systems having such high degrees of complexity and, realistically, 100% availability expectations on a global scale.
They may not have learned it but being thorough in general was more of a thing. These days things are far more rushed. And I say that as a relatively young engineer.
The amount of dedication and meticulous and concentrated work I know from older engineers when I started work and that I remember from my grand fathers is something I very rarely observe these days. Neither in engineering specific fields nor in general.
We were talking about making a missile (v2) with an extended range, and ensuring that the developers who work on it understand the assumption of the prior model: that it doesn't use free because it's expected to blow up before that would become an issue (a perfectly valid approach, I might add). And to ensure that this assumption still holds in the v2 extended range model. The analogy to Ariane 5 is very apt.
Now, there can be tens of thousands of similar considerations to document. And keeping up that documentation with the actual state of the world is a full time job in itself.
You can argue all you want that folks "should" do this or that, but all I've seen in my entire career is that documentation is almost universally: out of date, and not worth relying on because it's actively steering you in the wrong direction. And I actually disagree (as someone with some gray in my beard) with your premise that this is part of "rigorous engineering" as is practiced today. I wish it was, but the reality is you have to read the code, read it again, see what it does on your desk, see what it does in the wild, and still not trust it.
We "should" be nice to each other, I "should" make more money, and it "should" be sunny more often. And we "should" have well written, accurate and reliable docs, but I'm too old to be waiting around for that day to come, especially in the age of zero attention and AI generated shite.
I watched both; both are good, in different ways. Some scenes that I remember being beautifully composed in 4:3 lost to the transition, while others have improved markedly.
They made a ton of effort on it, recognising it's a different version altogether:
> The new version of The Wire, then, will differ both creatively and technically. In certain cases, such as a scene in season two where longshoreman gather around a body, Simon said he believed the added space would add a vulnerability to the scene that wasn’t possible in 4:3. But he describes other scenes where the added space distracts the eye, and the remaster zooms in on the characters to retain that intimacy.
> I said there was no way this truck would pass a pedestrian impact safety standard. Now, I wasn't wrong that the truck won't pass a pedestrian impact safety standard, it won't! And that's why they can't sell it in Europe. [...] But I didn't realise that America has no pedestrian impact standards. [...] America actually allows companies to self-certify a variety of aspects of safety.
See also: Boeing. It is the exact same kind of fuck-up. Regulators should not be in bed with the industries they regulate. That's a hard problem to solve, because where if not in industry would you get the expertise. But these kind of revolving door arrangements are extremely problematic.
Even the much-maligned raid5/6 is basically fine†.
If you're concerned about the write hole, use -m DUP/raid1/raid1c2 instead of -m raid5. Plus raid-stripe-tree†† is coming - didn't check the status of it recently.
Many horror stories are because, while btrfs is fine, the operational model and tooling have some footguns which can cause either straight up data loss (due to operator error, but arguably that's really due to bad UX) or possible-but-hard-to-get-out-of situations.
I use btrfs because using zfs has been painful for me, for two reasons:
- btrfs can "shapeshift": I progressively moved _live_ from 2hdd raid1 to 5hdd raid5 data + raid1c2 meta with varying experiments in between. Probably five or six rebalance to change its shape over the years.
- the zfs module situation: when I tried it, the module silently failed to build properly and this resulted in a broken system til I fixed it; this happened twice over six months. Luckily I anticipated this failure mode and only the data array (not the root fs) was zfs, so I could still boot and login into a full system to fix.
Compared to zfs, btrfs is slow to scrub and rebalance though.
I realise this may probably boggle the mind of the modern software developer.
reply