298 karma · joined July 3, 2023
This is useful for segregating groups of work related to a set of files but I would be interested if there's anything for arbitrary unsaved buffers in general.
A side effect (and the end result) is that we all end up having poor [Bayesian priors](https://en.m.wikipedia.org/wiki/Prior_probability) in our heads - this disproportionate reporting practice at large impacts our understanding of the world, as you describe. And I bet there's a feedback loop: the more skewed our model of the world, the more we will produce/consume skewed content.
I think this is not something you can ever truly do completely away with because of the many factors that it arises from, not limited to our psychological biases that tend us towards liking or interacting with certain form of content more than others... but certainly there should be more controls.
What's screwed up right now is we are currently forced to rely on 3rd-parties to filter for us, and they do so often poorly by just dropping content that's not "popular" which results in biased sampling, or worse, they select based on some kind of profit motive. Why can't we own our own "social media algorithm" or something? Why do I have to spend so much time consuming? Give me the IV drip, and filter out the unhealthy portion, please. Ideally, I should be able to trust the filter, too.
There's not enough pure veggie dishes out there. I've been turning to Indian cuisine because they're the few options that don't have their entire veggie menu be "fake burger, fake hot dog, fake chicken nuggets, salad". It's like we can't conceive of eating a meal unless it has meat in it.
Why do we have to set the time on our clock radios or on our microwaves or whatever? Why don't they just always use this Tech. I don't understand. All you have to do is allow people to store an offset for the time zone, and RTC issues are a thing of the past.
In the "frictionless environment, ideal world" scenario - requirements should always be completed as close to the letter as possible and no further.
In the practical scenario, requirements should be written as close to perfect as can be achieved where perfect is defined as what is necessary to resolve your problem space, limited by your understanding of the problem space.
In any project, resources (time, money, etc) are limited so the most successful project will be one that uses resources most efficiently. So good explicit requirements allow you to determine the most efficient manner to achieve them as they codeify the problem and give you goalposts to optimize within.
This all relies on you being able to set good requirements from the outset, which can be done by understanding what you're setting out to achieve (the problem you're trying to solve).
I have a comment in this thread which discusses the consequences of this rule specifically. https://news.ycombinator.com/item?id=37069168
The R100 design was "competing" with the design for the R101; both design teams were simultaneously tasked with constructing a viable airship to make a long-range trip (in the case of R100, crossing the Atlantic in 78 hours, which was a remarkable achievement for the time). The difference was that the R101 project was state-owned whereas the R100 was privately-owned.
R101 crashed and burned in France, en route to India on 5th of October, 1930, likely due to structural issues damaging the airships gasbags, of which the only survivors were those lucky enough to be in the engine cars.
In the autobiography, Norway describes how the difference in program management led to the disaster. There are a lot of factors that led to the crash, as you might imagine, but one of the points he makes is that the publically-owned project was not held to strict requirements in its design process. The privately-owned R101 had a strict contract that they needed to complete, with a tight budget to complete it. They had constraints. Whereas the public-sector project was allowed to continually revise their design as they went, making many successive rewrites and changes without much structure. In particular, they cut the ship in half and rebuilt it at one point in it's development. And when they arrived at the end of their development cycle, they had no leeway to maneuver because they had a lot of public money wrapped up in the project, along with a lot of public visibility and responsibility, pressuring them into rushing the launch without complete trust in their design, and into terrible weather conditions.
*13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.*
Decide/envision your outcome, and set your constraints correspondingly early on in development, aligned with realistic expectations of resources, folks.
To underline my point, here's a quote from the Wikipedia page.
"Shortly before R101's flights in June 1930, the Cardington [R101] engineers tentatively suggested that the long flights to Canada and India might be postponed until 1931 on the grounds that neither of the two airships was fit to make a lengthy flight at their current developmental stage. The R100 team replied that their airship was perfectly capable of flying to Canada, and that the Canadian flight was a part of their contract."
R101 did not have a contractual obligation to meet, but did not want to outright state they needed more time, lest admit defeat. R100 had requirements that they needed to meet, which they were ready to meet, as they had them written from the start in clear. R100 launched successfully. R101 was forced to launch to compete before it was ready, due to this "spontaneous requirement". R101 burned for it.
Perhaps we can design a new character system script specifically designed for ease of programming! I say we use Aurebesh. :)
It is important for the public to learn - and they will need assistance to understand findings that are outside of their usual realm of knowledge/experience. Unfortunately, the resources for this are shaky, profit-motivated, and arbitrary.
Why isn't there just one giant firehose API which merges all the socials into one intake feed. Then I could filter it down for useful data and discard the rest. This probably already exists, but, just my thoughts from the article!