frenchtoast8

From the thread and related discussions, Cloudflare's reasons probably had nothing to do with bandwidth used. I also recently signed up for Cloudflare and pushed 20 TB per month on their free plan, I specifically asked Cloudflare if this was okay and they said yes. YMMV

> The new OMNY "tap to pay" system is also less generous with its weekly discounts than the previously weekly MetroCard discounts. In practice, that's a further price hike for weekly commuters, above and beyond what the single ticket list price captures.

How? The 7 Day Unlimited MetroCard is $34, which is the weekly fare cap in OMNY. Did you mean monthly? I do believe some people in certain situations will pay more with OMNY compared to a 30 Day Unlimited MetroCard due to OMNY fare caps only being counted weekly. Someone who consistently hits the $34 OMNY weekly fare cap pays $4.85 per day on average, but a 30 Day Unlimited MetroCard is $132 ($4.40 per day).

This is nearly my exact experience at work. I work on an internal tools team, so my users are other engineers at the company. Product teams have Product Managers and seem to put in a lot of effort into their OKRs, but for the internal tools team, we're in some limbo: still forced to write OKRs, but no parts of the process that are actually useful. We might have an OKR to upgrade Jenkins before an EOL date, but no introspection about whether the company at large would be better served by GitLab CI (as an example). Management only cares that we have defined KPIs like "Days remaining until Jenkins EOL date" and that they are improving. I still try to have the difficult conversations, but it's a constant battle with management as improving developer happiness by allowing them to use a better system isn't easily demonstrated on a dashboard.

Also, like you said, teams write their OKRs in a vacuum without coordinating with other teams. So, one engineering team might have an OKR to fix some memory issue affecting their Jenkins pipelines, but they didn't communicate that with the internal tools team that operates Jenkins. It then became a struggle between the two managers, one saying "We need to fix this Jenkins issue or we'll fail our OKRs commitment" and the other saying "We already committed to different OKRs this quarter, we can't take on new work." The engineers are stuck between this battle trying to help each other in secret without management hearing about it.

You have no problem describing your teammates like that in a formal review? I am not sure how that would go here, I haven't tried. Like I said, so far every company I've worked for either didn't do formal reviews at all or it was entirely assessed by your manager without any conversation.

Fable, a social media platform alternative to Goodreads, recently launched a Reader Summaries feature that playfully roasts the user based on the books they have recently read. The content is generated by an AI model, and in some cases users have gotten offensive or racist jokes. This has resulted in the company's Head of Product to release this statement.

According to the video, the team relied on "safeguards" to prevent this from happening. Two were mentioned:

1. "We ask the model to avoid some topics."

2. "We also created a second pass offensive language filter."

It sounds like the company considered avoiding certain language to be a hard requirement for this feature. The decision to rely almost entirely on the instructions in the model prompt leave me scratching my head. Is this a simple matter of a Series A company shipping something too quickly, or did the engineering team really believe that a couple instructions could guarantee certain responses? (Or both?)