Maybe I'm stupid, but why is this tech needed now? Whenever I watch movies (new to me) if they're from before ~2005 I never need subtitles to understand, never mind genre or origin... and if they're more recent I frequently do. It's cool to have tools that highlight this for folks in industry, but how were they getting it right before that?
I think the complexity of audio has out stripped quality of speaker systems.
My guest room has a cheap 40inch TV the audio is terrible compared to the visual output. And I can play what feels like cinema quality 7.1 audio and 4K video over it. The result is the audio is terrible, tiny distorted. Muddy. Hard to understand if it's anything other than a voice over.
In 2005 the quality of whatever I was watching was crap but it was mixed knowing that it was likely going to be viewed that way!
That's been my conclusion admittedly based on not much.
I think a big key is channel management. You wouldn't buy significantly cheaper smaller audience content because it had to be big enough audience for the time it was blocking.
> such a degree of sacrifice wasn’t always associated with raising children
To a certain extent I agree with you that lower standards in parenting made the whole project more doable.
However, when my great-great-grandmother's brother's wife died, my great-great-grandmother had to quit school (about 14 or 15 years old?) in order to stay home to help take care of his baby. Shaped the whole rest of her life.
Responsibilities being split often meant others had to sacrifice in addition to parents, and those expectations of sacrifice often fell hard on women (whether young unmarried or past their own reproductive years).
> By designing a precise diet-controlled setting to rule out the effect of appetite suppression and weight loss induced by SG, we demonstrate a weight loss-independent mechanism.
why even pay for that, just use a free model from Opencode, most of them are pretty good for simple tasks. I haven't paid a cent in vibe coding for ages.
Small summary: external identifiers are hard to change, so projects will evolve such that they are not accurately descriptive after time.
(Less discussed there, but: In a complex or decentralized ecosystem, it's also the case that you come across many "X Manager"/"X Service"/"X State Manager"/"X Workflow Service" simultaneously, and then have to rely on a lot of thick context to know what the distinctions are)
I’ve been told multiple times in multiple jobs that I’m good at naming things, and I love whimsical names. A couple rules I’ve internalized are:
- if it’s hard to name, that’s a good sign that you haven’t clearly delineated use case or set of responsibilities for the thing
- best case for a name is that it’s weird and whimsical on first encounter. Then when somebody tells you the meaning/backstory for the name it reveals some deeper meaning/history that makes it really memorable and cements it in your mind
- the single best tech naming thing I’ve encountered (I didn’t come up with it) was the A/B testing team at Spotify naming themselves “ABBA”
God this article is 10000% better than the posted one. This is great:
> Names should not describe what you currently think the thing you’re naming is for. Imagine naming your newborn child "Doctor", or "SupportsMeInMyOldAge". Poor kid.
I totally agree with this, and will add that another benefit of whimsical names is discoverability. If your project is named plugin-update-checker and I want to find documentation on it, it's likely going to be buried in a bunch of other irrelevant search results about plugin update checkers in general. If it was called SocketToMe instead, I'm going to find much better search results.
I suppose it depends on your goals, but that scope restraint can be a good thing.
Do one thing, do it well, and while you're at it call yourself by the thing you do so you remember that's what you ought to be doing. A bit wordy for unix but you get the idea.
1 week is fascinating. Was it like – the missing piece was modern version control/CD? What kind of testing would need that? (We have configs at work where the system interactions are so unknowable and the financial implications of reduced efficiency so profound that we have to run multi-week A/B tests to change values) Was it some kind of pathological documentation culture?
AFAIR, there were two aspects to testing. The code change itself obviously only took tens of minutes, if that. First round of testing was just the build test, and that was fully automated but I think there were independent builds for multiple different hardware variations and so the total time for that was several days. Then there was actual use-case testing ... I wasn't involved in that at all, but was told it would also take several days of actual testing by a QA team.
