Sounds like if the OS doesn't track anything else about the user, then it won't receive any other signals and will just use whatever was typed in at account creation.

If websites accept this as age verification it could provide a very easy way to bypass it.

In fact, looking at it again, point B specifically says if the "developer" has information rather than the "system" has information. So really sounds like if the developer isn't collecting logs that they can access themselves this wouldn't apply to them.

That's not been my experience living in the UK. Whe I've asked for directions people either give correct ones (as far as I remember) or say they don't know. When people ask me and I don't know, I say I don't know.

They're not, but the point is that users can see the 403 due to network errors. If vpn + networking work then the user can access the resource through the private interface. If there are issues with network routing or VPN then they end up on the public interface and get 403. So from the user perspective the same action can result in success or 403 based on whether there are network issues.

I wonder if people are talking about the same things in these discussions. 50 people working on the same deployable in the same repo is going to create friction. Similarly, having a few people work on 50 deployables across 50 repos will create challenges.

You need to scope services appropriately. A single small team shouldn't break their application down for the sake of doing microservices, but once you have multiple teams working on the same codebase splitting it up will probably help.

I think this is exactly it. It's easy to see that there's a chance to improve things while ignoring the ways it could make things worse when they won't affect you. Should you quit the job you don't like? "Of course" the friend will say. But then you might just end up with a job you hate more that pays less, or even no job. Whether the outside perspective is helpful probably depends on how much your own perception deviates from reality. Though people do have a tendency to prefer the status quo until things change, so maybe you should always prefer the "change" option when you aren't sure.

Maybe splitting them is helpful, but why would you have to do them sequentially? Many of the things that reduce income inequality also help reduce poverty. Poverty isn't "low-hanging fruit" and it's something people have been trying to eradicate longer than we've been alive.

Saying "let's not even think about B until we've 100% sorted A" is just a way to ensure B never gets done.

I think I gave the impression that we should tackle them sequentially with my comment. My point was that I don't think it's controversial to eradicate poverty, but for whatever reason it is controversial to eradicate income inequality. We don't need to tackle them sequentially but we also don't need to wait for a silver policy bullet that solves income inequality while we try to solve poverty as well. It may be possible to do both, but in the event it's impossible to do B at least we can still try to do A.

Is that what I said?

I apologize. That was not what I meant.

I simply stated they should be decoupled, and approached concurrently.

I think part of the reason is the embrace of an "each package should do exactly one thing" by many in the community, often taken to a ridiculous extreme. Possibly better now after left-pad and other similar incidents.

And anyone who calls that method may find themselves dealing with the implementation details of Entity Framework and whatever db provider you're using because it's a leaky abstraction.

I thought cqrs was a code pattern where you segregate query models from command models, rather than something that specifies where the data is read from or is written to.

Yeah, in my admittedly limited experience the grade I assigned in a live code test (slightly more than fizzbuzz, but no tricks or algorithms required) matched up very closely with real world performance.

I even have knowledge of some of the fails as people higher up the chain decided to hire them anyway. They didn't do well from the feedback I received.