> We don't have height categories, we have categories based on sex.

I mean, we do have weight categories in combat sports, right? I don't see why we couldn't come up with similarly neutral categories if we think it's good to segment people out by physical advantages. The parent comment is making a good point, though: it feels like some people care a lot about physical advantages that map onto gender stuff they care about, and not a lot about weird genetic anomalies that provide physical advantages that aren't gendered.

We could do that! I'm just trying to say that given categories based on (biological) sex, we should find some criterion based on biological sex to sort people into said categories, which the OC decision seems to do (at least better than the alternatives I have encountered). I don't have a problem at all with finding different ways of defining categories for competitions.

Re: anomalies - I think this is just unavoidable in any sort of category system, and I don't have a good solution for it except to consider frequency and severity.

I am in the same boat. Reading is a transaction and lately everyone wants to put 60 seconds of effort into writing an article and expect me to put 10 minutes into reading it, and I just can't. The writing feels dead, soulless even. Every sentence or phrase is structured like a mongering, click baity headline and it's insufferable.

I'm always interested in write-ups when folks try new attacks on self-study.

I will also admit that this part hurt my heart to read (vicarious embarrassment):

> the recruiter mentioned I needed to pay more attention to code debuggability (whatever this means - I assume that under the corpo-language, they mean that I wrote invalid code)

I completely understand why that line caused vicarious embarrassment. Looking back, I realize my brain was(is) operating on a completely different definition of that word based on my daily constraints. I plan to write more about this in Part Two, but at that point in time, I wasn't even aware of this alternative understanding of the term.

In telco, when a remote node crashes at a client's site, I often only have access to a heavily restricted subset of logs, and the debugging communication loop via email can take days to understand "what happens". Because of that, I write defensive, strictly encapsulated code, and I think in terms of domain-specific states and objects that can be explicitly tracked from an external PoV.

Similarly, during game jams, "debuggable and maintainable" means to me that the code is modular enough that I can completely rip out and rewrite a core mechanic in the final 3 hours just because the game design suddenly changed.

My habit of writing code optimized for remote logs and sudden architectural shifts actually became my biggest enemy under the algorthimic interview (or 45-minute LeetCode) constraint. It makes the core algorithmic state less clear and hides algorithmic mistakes under layers of defensive "if" statements (where I would normally drop a debug log).

I am simply used to not trusting the inputs, whereas in algorithmic problems, the whole point is to exploit constraints that you need to be absolutely sure about.

So the "if" statements that usually increase "debuggability" in telco or during game jams are the exact opposite of the "debuggability" term used in algorithmic thinking.

Thanks for naming this issue so clearly - it is a very valid reality check.

This is so cool! I would love to hear what stavros ends up using it for – actually, in general I'd love to hear more about how folks are using voice recorders. It seems like now's really their moment as STT finally doesn't suck too bad and natural language can actually be turned into stuff.

I use it to talk to my LLM assistant! It's great, it's always there, always works, and it's very accurate, as you say.

I've been quite surprised, it even does Greek very well!

Maybe it's a silly question, but what are you using the assistant for? I love the idea of voice interfaces. Matt Webb's thing about distinguishing data and instructions by addressing "Diane" (https://interconnected.org/home/2025/03/20/diane) to work through a more substantive task by talking has some magic in it. And yet I've rarely gotten more use out of these things than, you know – toggling lights, setting timers. Plugging them into more meaningful integration seems really interesting.

It's a lot of tiny things, for example having all my info in one place when I go traveling, and being able to say "how do I get to the Airbnb from the airport". Yesterday I had the agent search for events in my city every week, find the ones I like and put them in a newsletter that it emails to me. I also had it look at my book history and ratings and recommend new books. Tracks my gym sessions, what restaurants I like and what I want to get next time, etc.

Nothing you can't live without, but it reduces the thousand little paper cuts of daily life by a lot.

> If the payment service went down because a config value was wrong, the incident report should say: the payment service went down because config value X was set to Y when it needed to be set to Z.

The number of junior engineers I have had to coach out of this way of thinking to get the smallest fragment of value out of a postmortem process... dear Lord. I wonder if this person is similarly new to professional collaboration.

The larger personal site is very aesthetically cool, though – make sure you click around if you haven't!

Yeah, I wonder if the author has been in a situation where a brief explanation was taken by a higher up (or a cc'd higher-up x2, or x3) as "It was entirely my fault and I'm withholding details that would further implicate me and giving only the facts that don't."

I've had to work to balance emails like this between "they don't want the nitty gritty, they just want to be satisfied the issue is solved" and "They will definitely want the nitty gritty and think something is up if the details seems suspiciously sparse". Especially if the recipients are technical, and they know that you know that they're technical. what are you hiding, Qaadika? you're usually more verbose than this.

What's the mistake here? Shouldn't an incident report start with this and then continue with an analysis of the process, without too much "internal perspective"?

In my mind, the internal perspective might be useful to jot down when doing the analysis, but is too noisy to be useful to disseminate.

So I know it's a little bananas to answer this with a link to material the length of a novel, but my feeling is that the real spirit of a postmortem is best carried across by:

https://www.hillelwayne.com/post/stamping-on-eventstream/

He goes through the process, which he describes:

> The constant zooming-out is key here: it’s not enough to find out why things broke, but find out why “why things broke”. In theory you’re supposed to keep doing it: if someone skips a step because of managerial pressure, you ask why the manager was pressuring them in the first place. If the manager was worried about production quotas, find out how the quotas were decided. You just keep going and going and going.

There are different procedures folks can use to capture bits of this to different degrees, but I think this write-up illustrates well both how exhausting it is to do this right and what the value can be. Even if your goal is to get to Action Items, this kind of understanding of your event is what should generate them.

If a person doesn't understand the value, I would imagine they would write something very close to TFA's

> when something goes wrong [...] they explain why they made the decision, and then explain the contextual factors that influenced that, and then explain why those contextual factors existed, and then explain why it would have been unreasonable to expect them to anticipate the downstream effect of those factors, and by the end you have some fat five paragraphs that contains maybe one sentence worth of information and reads like a legal defense brief written by someone who knows they are guilty.

"Daylight Saving Time" refers to adjusting the time in a way that noon does not try to track solar noon for a timezone in order to shift daylight later in the clock-day.

Tracking solar time would mean it's equivalently light out at 5AM and at 7PM. Nearly noone is awake at 5AM. Nearly everyone is awake at 7PM. You can wave your arms around and say "well then why don't people wake up earlier", but they have jobs and stuff. The "scientific evidence" for standard time is flimsy.

People did wake up at way earlier. Working hours have shifted past by a few hours during the last century, so it seems like people actually prefer that.

If we were trying to adjust the time to track the solar time, wouldn't we need to adjust the clocks every day as days get shorter/longer? I keep seeing this in every post discussing Daylight Savings. What's the obsession with tracking solar noon?

> If we were trying to adjust the time to track the solar time, wouldn't we need to adjust the clocks every day as days get shorter/longer?

No (not within a min or two). When days get shorter, it's not like they just lose daylight in the evening.

> If we were trying to adjust the time to track the solar time,

No, but

> wouldn't we need to adjust the clocks every day as days get shorter/longer

This is how hours used to work at least in Roman times, but I think also into the Medieval Ages.

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.

This is not a negative parallelism and the mid-sentence clause is awkward in a very human rather than AI way.

kind of a "yes, and", but:

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

FTFA:

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