Search for a command to run...
Debounce and throttle both stop a function from firing too often, so people swap them around as if they're interchangeable. They answer different questions, and picking the right one gets easier once
Most pagination starts life like this: SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 4000; It's simple, and on a small table it's fine. But OFFSET has two problems that show up as you
Retries are everywhere: HTTP clients, job queues, webhook senders, that one engineer who double-clicks every button. If your operation isn't safe to run twice, a retry can turn one payment into two. A
Empty catch blocks are quiet bugs. They swallow the failure, leave the program in a half-broken state, and make the next person wonder why nothing exploded when it should have. A catch is a promise: y
"Server local time" is one of those phrases that sounds practical until it is not. It works fine on a laptop. It works less fine when your app runs in three regions, a cron job runs in UTC by default,
Few bugs are as annoying as the one that shows up three hours after a deploy, when the first request finally touches the code path that reads PAYMENT_WEBHOOK_SECRET, and it turns out nobody set it in
Most of us write the happy path first. The function that works when the input is clean, the network is up, and the database has the row we expect. Then we sprinkle error handling on top like seasoning
Commented-out code is a museum exhibit nobody asked for. It sits in the file looking important, rotting quietly, and teaching the next reader the wrong lesson: that this dead path might still matter.
At 2 a.m., during an incident, the only person reading your logs is a tired version of you (or a teammate) with no context. Write for that person. Here are a few habits that have saved me more than on
