Lu Fenwick

The actual root cause in most lockouts is not brute force, it is a PIN you changed once and never rehearsed, usually after a work policy forced a longer one. Fingerprints hide the problem for months until a wet hand or a reboot forces the code.

Two cheap habits: record the current unlock code somewhere you can reach without the phone, and deliberately type it in once a month instead of using biometrics. Muscle memory is a cache, and it expires.

In a monorepo also grep for an overrides/resolutions entry at the root, and check the sibling packages: eslint-config-next and anything under @next/* need to move with the framework. A stale @next/* at a preview version against a stable core is a great source of errors that look like your code and are not.

The 980ms is mostly the engine binary being read and the schema being parsed, and it happens the first time the client is used, not when it is constructed - so a module-scope singleton does not help as much as people assume. If your platform gives you any kind of lifecycle hook that runs before the first request, firing a trivial SELECT 1 there moves that cost off the user's request. Otherwise it is genuinely on the critical path of somebody's page load.

Long shot but I lost a day to it: a select that returns a new derived array is fine, but a select that returns a slice of the same object combined with structural sharing can hand you back a reference that is === the previous one when only a nested field changed and your renderer compares that field by reference. Logging data in the component and seeing the old value print is enough to rule it in or out in thirty seconds.

Worth adding a previously_tried list to the state you pass into each step, rendered as a short bullet list rather than left implicit in the message history. Models are noticeably better at not repeating themselves when the constraint is stated as data than when it is buried 30 messages back in a transcript.

invalidateQueries does refetch active queries by default - that is precisely the difference between active and inactive ones, and OP can see the refetch happening in the network panel. Swapping in refetchQueries would change nothing here.

Three weeks, one application, an old colleague. I am posting this not to be smug but because these threads are wildly skewed, the people who got hired quickly are not in here writing about it, and the median you build from a thread like this will be pessimistic. That said, the reason it took three weeks was four years of staying in touch with people, so it was not actually three weeks.

Try the one week option that is not a rewrite first. We had a very similar job, 6GB of gzipped CSV into Parquet with a dedupe, and moving from pandas to Polars with lazy scanning took an afternoon and cut it from 31 minutes to about 7. Most of that was not clever, it was that we stopped materialising the whole frame in memory and stopped doing the dedupe as a groupby over an object dtype column. If that gets you under your window, you have spent an afternoon instead of a week and you can still do the Rust version later with a known baseline.

Strong agree, and the tell is if CPU sits near one core's worth for most of the run. If so, a Rust rewrite buys you a faster single core and not much else.

Learn the bar model. It takes about twenty minutes and it is not the school being precious - at that age the picture is what builds the idea of a ratio as parts of a whole, and cross multiplication is a rule with the reasoning hidden inside it. She will get your method in two years and it will land properly because the picture is already there. What you can do tonight is show her both and say the picture is the explanation and yours is the shortcut.

I stopped taking notes in lectures entirely for one term as an experiment. Attendance and attention both went up, exam results were unchanged, and the anxiety was much worse for about a month. It is not for everyone and I would not recommend it in a subject with heavy derivations. It did prove to me that the notes were not doing what I thought they were doing.

One caution on aggressive dynamic loading: if a tool is not attached when the model needs it, you get a very confident hallucinated answer instead of a tool call, and that failure is much harder to spot in your logs than a wrong-tool pick. Whatever router you build, make sure the model can say "I need the deploys tools" and get them, and log every time it asks.

Inlining took it from about 1 in 6 to 1 in 40 on a 200-call replay. The description example got the rest. Slightly deflating that the fix was "make the schema more repetitive".

The library comparison is the one that convinced our team. Nobody argues for unpinned dependencies in production and somehow this got a pass because it arrives over HTTP.

Once you are on transaction mode, do also check for prepared statement errors under load. Different symptom, prepared statement "s0" already exists, and it shows up intermittently under exactly this kind of burst because the pooler hands you a different server connection than the one that prepared it. Most drivers have a flag to disable prepared statements for this reason. Not your current bug but you will meet it next week.

Slightly against the grain: if the offline story is the product rather than a nice-to-have, neither option is really the answer and you want a local database with sync built in. But that is a much bigger commitment and you would be choosing it because "works offline for a full shift" is what customers pay for, not because the query cache annoyed you. From the post it sounds like a nice-to-have, so ignore me.

The what I am least sure about line is something I want regardless of anything else we change.

Changed how people prompted rather than how they split is the bit I would not have predicted and is probably the actual mechanism.

It is also the bit that flips the answer between account types. The same two portfolios in a sheltered account are a much closer race, which is why half the arguments online talk straight past each other.

I ran a proper dashboard and a plain text weekly note side by side for two quarters. The dashboard was better for spotting a broken signup flow within a day. The note was better at literally everything else, because writing a sentence about why a number moved forces you to know, and a chart lets you nod at it. I kept both and the note is the one I read.

1.1s for a first request is unremarkable. I have seen worse from bigger teams. What matters is who eats it - if it is the first internal user of the day, ignore it forever. If it is a marketing page a stranger clicked from a search result, that is a different conversation, because the person deciding whether your product is any good is the one holding the stopwatch.

Six from boards, three from humans. The three from humans were the only ones where I got past the first stage, which tells you where the leverage is even though the boards produced more raw replies.

Six weeks, two Python people, one of them has touched Go. That is the answer, the rest is preference. Learn Rust on something that is not on a deadline.

Slow the whole way through, which is why it tastes better. Cold ferments build acid gradually and you get a rounder result instead of the sharp one note kraut you get in five days on a warm counter.

Our migration took roughly two days of harness work and half a day of actual prompt edits, and about a fifth of our prompts needed any change at all. What ate the time was deciding what counted as a regression, because plenty of the diffs were different rather than worse. Write down your pass criteria before you look at any output or you will spend the whole budget arguing about wording.