5 ms·
It's interesting that you'd say the downtime was relatively overwhelming. From an outsider's view HN seems like it must be a relatively low stress site to main
by simonholroyd 14y ago
It's interesting that you'd say the downtime was relatively overwhelming. From an outsider's view HN seems like it must be a relatively low stress site to maintain. If it goes down, YC suffers very little. Its community views the site as a public service. If anything, a few hours or even days of downtime just serves to remind the community how valued that service is (and by extension how positive our feelings towards YC are).
Is there a hidden downside to the downtime I'm missing? Worried it brings into question YC's technical chops?
- TheMakeA 14y agoAside from the obvious HN and YC app services, I believe the office hours scheduling and probably any other internal YC service are all part of the same codebase running on the same server. Sounds like it could be a major problem for them.
- pg 14y agoI think almost any programmer running a service used by hundreds of thousands of people would hate the idea of it being down. It's part of building things to want them to work properly.
- mcartyem 14y agoIs there anything you believe could have helped avoid HN being down in the way it did? (Sorry to hijack this post; I doubt you'd see this question in the proper HN downtime post.)
- Donito 14y agoQuote from pg: "For some reason I didn't check the comments after the surgery to see if they were in the right place. I must have been distracted by something." Short answer to your question: Test the fix after deploying it on production :)
- simonholroyd 14y agoI certainly sympathize with the stress, I've been there. But programmers are much more effective at resolving downtime in low stress situations, so the best strategy is neutralizing those high-stress moments and just accepting that "downtime happens".