HN user

ebiester

7,499 karma

Blog: www.ebiester.com Email: hnchat@ebiester.com

Posts4
Comments2,447
View on HN

Or, perhaps, apple users are rational actors that have different weights to their tradeoffs than you.

The last time I checked Android, the security and privacy story was much worse than Apple. Further, it's not just me who has to make the change - it's the family I share photos and videos and other things.

Yes, I would prefer to have other App Store options, but it is balanced against other issues. (And yes, I have owned an Android phone before - every time I buy a new phone I compare the two again.)

You should do an experiment of splitting that up to multiple reviews that are logically together. My hypothesis is that you may be losing signal due to the amount of text expected back.

Or, alternatively, they feel like they finally cracked the code and think they can do it better. That's when Apple finally enters a market.

Consider how much money they put in to building a car to cancel it when they decided they couldn't, in fact, do it better. I'm sure there are hundreds - maybe thousands - of failed prototypes along the way.

It's the concern for the community who pays in higher prices, and the employees in their job stability.

Has everyone forgotten the social contract? We do not exist as communities to make a small number of people richer. If the trade doesn't work for all involved, we change the rules.

One thing that this misses is that in many fields, career retirement chooses you before you choose it. This is often true in development as ageism catches up with you. At some point, you keep doing interviews and nobody says "yes."

Then, even though you have enough money for retirement (or even if you don't), you are answering these questions simultaneously with handling rejection.

I'm so glad YouTube and other podcast players have moved to support 3.0 speed. As I get comfortable with one, I move it up some. For things like sports and "did you know" content, I can go 2.5 if I'm not multitasking. For technical content, sometimes I'm stuck at 1.0.

Parmesan cheese is savory, not sweet.

For people who did not grow up with hershey's, the butyric acid is what makes it taste off.

This is not a question of safety - it is a question of results. They stayed with old technologies and have optimized for cost, not flavor. (And yes, that processing was necessary in the days before a reliable milk source.)

First, no matter what you do, if a human has write access to the production database, the database can be deleted.

Second, there is a legitimate reason to destroy a database in development and automation. The biggest problem I see is often treating your development data like pets not cattle. You absolutely need to have safeguards that this cannot be run in production, but if a human has access to the credentials to run in production, the agent has access.

So, then, what do we do? In a larger organization, we can depend on the dev/ops split to maintain this. For a solo developer, or a small team, it takes a lot more discipline. Even before AI, junior and even mid-level developers didn't have the knowledge to segment. And senior devs often got complacent because they thought they knew enough.

They likely need some combination of https://www.cloudbees.com/blog/separate-aws-production-and-d..., introduction to terraform, introduction to GitHub actions, and some sort of vm where production credentials live (and AI doesn't!)

But at that point you're past vibe coding. And from what I can tell, the successful vibe coders are quickly learning that they need to go past it pretty quickly with all these horror stories.

I have all the empathy for people in the world.

A corporation is not a person. If your organization cannot handle the load, then you need to adjust your practices. The organization needs to prioritize their paying users. The organization needs to shift people from new features to keeping the lights on. And maybe the organization needs to find another strategy to manage its azure transition.

This is a particular artifact of the government system process. These are contracted pieces of work that Company A would deliver, Company B would administer, and Company C would be contracted out for additional work. Further, all specifications were created ahead of time because changes would cost extra. (Anyone who has done government contracting can talk to the shenanigans involved with it - I have not lived in this world for a long time.)

That said, we still do ad-hoc versions of many of these. For example, a system/segment specification today is an OpenAPI document between microservices. Most larger SaaS companies have the equivalent of a Software Configuration Management plan - Who can change terraform or a GHA, what are the standards that they conform to (linter, peer review standards).

Oh certainly - I'm conflating the adjective of agile with the manifesto of agile. I've been on projects with multi-hundred page design docs and multi-week UATs. And nobody wants to go back to prince2 for example.

The point I was trying to make is we should be diving back into the older methodologies and accumulated wisdom and re-evaluate some of the older dead ends with new context.

Can I rephrase it slightly?

Humans have some repeatable bugs in our wetware, and it can be predictably exploited in a way that is hard to correct. It isn't "some people" - it's all of us, and the moment we think we're immune is the moment that we are most easily affected.

Yes, even the smartest of us are idiots in some very predictable ways.

First, the authors make very little money on most textbooks. You would be shocked. The money is staying with the book publishers.

Second, they've started publishing new editions so quickly with only the problem sets changed (in general) so that students can't use previous editions. If you're learning on your own, you can get some good deals on older editions for just that reason.

And on top of that, they maintain their own platforms so that even if you buy them used, you have to subscribe to a service to take the tests! All of this lines up to finding as many ways to extract money from students and at interest after it's all said and done.

Okay... you're an HTMX fellow. We live in the age of AI so if you're going to make an example, don't show us the trivial things we know HTMX can do.

You need to show a real application with pieces of the system that coordinate and complex interactions. Recreate Jira's backlog and sprint board that can have an arbitrary set of business logic for how a ticket moves through a workflow. Put it through its paces, don't give me a toy.

So, it's just changing the problem up a level.

First, is a 500 because you are using the API in a way that is unexpected a customer found defect? If Claude can't find the answer, what is the expectation of support?

If an internal team makes a change that breaks your workflow (because it was an unexpected use case), is that a CFD?

Do teams slow down in new features because the API must be the stress test of a public api?

I'm fine with unsupported frontends but an external API will be very difficult to keep static.