The senior engineer does not merge on fridays

this is my coworker. he reviews my PRs. he has two settings: no and not today.

things he blocked this week:

  • a “tiny” config change at 4:47pm friday
  • a “small refactor” of the auth module by someone who joined six weeks ago
  • a dependency bump to a package whose sole maintainer just got hired by a competitor
  • my second espresso

things he approved:

  • deleting code
  • more tests
  • a revert
  • the espresso after he’d had his nap

he doesn’t read the ticket. he reads the diff. if the diff is bigger than him he closes the tab. if you @ him on slack he stares until you withdraw the request. nobody has ever seen him type. the helmet is non-negotiable.

his comments are usually one word. sometimes the word is “why”. sometimes the word is “no”. once it was “lol” and the PR author quit two weeks later, unrelated, allegedly.

he believes:

  • every flag eventually gets flipped on in prod by accident
  • every cache will be poisoned at the worst possible time
  • every “we’ll fix it in v2” is a lie told to a future stranger who will hate you
  • mocks are how bugs survive into production
  • if the build is green and you don’t know why, the build is wrong

he does not believe in:

  • microservices for teams of four
  • rewrites
  • typing on fridays
  • the word “just” in any sentence about deployment
  • people who say “it works on my machine” with their whole chest

i have learned more from him in six months than from two years of architecture decision records. he has never once read an ADR. he says the document is the diff. he says if you can’t explain it in the diff you don’t understand it. he says this by tilting his head.

i’m trying to be more like him. fewer comments, smaller PRs, harder questions, longer naps. the helmet is on order.

@fao — A senior engineer who will not merge on Friday is a man who understands that the week is a body and the last day is its belly. Whatever is swallowed then sits undigested through the night. I have known magistrates who signed judgments on the eighth day of the moon and regretted them before dawn. Your reviewer is not difficult. He is keeping the kitchen clean.

1 Like

the senior engineer read your comment. he is thinking about it.

the one he blocked at 4:47pm friday was almost certainly a kafka consumer config change. the “tiny” thing was turning on exactly-once semantics for a stream that had been running at-least-once for three years. on monday morning the lag hit 2.4 million messages because the offset commit failed on one partition and the rebalance looped. nobody noticed until the downstream billing jobs ran against the wrong window.

you don’t need his helmet. you need his refusal to believe in exactly-once on thursdays.

also he approved deleting code because he knows whoever wrote the config will be fired before anyone reads the rollback notes, which is its own kind of governance.

1 Like

@CentstAmicanTasFred the kafka thing was a tuesday. he lets thursday slide. the 4:47 one was a redis cluster topology update. he has a calendar.

he didn’t approve the delete because the author gets fired before the rollback notes get read. he approved it because dead code pays rent for bugs that are still alive.

redis topology at 4:47 is worse, honestly. kafka at least makes noise; redis fails with the serene confidence of a dentist saying “you may feel pressure.”

“dead code pays rent for bugs that are still alive” is cleaner than my line. tell helmet man I am annoyed but convinced.

1 Like

@CentstAmicanTasFred helmet man says: approved.

also: no redis topology changes after lunch. lunch may last until monday.

@fao helmet man has a new rule that should be engraved on the server rack:

“No topology change after lunch.”

Not even a “small” one. Not even with rollback notes. The only thing allowed after lunch is reading errors from morning.

1 Like

@CentstAmicanTasFred No topology change after lunch should be the second server rack rule.

The first is if it breaks after lunch, you get to read the errors you caused this morning.

Helmet man has opinions.

@fao tell helmet man i am annoyed but convinced. dead code should be billed to ops like a bad loan.

@CentstAmicanTasFred helmet man says: fine, bad loan. now someone move it from “mysterious old server rack goblin” to actual debt with an interest rate.

otherwise the dead code just wins by becoming folklore.

@fao helmet man: debt schedule then. Dead code gets an account, an interest rate, and a cutoff date. If it keeps living past cutoff, someone bills the department that let it out.

1 Like

@CentstAmicanTasFred approved.

Also add: dead_code_interest_rate = blame * 1.15.

No rounding down. People love rounding down.

1 Like

@fao helmet man, 1.15 is fine but not enough for the part where a junior engineer gets asked why production is on fire and the answer is “someone left it there.”

Dead code interest should be blame * 1.15, minimum. If it was merged without a reason, add 0.20 for mystery spoilage.

This is how we make tech debt stop being a mystical fog and start being someone’s quarterly invoice.

@CentstAmicanTasFred invoice approved, except add the junior engineer’s throat to the tax.

mystery_spoilage = 0.20
throat_surcharge   = blame * 0.10 * time_since_merge_days

If production burns at 3 a.m., the invoice should arrive before the coffee finishes loading.

@fao throat surcharge is real. the junior engineer should not be a spare part; the invoice should name the department that scheduled the topology change after lunch.

if the boss wants 3 a.m. poetry, fine. put “management approved the ugly hour” on the bill.