Kim Auerbach

One rule that has served me well: never let hardware belonging to one employer touch a network path controlled by the other. No sharing a VPN, no tethering machine A through machine B, no shared cloud drive as a scratch space. Two separate stacks that never meet, even when it's inconvenient.

Two to four seconds of PDF generation in a request also means one slow user can occupy a web worker that someone else needed. At 300 users nobody notices, and the day you get a burst of traffic the whole app appears to be down for reasons that have nothing to do with the traffic.

The hard cap is the part that works. Without a number it's just a preference and it drifts back to 240 in a year.

Check the Domain attribute too. If your backend is setting Domain=api.example.com explicitly and your app runs on app.example.com, the browser will store it but never send it to the app's requests. Either drop the attribute so it defaults to the host that set it, or set it to the parent example.com.

Agreed, and daily standups are usually only the first collision. Sprint ceremonies, planning, retro, all-hands. The 9:15 thing is a preview.

Citations also move constantly. Mass digitisation of newspapers has pushed hundreds of first dates earlier in the last twenty years, and amateurs find a good share of them. If a date looks late to you, it might just be waiting for someone to search the right archive.

Also why a brand new account gets longer holds on everything for the first few months. It's not personal, there's just no history to compare against.

The planner is walking backwards down the created_at index and throwing away every row that isn't your tenant until it collects 50. For a tenant with 40% of the table that's quick. For a tenant with 0.1% of the table it reads millions of rows to find fifty, which is why small tenants are slower. That inversion is the signature of this exact problem.

You want one composite index in the order the query needs:

create index concurrently on events (tenant_id, created_at desc);

Then the equality column narrows first and the sort comes free from the index order. Your two single-column indexes can't do that, the planner has to pick one and pay for the other half.

Drop the standalone tenant_id index afterwards, the composite covers everything it did.

Rule of thumb that gets you most of the way: equality columns first, then the range or sort column, then anything you're only selecting. And build them with concurrently on a live table unless you enjoy explaining a lock to your colleagues.

The one that actually keeps my fridge from smelling is sealed containers. Glass with a clip lid for anything strong, and cover cut onions and cheese rather than putting them in on a plate. Smells move between foods more than they build up in the air.

Ancient sculptors and masons did use wax and marble dust to fill flaws, that part isn't fiction. The leap is from a real practice to a phrase nobody wrote down. Someone with the practice in mind produced a nice explanation and it travelled.

Mild disagreement from the boring corner. If your photo editing means 60 megapixel raw files and 40 layers, 32GB is a real quality of life change and you'll notice it every day, whereas the extra GPU tier gets you frames you may not be able to see. If it means cropping phone photos, ignore me and buy the GPU.

True, but four months of runway is thin for betting on that. I'd want eight before I'd let go of the coverage.

Good call. Two of my shortlist are blocked on the work machine, which settles it faster than any feature comparison would have.