phoenixy1

My whole life, my mom would talk about how much she hated the suburbs, how she lived in a Chicago suburb and it was a miserable experience, she would never do it again, etc., all the while praising the time that she lived in Tiburon.

I finally went and visited the house where she had rented in Tiburon (it was just a block from the Paradise Loop path, a pleasant bike ride from SF), and I was like, "Mom, Tiburon is totally a suburb." And her response was "Oh, well your sisters could walk to school and I could walk to the grocery store, so it didn't feel like a suburb to me."

Interestingly, "went to a bar in the past year" is one of the few questions in the survey whose answer basically didn't budge (52% in 1995 vs. 49% in 2026).

AI actually is decently good at updating docs. But the kinds of problems that are being described in this thread, like documentation that varies wildly in tone and target audience or that describes different versions of the same service, or where how to do something is covered across multiple semi-overlapping pieces of documentation (some of which are up to date and some of which are not) are all a real strong indicator of inadequate centralized ownership of the docs. And the AI ain't gonna update the docs if nobody tells it to. (And AI still requires a great deal of micro-management to be used effectively in docs authorship.)

It depends. For stuff like npm packages, where the downstream consumers have to make a conscious decision about whether to adopt the update or not, I absolutely think it's worth getting it right, especially for major version bumps. I myself am the user of an open source code gen tool that does not have comprehensive changelogs, and it makes me want to tear my hair out because we can never be confident when upgrading whether or not we're going to end up with changes that will break our workflows or our customers' workflows.

But for consumer apps, honestly, maybe not? Even at companies that do good consumer changelogs, they're generally considered marketing content. Other posters in this thread made the points that most people updating consumer apps are not even going to see the changelog message, and that app stores have effectively punished companies for providing detailed changelogs by holding app store releases over them.

And given that for larger companies so many of them are actually controlling their feature releases on the backend and not on the client side (you might add the capability for a feature on the client months before you actually set the rollout to 100%), trying to convey those updates in the client-side changelog can be hard to do in a way that consumers will understand and can often generate a lot of confusion and support tickets. After all, we don't expect a changelog entry every time a website updates, and I feel like every day mobile and desktop apps are getting closer and closer to that category.

Changelogs are really difficult to do properly. The concept of a "release" is fuzzy in a world of continuous deployment, and feature flags and experiments mean that different customers are seeing different features. The release of the client that can support the feature is often very divorced from the enablement of the feature. This is not a new phenomenon and has been something we struggled with way back in 2013 in my first SaaS job. Even if you do have a defined set of changes, the way modern software releases work means that the changelog is often the only reason to collect and document those all in one place, and not always a sufficiently compelling one to justify gathering and coordinating this information across teams in a large organization.

Anyway, time to go go see if Claude's done drafting that changelog I asked it to do...

The GitHub bot situation is so frustrating! A good ~50% of community traffic on our repos is spam and bots and to report them I have to fill out a lengthy form and MAYBE GitHub will ban them six weeks later. And I also can't tell whether our repos are being used (and thus worth investing in): GitHib only shows two weeks of traffic data and what they do have is completely useless because they can't filter out bot traffic.

This rule of thumb, when used correctly, is supposed to refer to womens' dress straight sizes. As in, for an average height woman, losing 10 lbs is roughly equivalent to going from a size 8 to a size 6. It doesn't refer to clothing that is sized as "medium", "large", etc. (I did not read the article; it seems from the quote that the author was using this rule of thumb inappropriately and out of context.)

These are really good changes for your overall health, but what I hear anecdotally is that a lot of the young adults diagnosed with colon cancer don't have traditional colon cancer diet/lifestyle risk factors. There's even a theory that healthy activities like long distance running might be contributing to cancer risk.

Yes, Anthropic, OpenAI, and Cloudflare, among others.

I think what you're missing is that prior to the acquisition, Anthropic was a customer of Stainless. They did not need to "rummage through [their] data and workflows" to understand the quality of their product.

The front page of Hacker News was not exactly the place where I was expecting to discover that you were changing jobs, but congrats, Tim!

You totally could, but the purpose of the OpenAI/Plaid integration is to help you analyze your spending and finances with OpenAI (using it as a budgeting/financial planning app), so if your spending isn't actually in the account you connected, it's not going to give you any value.

We just this week launched a new sign-up flow to make it waaaay easier for non-businesses to use Plaid, I posted some details below.

Actually, as part of publicizing our new hobbyist-friendly onboarding, we're looking to work with hobbyists who have created Plaid-powered apps and would be interested in making a short video about their app and their Plaid experience to potentially be featured on the Plaid blog -- if you're interested, shoot me an email at [email protected] and I can send you the details.