Two Calendars

I will be the dissenting voice: I think the requirement you have described argues against buying this category at all. You want a firmness you can change and no dependency on a company existing in ten years, and that is a latex or foam mattress with a firmness you chose plus a topper, for less money and with nothing to pair. I went from an adjustable air bed to 20cm of latex over a slatted base and the only thing I miss is being able to change my mind at 2am, which I did roughly four times in three years. The pump is a single point of failure attached to a company's support policy.

That last sentence is the thing I hadn't thought about and it's obviously what would happen.

The pre-defined restart is underrated. When I've missed a week the paralysis is entirely about what the first session back should be, and having one written down removes it.

Three people means your budget for weird problems is roughly zero. Pick the tool where an error message is already answered somewhere, and spend the risk budget on something a customer can see.

That is not a knock on bun. It is an argument about where a tiny team should spend its bad days.

Seconding the split. We also use bun for one-off scripts because it runs TypeScript directly with no build step, which deleted a whole tsx dependency and a bunch of config. That is a real quality of life gain that carries no risk, because those scripts do not ship.

I repeated the several years figure at work once and got taken apart by someone who had read the follow-ups, which was embarrassing and educational. What I learned: whenever a health claim comes with a clean round number attached, the number is usually the part that did not survive replication.

If you do go shared, know the escape hatches before you need them, because you will need them. You can host a native view inside the shared UI, and you can host shared UI inside a native screen. Both directions work.

The part people underestimate is state across the boundary - a native camera view that needs to write back into shared state is more plumbing than you think, and it is the kind of code nobody wants to own. Budget for a few of those rather than assuming zero.

Second the "do not let one flow drive it". Every cross-platform decision I have seen go wrong was justified by a single hard feature that turned out to be 3% of the codebase.

Fair, and the two are not exclusive. A well-fitted feed tolerates a warm train with a half-empty barrel, a badly seated one does not. Worth checking the cheap thing first though, which is filling it fuller for a week.

I did an evening group class for two terms and then switched to a private tutor for the last stretch, so I can compare directly. The group class was much cheaper per hour and about a third of the time was other people's questions; the tutor cost more and every minute was aimed at my specific mess, which for German meant cases and word order. My rule now: group classes to cover ground, private hours to fix what is actually broken, and do not pay tutor rates for vocabulary you could learn on the bus.

Change what you're doing before you change the friendship.

Stop holding the evening. Say yes, and also make a fallback plan you'd be happy with, so a cancellation costs you nothing. Then shift to things that are cheap to cancel: a walk, a coffee near their place, something in a slot you'd be out for anyway.

Separately, and once, say the plain thing. "The last few plans have fallen through late and I've stopped counting on them, is something going on?" Said without heat that's a question rather than an accusation, and their answer tells you which friendship you actually have now.

The strap tightness thing is real and almost nobody controls for it. Mine reads completely differently on the finger I usually skip.

I will defend trends, though not absolutes. I could not have told you that two drinks in the evening cost me something without the data, but the pattern was so consistent across dozens of nights that I believe the direction even if the minutes are made up. Same with a late heavy meal. Use it as a diary that fills itself in, not as a diagnostic.

Counterpoint from the other side of this: we split too aggressively and ended up with 40 packages where a single feature touches six of them and every PR is a version-bump ceremony. There is a middle. Split when a change to one part keeps forcing rebuilds of consumers who do not care about that part, not on principle.

Worth internalising the distinction: "affected" is about the dependency graph, "changed" is about git. Most tooling gives you both and people conflate them. You want changed for deciding what to cache, affected for deciding what to verify.

The he-should-say-it part is doing a lot of work. Every version of this I've seen where the partner delivers the message to their own in-law goes better, no matter how kindly the other one phrases it.

Taken too literally. The guidance says hoist to the lowest common ancestor of everything that reads or writes the state, and people read it as "hoist to the top".

If a toggle's value is only read by one row, its state belongs in that row. It gets hoisted when something else needs it - a save button that must know the value, a validation message, whatever. Not before.

For the ones that genuinely do belong at the screen level, the standard shape is a state object and a single event channel:

data class SettingsUiState(
    val notificationsEnabled: Boolean,
    val theme: Theme,
    val syncOverCellular: Boolean,
)

sealed interface SettingsEvent {
    data class ToggleNotifications(val on: Boolean) : SettingsEvent
    data class SetTheme(val theme: Theme) : SettingsEvent
}

@Composable
fun SettingsSection(
    state: SettingsUiState,
    onEvent: (SettingsEvent) -> Unit,
)

Two parameters instead of eleven. Adding a new setting changes the data class and the sealed interface, not every signature between the screen and the row.

The cost is that onEvent is less explicit than a named callback, so a leaf can now emit any event. In practice that has never caused me a problem, and eleven-parameter signatures caused me problems weekly.

So: your instinct is right. It is a real smell, and it is the most common way people over-apply the pattern in their first months.

Same conclusion at my last place. The tell was that every incident review had a line saying staging didn't have this data. After the fourth one we stopped pretending.

Shoulders, bust, waist, sleeves. I've been doing them in whatever order the problem shouted loudest, which explains a lot.

Fourteen months and no fights is the part I'd look at, honestly. Not because fighting is good, but because most couples have found a couple of real disagreements by then. If you've both been avoiding them, the flatness might be that rather than the timeline.

Five weeks is early, and nightly habits are slower than morning ones because your evening is more variable: different times, different tiredness, sometimes not even home. Morning habits automate faster almost entirely because the context is more consistent.