guhidalg

Regarding who maintains them: that’s my problem to have _after_ I buy them, but today I can’t even buy them! And I picked a high-end example, of course I couldn’t maintain an F35 but maybe I would like some automatic rifles or more realistically some armed drones.

Still I think we’re saying the same thing: the founder’s arguments amount well regulated militias being a check on tyrannical government doesn’t land when the tyrannical government can just drone swarm the country into submission.

Can I buy the same weapons the American military has access to?

Until that's true, the 2nd amendment is meaningless when USAF can buy JDAMs and F35s and I, an American citizen, cannot.

Read the second to last slide. What we need now is *imagination*. You assume the need for new software is fixed and that AI is going to satisfy that need with fewer humans (lower cost), but by lowering the cost we can increase the supply of software!

That means software engineers better start getting creative. If you think your job is to wait for a PM to assign you a well-written researched ticket, you're done. Your job is now to figure out how to make these machines (computers) do whatever we need them to do safely, quickly, at scale, and correctly by applying all your knowledge of computer science and the engineering field of software engineering to an AI prompt.

How do you know it’s installed right without putting power through the thing? You’re going to turn the breaker off an on for every single switch? NOPE!

That would be great, if everyone in society thought about each other as altruistically as those pushing for UBI and stronger safety nets. It's probably achievable in small homogenous countries, not in this vast, heterogeneous, central-government-wary USA.

Some PM realized that agents will not push back against waterfall style project planning, so now we get an agent for all possible versions of waterfall projects.

Because it's less moving pieces to only have one bit of state to think about.

You already have a connection string to your database with a password or authn/z with your cloud provider. If this is a "serious" application, you have backups, monitoring, user roles, pgbouncer, partitioning, and other Postgres-specific things to think about. With just a little bit of care, you can make whatever queries you are running fast enough to not need redis.

But ok, you think adding redis is going to solve your performance problem because you can just cache API responses in redis instead of hitting the DB. Maybe, but now you have to think about cache invalidation, eviction behavior, sizing the redis instance, another set of authn/z roles to think about, and of course more cost.

I realize we're speaking past each other, but IME Postgres will work well into the terabyte range and if you can't tune your database setup for performance then reaching for cache is a form of premature optimization.

FDA does regulate cosmetics components, and FTC regulates what claims they can make. It’s hard to make a binary decision that one thing is a drug and something else isn’t. You can appreciate there is a spectrum of side effects with moisturizer and sunblock on one end, supplements in the middle, and chemotherapy drugs on the other end.

Personally, I think that Americans simply don’t treat skin cancer as seriously as they should, and so the market has not provided more choices.

I bet this is correlated with how much they like/know Postgres already. When people don’t understand their database’s features, they want it to behave like something else they do understand (code). They’re leaving a lot of performance on the table by not leveraging everything their database can do.

More like "you must be on the newest version of everything all the time, or you will get hacked".

You don’t, there’s always a choice about what to include and what to exclude in your system.

Unless you are hand selecting every atom that goes into a thing (maybe you make nuclear weapons?), you always make choices about what you focus on and what is irrelevant to your project.

In my experience, the median user for communication apps is mobile _only_. Before that, it better be a website that works well on phones, and decently on desktop.

As a developer I don't like it, but reality doesn't have to appease me.

In my experience, there is no in-memory database replacement that correctly replicates the behavior of your database. You need to use a real database, or at least an emulator of one.

For example, I have an app that uses Postgres as the database. I have a lot of functions, schemas, triggers, constraints in Postgres for modifying database state, because the database is 100x faster at this than my application will ever be. If I have an in-memory version of Postgres, it would need to replicate those Postgres features, and at that point I really should just be standing up a database and testing against it.

I have worked with people claiming that unit tests need to hermetically run in-memory, because reasons. Ok, I don't disagree, but if my bug or feature requires testing that the database is modified correctly, I need to test against a real database! Your in-memory mock will not replicate the behavior of a database _ask me how I know_ ...

These days, Docker makes this so easy that it's just lazy to not standup a database container and write tests againts it.

But our brains do map high-dimensionality input to dimensions low enough to be describable with text.

You can represent a dog as a specific multi-dimensional array (raster image), but the word dog represents many kinds of images.