Mugshots are pretty locked down now, but when I was younger, you could just scroll and scroll. Used to go through, check to see if I knew anybody. Got lucky a few times. Well, if you think you're safe, you're not, and if you think it's deleted, it knows everything about you. The difference between the marginal mugshot and the whole database is how prepared you are. Scrape that data every day, baby.

Excellent fun. Now just to create a prompt to show iterated LLMs are turing complete.

I tried to come up with an optimistic response, but when you consider all the ways data can be exfiltrated: if you can send a bit, you can send a file.

Google makes the impossible, hard, and it makes the easy, hard.

Here's the dangerous way I put it that I only tell senior people: understand why rules were made and make sure the people who made them would be happy.

I saw this put really, really well not too long ago:

> A lot of us got the message earlier in life that we had to wait for other's permission or encouragement to do things, when in fact, all you need is the ability to understand the situation and deal with the consequences

So fun to see other variations of this. I have for a while said

> You never need permission to do a good job.

But of course, it takes the experience to understand the nuances of what a good job is in the domain at hand, in the organisation and society at hand.

> You never need permission to do a good job.

If you don't mind, I will steal this one.

Love the irony of this post.

I’m sure there’s a flashy way to say it, but yours reminds me of this one:

> Only ask for permission if you want to be told “no”

The one I'm familiar with is:

> It's better to ask for forgiveness than permission.

Of course this can be used to justify all sorts of terrible things, but I've mainly seen it as pretty innocent in work environments when applying common sense.

As a manager the way I approach rules with my reports is I always tell them to understand the "chesterton's fence" behind any rule. I looks at rules like business logic in code, the "logic" was added there for a reason but there are often edge cases where that logic does not apply. I don't tell my reports to either break or follow any particular rule, but to understand why that rule is there before they decide if they need to either follow or break it.

And from personal experience i find that when you give people that level of autonomy, they will almost always approach what I told them about rule breaking in good faith.

Frankly, most corporations do not last long enough for this to be a problem. Governments are their own issue, but without the political inertia and staying power of a nation-state, your organization will likely be long dead (or at least irrelevant and dying) before interpretations will drift that far. Most of the time, for most engineers, at least some of the people who made these rules in the first place are still around -- which helps ensure that nothing drifts too too far.

Of course there are exceptions, probably even upwards of 20% of the time, but we're talking generalities.

I never went to class myself unless I was required, had an exam, or loved it. Sometimes I would skip my research advisor's class to do research in his lab. Even if I wasn't in class, I was there though. I'd get notes from someone.

We need AI EU OS to cover all vowels.

Y?

I have one rule about ATMs. Always take out the maximum amount.

The Amazon reviews for this book are bad, but hey, for free!

This is the same as a null pointer, and the requirement is very deeply tied to protobuf as it is used on large distributed systems that always need to handle version mismatch, and this advice doesn't necessarily apply to API design in general.

Even in the simplest web apps you can encounter version mismatch when a client requests a response from a server that just updated.

This implies an API where the server has a single shared implementation. Imagine for instance that the server implements a shim for each version of the interface, then there isn't a need for the null in the API. Imagine another alternative, that the same API never adds a field, but you add a new method which takes the new type. Imagine yet again an API where you are able to version the clients in lockstep. So, it's a decision about how the API is used and evolves that recommends the API encoding or having a null default. However in a different environment or with different practices, you can avoid the null. Of course the reason to avoid the null is so that you can statically enforce this value is provided in new clients, though this also assumes your client language is typed. So in the end, protobuf teaches us, but it's not always the best in every situation.

Hence the advice to make that situation not happen. Update the client and server to support both versions and prefer the new one, then update both to not support the old version. With load balancers and other real-world problems you might have to break that down into 4 coordinated steps.

That only really works if you control the clients, or can force them to update.

> or can force them to update.

I've used a few clients that completely lock me out for every tiniest minor version update. Very top-tier annoying imho.

But it does make the authors' jobs easier.