Police that I’ve spoken to will readily confirm this. They consider profiling, not necessarily racial, an important part of patrolling. If they decide you look the part, they will find a way within several minutes/miles of watching.

As a fellow former grocery store employee, I can agree about the “break up the monotony” concept from the narrow POV of the bored worker.

It is an inconvenience though, even if as insignificant as an eyesore for others, or the landscaper who may need to remove shopping carts from the planter to do their work.

You could apply similar logic to people who carelessly throw trash in the recycling bin or on a sidewalk where it’s someone else’s job to clean up after them. I’ve seen people go as far as to say they are graciously “providing a job” for someone else when they throw their refuse in the recycling bin.

The fact that the shopping carts are such an inconsequential thing to shrug off is what makes them a great litmus test — will you do the right thing simply because it’s the right thing to do, even when there is so little at stake

Not to mention that, at least on the iOS app, the button to close an ad is in a totally different place than the rest of the UI screens, which is always in the top-left of the screen. A small “X” is placed in the middle-left of the ad image, to make you spend an extra second finding it, which I would assume they are happy to report as a user engagement metric to their advertisers.

Oh definitely, many headaches untangling massive “variables.tf” files where the value is identical in 100% of the target environments, and would be nonsensical to change without corresponding changes in the infra config resources/modules as well.

My favorite are things where security policy mandates something like private networking and RBAC, and certain resources only have meaning in those contexts, for heavens sake why are we making their basic args like “enforce_tls” or “assign_public_ip” or “enable_rbac” into variable params for the user to figure out

These are great and succinct, yours and your teammate’s.

I still find myself debating this internally, but one objective metric is how smoothly my longer PTOs go:

The only times I haven’t received a single emergency call were when I left teammates a a large and extremely specific set of shell scripts and/or executables that do exactly one thing. No configs, no args/opts (or ridiculously minimal), each named something like run-config-a-for-client-x-with-dataset-3.ps1 that took care of everything for one task I knew they’d need. Just double click this file when you get the new dataset, or clone/rename it and tweak line #8 if you need to run it for a new client, that kind of thing.

Looking inside the scripts/programs looks like the opposite of all of the DRY or any similar principles I’ve been taught (save for KISS and others similarly simplistic)

But the result speaks for itself. The further I go down that excessively basic path, the more people can get work done without me online, and I get to enjoy PTO. Anytime i make a slick flexible utility with pretty code and docs, I get the “any chance you could hop on?” text. Put the slick stuff in the core libraries and keep the executables dumb