none of them honestly. i'd rather keep shipping for five clients than bet a year on one idea i didn't pick myself.

added a meeting to Monday and it showed up on all 7 days of the week the grid was built with Array(7).fill([]) looked fine. 7 empty arrays, one per day except fill doesn't make 7 arrays. it makes one array and puts the same reference in all 7 slots, so pushing to Monday pushed to Sunday too took 40 minutes to find because my tests only ever added one meeting and checked one day Array.from({ length: 7 }, () => []) fixed it fill is great for zeros and terrible for anything you plan to change later

a user wrote in 4 times saying they couldn't remove their phone number clear the box, hit save, green "saved" toast. reload. the number was back the form set phone to undefined when the field was empty. JSON.stringify quietly drops any key whose value is undefined, so the PATCH body never mentioned phone at all the server saw nothing to change and kept the old one swapped undefined for null and it worked first try null means "make this empty". undefined means "I didn't say anything". JSON only has a word for one of them

a user couldn't save their display name. "too long", the form said the limit was 20 characters. they had typed 12 9 letters and 3 flag emojis in JavaScript a flag is two regional indicator symbols, and each one takes 2 UTF-16 units. so a single flag has a length of 4 9 + 12 = 21 the fix was counting with Intl.Segmenter, which counts what a person actually sees on the screen "how long is this string" has at least three right answers, and the default one is the wrong one for humans

my sync script said a Notion database had exactly 100 rows it had 1,342 no error, no warning. status 200 and a tidy list of 100 pages, so I believed it for 3 weeks then someone asked why most of their entries never showed up anywhere the API returns 100 at a time with a has_more flag and a next_cursor for the page after. I never checked has_more the fix was a 6 line while loop now any count that lands on exactly 100 makes me nervous before it makes me happy

a customer couldn't pay for a $19.99 order. the $9.99 and $29.99 ones went through fine Stripe kept rejecting it with "invalid integer" I was sending the amount as price * 100 19.99 * 100 in JavaScript is 1998.9999999999998 floats can't store most decimals exactly, so a few prices land a hair under the cent. 9.99 and 29.99 happen to round clean, which made it look random Math.round fixed it in one line storing money as integer cents from day one would have meant nothing to fix

set a Christmas sale to start with new Date(2026, 12, 25) tested it by faking the clock to December 25th. no banner faked it to January 25th. banner JavaScript months start at 0. January is 0, December is 11. so 12 isn't an error, it just rolls over into the next year no warning, no exception. a perfectly valid date, one month late the fix was typing 11 and feeling a bit stupid the calendar has 12 months. JavaScript has 0 through 11 and a lot of confidence

a user wrote in asking why they had two accounts with the same email they didn't, technically. one was all lowercase. the other started with a capital P because their phone capitalised it at signup my unique constraint on email did its job. Postgres compares text exactly, so P and p are two different people 38 users had done the same thing over 2 years the fix was a unique index on lower(email) and a very boring merge script the database was right all along. humans just never type the same thing twice

my signups chart showed a spike at 1am this morning. about double a normal hour no launch, no tweet, nothing. I went looking for a bot it was the clocks. the UK went back an hour at 2am, so 1:00 to 2:00 happened twice the chart grouped by local hour, so two hours of signups landed in one bar the fix was boring. bucket everything in UTC and convert only the labels nothing was wrong with the data. the day just had 25 hours in it

wrote a retry wrapper for a flaky API. 3 attempts, exponential backoff, the works it never retried once the API returned 503s for most of an afternoon and my logs said success fetch only rejects when the network itself fails. a 500 or a 503 is a perfectly good response as far as fetch is concerned my try/catch was waiting for an error that was never coming one line fixed it: if (!res.ok) throw new Error(res.status) the retry logic was fine. nobody ever told it something went wrong

a leaderboard I wrote put someone with 9 points in first place, ahead of someone with 100 the code was one line. scores.sort().reverse() JavaScript's default sort compares everything as strings so [9, 10, 100] sorts to [10, 100, 9]. "9" lands after "1" the same way "z" lands after "a" every test passed because every test score had two digits the fix was scores.sort((a, b) => b - a) it took 4 minutes to fix and 3 weeks for anyone to notice

wrote a query to find users who never placed an order SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders) 0 rows. we had 4,000 users and maybe 1,200 had ever ordered no error. the query was fine. the data wasn't one guest checkout in orders had a NULL user_id NOT IN checks id <> each value in the list. id <> NULL isn't true or false, it's unknown, so not a single row gets through NOT EXISTS skips the NULL and gave back all 2,800 one NULL in one row erased the whole answer

I scheduled a reminder email for 30 days out with setTimeout it went out 4 milliseconds later. to 40 people setTimeout keeps the delay in a 32-bit signed int. the biggest it takes is 2,147,483,647 ms, about 24.8 days go past that and Node sets the delay to 1. it does print a warning, on stderr, which nobody was reading 30 days is 2,592,000,000 ms. too big by about 5 days now anything longer than a few minutes is a database row with a due date and a job that checks it a timer is not a calendar

my script saved tweet IDs to a JSON file and every lookup after that came back 404 the IDs looked fine. 19 digits, same length as on the site they weren't. 2113619830578241578 went in and 2113619830578241500 came out JSON.parse turns every number into a JS double, and a double only holds whole numbers exactly up to 9,007,199,254,740,991. past that it rounds and says nothing no error. just a real looking ID pointing at a tweet that doesn't exist now IDs stay strings from the first fetch to the last write there's a reason the old API sent id_str right next to id

wanted a job to run on the last day of each month wrote 0 0 31 * * and moved on end of April came. nothing ran. no error, cron just never saw a 31st I only noticed 9 days later when the April report still hadn't shown up only 7 months have one. the job had been skipping 5 months of the year the fix was boring. run at 00:05 on the 1st and process the month that just ended cron has no idea what "end of month" means. it only knows the numbers you hand it

an export job pulled 2 million rows, 500 at a time, and got slower with each page page 1: 20ms page 1,000: 1.4s page 4,000: 9s the query was ORDER BY id LIMIT 500 OFFSET n OFFSET doesn't skip rows. it reads them and throws them away, so the last page read 2 million rows to hand back 500 switched to WHERE id > last_seen_id LIMIT 500 each page stayed at 20ms and the whole export finished in 4 minutes OFFSET is a loop you didn't know you wrote

set a cron job to send me a daily report at 9am first morning, nothing in the inbox 10am, still nothing. logs were clean, no failed run then at 2:30pm it showed up the server clock was UTC. India sits 5 hours 30 minutes ahead, so "0 9" meant 9am UTC, which is 2:30pm here the fix was "30 3" instead. and since India never moves its clocks for summer, it stays right all year a scheduled job has two times, the one you meant and the one the server heard

an iPhone user uploaded a profile photo and my upload route threw a 500 PNG, JPEG, WebP, even AVIF went through fine the file was HEIC, which iPhones save by default the route resizes with sharp. its prebuilt binaries ship libheif with the AV1 codec only, so AVIF works HEIC uses HEVC, which is patent-encumbered. decoding it needs a custom libvips built with libde265 fixed it with 30 lines that convert to JPEG in the browser before upload the most common phone camera format was the one format my server couldn't open

I moved an API to a new server on a tuesday at 4pm new IP, updated the A record, green checks everywhere by 6pm the inbox said the site was down it wasn't. people were still hitting the old box, which I had already switched off the A record had a TTL of 86400 that's 24 hours of resolvers everywhere holding on to an address I'd just killed no fancy multi-region setup saves you from that the fix is boring. drop the TTL to 300 at least a day before the move, then move

locked myself out of my own server at 11:40pm a firewall rule I pushed blocked port 22 fine, I'll get in through the VPN. the VPN runs on that server fine, the provider's web console. it wants my 2FA code the 2FA backup codes live in a password manager I self-host. on that server all the ways back in went through the one machine I had just locked one support ticket and 3 hours later I got a rescue boot now any firewall change I push undoes itself in 5 minutes unless I confirm it

my scraper ran clean for 3 weeks, then started getting 403s at exactly 2:00am each night I spent a weekend on fingerprints. new user agents, a stealth plugin, different TLS settings still 403 at 2:00am the cron fired at 2:00 sharp and hit the same 40 pages in the same order, 1.2 seconds apart, night after night no human browses like a metronome I added random gaps of 4 to 30 seconds, shuffled the page order and spread the run across an hour zero 403s since the fingerprint was fine. the rhythm gave it away