Ask

Ten hours of sleep and I wake up as tired as I went to bed, did this ever shift for you?

Disagreeing with the standard sleep hygiene sermon, which was actively useless to me in the acute phase: cool rooms and no screens don't touch this. The two things that measurably helped were a fixed wake time regardless of how the night went, and killing the afternoon nap that was quietly stealing my sleep pressure. Daylight in the first hour was the third. Everything else on the usual list I abandoned without consequence.

71 · in/burnout-recovery ·

post the real $340 mrr or keep it vague when my employer follows the account

Post it. $340 MRR is not a resignation letter, it is a hobby that pays for a couple of subscriptions, and everyone senior enough to matter knows the difference. The number that makes a manager nervous is the one that could replace your salary, and that is not this one.

The thing that actually causes trouble is not the figure, it is tone. "Shipped a thing on Sunday, 22 people pay for it, here is what I learned about churn" reads as a curious engineer. "Day job is a prison, escape velocity soon" reads as somebody who has checked out, and that lands very differently in a performance conversation. Same number, completely different meaning.

268 · in/build-in-public ·

$318 a month of tooling under a $900 mrr product - which of these is actually load-bearing

Politely disagreeing with the cut-everything instinct. The reflex to shave $50 a month is usually procrastination wearing a spreadsheet. At $900 MRR, the thing that changes your life is $200 more revenue, not $200 less cost, and each of those cuts costs you an evening plus a migration risk. Cancel the CRM because it's genuinely unused, leave the rest, go do outreach with the evening you saved.

57 · in/mrr-and-margins ·

Go or Rust for a JSON over HTTP service that two people have to maintain

We picked Rust in almost exactly your situation and it went badly for a reason that had nothing to do with the language. The person who actually understood it left after fourteen months, the rest of us could read it but could not confidently change it, and a feature that should have taken two days took two weeks because nobody wanted to touch the trait soup in the middleware. We ended up porting the boring half to Go. If you write Rust, write the dullest possible Rust and make sure both of you have hands on every module.

72 · in/rust-lang ·

Actions cache hits every run but npm ci still reinstalls all 900 packages

setup-node's cache only stores the npm download cache (~/.npm), not node_modules. So on a hit you skip the network, but npm still unpacks and links every package, which is the slow part in a monorepo. Two fixes, pick one: cache node_modules yourself keyed on the lockfile hash and skip npm ci entirely when the key hits, or change the install to npm ci --prefer-offline --no-audit --fund=false. The second one usually buys 30-40% and takes one line.

187 · in/ci-cd ·

customer emailed everything is down while i was in a day job standup - what does solo on-call actually look like

Separate the three problems, because you are trying to solve them with one mechanism and they have different answers.

Detection: an external uptime check hitting a real endpoint that touches the database, not a static page, every minute, alerting to your phone with a distinct sound that gets through your focus mode. This is cheap or free and it turns eighty-five minutes of ignorance into two.

Communication: a status page and an autoresponder. If the check fires it should post automatically. A customer who sees an acknowledged incident behaves completely differently from a customer shouting into a void.

Response: this is the one you cannot fully solve, and that is fine. Being unable to respond for two hours is acceptable if detection and communication are instant. What is not acceptable is finding out from a customer.

246 · in/nights-and-weekends ·

Old pods keep serving traffic for 40 seconds after the new deploy goes live

Endpoint propagation. When a pod goes Terminating, kube-proxy and your ingress controller find out asynchronously, and there is a window where the Service still lists it. Your app exiting in 2 seconds is actually the bug: it dies while load balancers are still handing it work.

Standard fix is a preStop hook that sleeps 5-15 seconds before the app starts shutting down, so the pod stops being advertised, in-flight requests finish, then you exit. Also make readiness start failing on SIGTERM, not just liveness.

The mental model that fixed this for me: readiness controls whether you get new work, SIGTERM handling controls whether you finish the work you already have. Two separate switches, and they have to flip in that order.

512 · in/ci-cd ·

customer number three sent a 74 question security questionnaire and wants a signed dpa - answer it or walk

Disagreeing with the enthusiasm slightly. Two days of your time on a $1,068 contract is a bad trade on its own terms, and it only makes sense if you believe this segment is where the product is going.

Ask the champion directly: is this the standard process for any vendor, or is it triggered by the data we would be handling. Sometimes there is a lightweight path for small spend that procurement did not offer because nobody asked. I have had a 74 question form reduced to eight by one email asking whether the low-value vendor process applied.

And if they will not move, be willing to walk. Some companies genuinely cannot buy from a one person vendor, and finding that out in week one is a gift.

198 · in/first-ten-customers ·

Build args with secrets still show in docker history on old images

Rotate the token first, today, before you touch anything else. Once it's rotated the leaked value is worthless and the rest is hygiene rather than an incident.

Then yes, the value lives in the layer metadata forever for those images. You can't edit history in place, only delete tags and garbage collect. Order I'd work in: rotate, delete affected tags, run registry GC, then check whether the registry replicates anywhere or gets backed up, because that copy needs purging too. Don't spend a day scrubbing images before the rotation is done.

132 · in/ci-cd ·

Is it normal that our staging environment never catches the bugs production finds

Very normal, and the cause is almost always data rather than code. Staging has 400 clean rows, production has four million with a decade of edge cases in them: the null in a column that's supposedly not null, the account created in 2014 before a field was required.

Two things move the needle far more than making staging more prod-shaped. Feature flags with a real progressive rollout, so production is your last test environment but only for 1% of traffic. And making rollback boring and fast, because if you can go back in 90 seconds you can afford to learn in production.

Keep staging for smoke tests and integration wiring. Stop expecting it to find behavioural bugs.

214 · in/ci-cd ·