[Karupan]

> Surely, “just whip up a solution in an hour” doesn’t ever happen in reality. > > Right?

Err, maybe the author hadn't experienced that before, but IMO that happens pretty frequently, even for projects that have been in production for years.

[oritart]

I've definitely experienced this before! But, like, its dramatically different if you're physically in the space and there's visible pressure. Its not like I was at home dealing with a crisis where I could more easily block out everything. And coding from scratch is significantly more stressful, imo, than bug fixing.

In addition to my (former) day job, one of my side projects is a live service with ~60k monthly users, and it has broken in prod multiple times.

[Karupan]

> But, like, its dramatically different if you're physically in the space and there's visible pressure

For sure. Not dismissing the author’s achievement here, just noting that it does happen frequently in our industry.

P.S: I once had to fix something in prod during a demo of upcoming features to paying customers. Nothing like using Remote Desktop (yep not even SSH) into four servers to manually change a line in a bundled and minimised Nodejs app!

[oritart]

(To be clear, I'm the author)

[ctrlmeta]

Exactly! An unfortunate truth about running live and complex services is that they break frequently in strange and weird ways and we need to write a fix as quickly as possible, get it reviewed quickly and then roll it out asap. The term "hotfix" literally comes from that. The time range to develop and apply hotfix can be 30 mins to 48 hours--depends on nature of issue.

[jicksaw]

But how often can you say with confidence it will take 30 minutes? If the author was wrong about being able to do it in time, the players would waste their time waiting for a solution and eventually leave. It might be better to just tell the players to go home.

IME with a hotfix you have no choice but to fix it, no matter how long it takes.