HN user

rdoherty

1,742 karma

Site Reliability Engineer at Netflix https://www.linkedin.com/in/ryan-d-doherty/

Posts74
Comments200
View on HN
www.kqed.org 11d ago

San Francisco Inches Closer to PG&E Acquisition

rdoherty
2pts0
techcrunch.com 2mo ago

San Francisco's housing market has lost its mind

rdoherty
4pts4
simonwillison.net 4mo ago

Shopify/liquid: Performance: 53% faster parse+render, 61% fewer allocations

rdoherty
4pts0
github.blog 4mo ago

Addressing GitHub's recent availability issues

rdoherty
2pts1
log.andvari.net 4mo ago

Chasing Boring at Just the Right Speed

rdoherty
2pts0
www.marketwatch.com 4mo ago

Block to lay off nearly half its staff in 'deliberate and bold' embrace of AI

rdoherty
9pts2
www.npr.org 7mo ago

Ford pulls the plug on the F-150 Lightning electric pickup truck

rdoherty
6pts4
www.siddharthbharath.com 8mo ago

GPT's Glazing and the Danger of AI Agreeableness

rdoherty
2pts0
incident.io 9mo ago

Incident.io Service disruption on October 20, 2025

rdoherty
2pts1
queue.acm.org 10mo ago

Civics is boring, so, let's encrypt something (2024)

rdoherty
55pts70
www.buoyant.io 1y ago

Careful upgrading to cert-manager 1.18

rdoherty
3pts0
www.npr.org 1y ago

Trump administration cancels plans to develop a bird flu vaccine

rdoherty
13pts0
www.junctionlabs.io 1y ago

From Nitro to Junction: Testing in Production at Scale

rdoherty
3pts0
apnews.com 1y ago

Federal technology staffers resign rather than help Musk and DOGE

rdoherty
28pts9
www.honeycomb.io 1y ago

Standup Meetings Are Dead

rdoherty
4pts1
www.usenix.org 1y ago

Seeing Like an SRE: Site Reliability Engineering as High Modernism

rdoherty
3pts0
longform.asmartbear.com 2y ago

The Fundamental Forces of Scale

rdoherty
1pts0
restofworld.org 2y ago

Digital parents giving millions in China a vision of family love they never had

rdoherty
2pts0
tech.ahrefs.com 2y ago

Ahrefs Saved US$400M in 3 Years by Not Going to the Cloud

rdoherty
5pts1
blog.danslimmon.com 2y ago

Clinical troubleshooting: diagnose any production issue, fast

rdoherty
2pts0
techcrunch.com 2y ago

Rivian lays off 10% of workforce as EV pricing pressure mounts

rdoherty
16pts0
incident.io 2y ago

AI convinced our CTO to upgrade our MacBooks

rdoherty
4pts1
www.theguardian.com 2y ago

Could a $400k Australian court ruling silence Kiwi Farms?

rdoherty
47pts68
www.honeycomb.io 2y ago

Incident Review: What Comes Up Must First Go Down

rdoherty
1pts0
www.economist.com 2y ago

Some developers are pushing back against violent video games

rdoherty
2pts1
blog.alexewerlof.com 2y ago

Broken Ownership

rdoherty
163pts34
foundation.mozilla.org 3y ago

Slack Takes an Important Step to Block Abuse

rdoherty
31pts69
www.mermaidchart.com 3y ago

Flow charts are O(n)2 complex, so don't go over 100 connections

rdoherty
2pts1
www.thedailybeast.com 3y ago

LinkedIn Founder Is Funding E. Jean Carroll’s Lawsuit Against Trump

rdoherty
9pts0
www.npr.org 3y ago

FBI arrests 2 on charges tied to Chinese outpost in New York City

rdoherty
19pts1

It's not just the untyped problems, the runtime definitions of functions, properties, etc make it nearly impossible to debug unless you have the state of your production data locally. (Or you ssh into your prod server and open up a REPL, load the state and introspect everything there). Good luck debugging locally in a nice IDE. It's a horrific nightmare. I use to love Ruby until I had to debug it live.

Skimming the list, looks like most extensions are for scraping or automating LinkedIn usage. Not surprising as there's money to be made with LinkedIn data. Scraping was a problem when I worked there, the abuse teams built some reasonably sophisticated detection & prevention, and it was a constant battle.

This is probably one of the best summarizations of the past 10 years of my career in SRE. Once your systems get complex enough, something is always broken and you have to prepare for that. Detection & response become just as critical as pre-deploy testing.

I do worry about all the automation being another failure point, along with the IaC stuff. That is all software too! How do you update that safely? It's turtles all the way down!

I'm a HOA president and while HOAs can be very extreme, the flip side is if homeowners are breaking rules designed to protect property or common areas (pool, lawns, playground, etc) a $100 is not enough to stop people. Thankfully our HOA focuses on our common areas and is responsible for all exteriors and lawns (it's all townhomes), so the lines are a bit clearer.

We've had all sorts of wild issues such as building scaffolding on top of balconies (not attached), ripping up common area plants, parking issues (we all have garages, street parking is guest only), drying food on the pool deck (really), dumping garbage bags outside in the common area and more. If we can only levy a $100 fine there's little incentive for some people to stop doing things that impact the community.

I do cringe when I hear about these crazy HOAs of what are usually a collection of single family homes. I think a better approach would be some kind of limitations of the what HOAs can have rules about vs the penalties. Interiors of homes should be generally off limits (aside from townhomes that are all technically 1 building, so you should not be doing anything structural without approval). For single family homes with private property surrounding them I'd rather there be limits that are purely for safety, legal reasons or impacting common areas.

Not explicitly, but there were rumors a few days before. Also the signs were there: every single meeting room was booked, meeting rooms all had water & tissues, etc.

I worked at Yahoo in 2008 when they laid off thousands and yes every single person got a calendar invite and met in a meeting room 1:1 with a manager. It was difficult but they did it. Times definitely have changed.

It will hold my coffee at the perfect temperature all day. Also if the battery runs out I can put it on its charger and after ~5 mins it will start heating my now cold coffee back up to temperature. I thought it was kinda gimmicky too before I bought it but I am surprised at how great it is to have perfect temp coffee all the time.

Under $100 - Ember mug. No more reheating coffee a few times/day or trying to drink cold coffee. I was surprised at how much I enjoy it. A nice napkin holder that is easy to pull napkins from. Vertical magazine/tablet organizer. Whiteboard next to my desk. Anything simple that makes a frequent chore or task 50% easier.

Under $1000 - Twice/week 'house helper' who does dishes and laundry. My wife travels a few weeks/month and we have 2 kids. Having someone do all the dishes and laundry saves me at least 5hrs/week.

I've ridden a few times and their prices seem close to Lyft. I would happily pay a premium for the service they are providing right now. New, clean cars that drive very smoothly and lower rates of accidents than an 'average' driver. No weird smells, distracted drivers, inexperienced drivers, etc.

I think in a few more years with the amount of training their AI will have Waymo will be a truly incredible taxi service. It can only get better!

Warm Handoffs 2 years ago

I hate DMs in Slack for this and many reasons. One thing I do try is to ask people to move to a public channel unless it's a personal issue. Copy/paste their question and cc their handle.

Comic Mono 2 years ago

Me too! I did it so I wouldn't take the codebase I'm working on so seriously :)

I'm not the OP but a few things:

* Reading/fetching the data - usernames, phone number, message, etc.

* Generating the content for each message - it might be custom per person

* This is using a 3rd party API that might take anywhere from 100ms to 2s to respond, and you need to leave a connection open.

* Retries on errors, rescheduling, backoffs

* At least once or at most once sends? Each has tradeoffs

* Stopping/starting that many messages at any time

* Rate limits on some services you might be using alongside your service (network gateway, database, etc)

* Recordkeeping - did the message send? When?

If you read the article it says exactly why:

In the 1950s and ‘60s, as Hong Kong grew as an industrial hub, many people migrated to the rapidly expanding urban centers for better working opportunities. “It’s hard farming and fishing out there in these remote areas, so a lot of people moved to the city to work in the factories,”

At least around me in CA I see folks every day looking at their phones while driving. I believe license requirements and overall driving safety is much higher in Europe vs the US. I have friends from Europe who are shocked at how easy it is to get a license in the US.

These are great tips for load testing any web service. Don't forget that you can also saturate memory, disk or network too, so watch those graphs too. I've seen load tests unable to saturate CPU because another resource was limited.

Also don't forget that you are load testing all the dependencies of your service. Database, caching tier, external services, etc. Make sure other teams are aware!

Also nothing beats real world traffic. Users' connections will stay open longer than a synthetic tool may hold them open due to bandwidth, they make very random, sporadic requests too. Your service will behave very differently under large amounts of real world traffic vs synthetic.

Other options if you are running multiple web servers is to shift traffic around to increase traffic to 1 host and see where it fails. That is usually a very reliable signal for peak load.

And don't forget to do this on a schedule as your codebase (and your dependencies codebases) changes!

Good on the author, but using a Virtual Private Server skirts very close to not self-hosting. When I read 'self-hosting', I imagined buying/building a physical server and either putting it into a datacenter or running it in your home.

Lately I've been thinking of creating a bare-bones HTML website of my own and maybe I'll run it on a Raspberry Pi at home. I think that would qualify as 'self-hosting'.

The real learnings of this incident is how to handle incidents effectively. The author cites ones that I use every time I manage one:

* Centralize - 1 tracking doc that describes the issue, timeline, what's been tested, who owns the incident. Have 1 group chat, 1 'team' (virtual or in person). Get an incident commander to drive the group.

* Create a list of hypotheses and work through them one at a time.

* Use data, not assumptions to prove or disprove your hypotheses.

* Gather as much data as you can, but don't let a particular suspicious graph lead you into a rabbit hole. Keep gathering data.

If you don't do the above you are guaranteed to have a mess, have to repeat yourself over and over and waste time.

I Love Ruby 3 years ago

Yeah tbh after working with Ruby for nearly 2 decades now and with a handful of other languages I think Ruby could use some parentheses and other common symbols. It really is too easy to create what are DSLs which requires learning another language and layer of abstraction.

For great sci-fi, definitely review The Hugo Awards (and previous awards) https://www.thehugoawards.org/hugo-history/2023-hugo-awards/ and the Arthur C Clarke awards https://en.wikipedia.org/wiki/Arthur_C._Clarke_Award . I found many great authors and series there.

I highly recommend anything by Adrian Tchaikovsky. His themes and ideas are deep and fascinating. https://www.amazon.com/stores/Adrian-Tchaikovsky/author/B002... (Children of Time Series, Dogs of War and City of Last Chances are great). Him and Dan Simmons are my favorite new(ish) authors. If you haven't read the Hyperion quadrilogy, it's my favorite sci-fi series ever.

I hate to be that guy, but I find Andy Weir's books to be very simple and 'light' sci-fi. Fun reads but usually suffers from the protagonist being a genius and smart aleck. No deep themes or characters. I never understood the crazy appeal after reading all of Asimov and Arthur C Clarke. Personally I want giant themes, huge space operas, complex characters and long storylines!

Once your schema changes take more than a few minutes, yes. There's a lot of toil and burden if you need to take down your application every time you need a schema change. Announcements, coordination with internal teams and customers and then coordinating with other engineers.

We aren't talking about zero downtime here, but continual, recurring downtime due to schema changes. Once you have beyond a few million rows in a normal RDBMS, schema changes can take minutes to hours depending on the type. Do this a few times per month and you now have 'lots' of downtime and you are blocking other engineering work from happening. It eventually becomes so much of a hassle that engineers don't want to do schema changes, blocking feature work. The more seamless and painless you can make them, the better.