Drift towards danger and the normalization of deviance (2017)

That’s not the only real danger.

The angle grinder can suddenly shift in practically any direction. It’s very easy to lose control of it.

> the real danger is the disc breaking up at 10K RPM and shrapnel flying in your face. you might easily lose an eye.

For anyone wondering, OSHA would tell you to use safety glasses and a face shield. Neither is sufficient protection alone.

You should also do the "ring" test before mounting a disc.

https://youtu.be/QSQiLxDBpu8

you also learn in biking that a helmet gives you a redo, just like the blade guard does

I've seen that before in reference to flying planes and I assume it's true of driving cars.

Do you know the/an authoritative for this topic?

This is also part of the concept of normalization of deviance, though. Selecting tools because of proximity or accessibility rather than suitability.

One time you "need" (feeling pressure from somewhere) to get something done and you reach for the tool at hand, it's not the right tool but it's workable. Then later you experience the same thing and think, "Oh yeah, that worked last time I can just do it again." Repeat a few more times and it becomes the tool you reach for instead of your backup when you have nothing else but "need" to get the work done now. Its unsuitability becomes apparent when you injure yourself or cause damage to the items you're working on because it was never the right tool, you were just careful in how you used it the first few times and got too comfortable with it as time went on.

Angle grinders are just awful in their versatility. It’s almost always a wrong tool for the job, but the right specialized tool often costs more or not readily available.

Companies: "your testing is costing us thousands of dollars"

Devs: "So how much does an a few hours of outages cost again?"

> I have not found an answer for testing React components that seems like a good use of resources > … > I'd really love to have a system that would give me a heads up that some CSS I changed has a spooky effect on a distance on part of the UI because of the complexity of selectors but that's asking a lot

I would’ve agreed until recently. I always found basically all other forms of testing valuable (unit tests of almost everything on the BE, unit tests of FE business logic, BE integration tests, E2E tests), but not testing of the visual elements of the FE.

But the company I work at, ~6 months ago we gave this product a try, and honestly it’s pretty incredible: https://www.meticulous.ai/

They basically record sessions of real usage in our staging environment, and then replay them against your branch, like taking all the same interactions, and mocking responses to all network calls. It records tonnes of these sessions and is very smart about which ones it uses for a given change. It flags any visual differences, and you can OK them (or not). There’s a bit of work to initially integrate, but then you don’t write any tests, and you get pretty amazing coverage. It has the odd false positives, but not many, and they’re easy to review/approve in their web UI. They’re also a small startup willing to work super closely with you (we share a Slack chat with them, they’re very open to feedback and iterating quickly on it).

I swear I’m not a paid shill or affiliated with them in any way, just a user who really loves the product. I was skeptical it’d work well at first, but it’s honestly been great, has caught many potential regressions, I feel we’re getting much better coverage than we would with handwritten UI tests. It’s very worth a look IMO if you’re not satisfied with your visual tests. It’s not an E2E testing tool, because the network requests are recorded/replayed (so it can’t stop BE changes that break the FE), but it’s amazing for testing so many elements of the FE.

Hm. Just thinking out loud. TLDR is that I think the core of the solution to good testing of React components, would look like using it like the Web Component model?

So one thing that I keep coming back to as kind of a "baseline" is called Functional Core, Imperative Shell. It's a little hard to explain in a short space like this and the presentations available on YouTube and blog articles are a bit confusing, but basically it asks for your application to be broken into three parts: (1) modules in the "functional core" define immutable data structures and purely deterministic transformations between them; (2) modules in imperative libraries each "do one thing and do it well", they might call the SaveUser API or something like that; and (3) these are held together by a thin shell of glue code that needs to have no real logic (that's for the functional core) and needs to not do any real operations directly (that's for the libraries). And the reason to break the app apart like this is that it's test-centric: modules in (1) are unit-tested without mocks, by creating immutable data structures, feeding to the transforms, and checking the output; modules in (2) will init a real connection to a dev server upstream and are integration-tested by sending the real request to the real server; and the shell in (3) is basically so simple that it requires one end-to-end test that just makes sure that everything compiled together all right and can initialize at runtime. So this is what software looks like if you elevate Testing to be the One Core Pillar of the application, and demand "no mocks!" as part of that.

Q1, how do we apply this to a React app? Well, if you think in terms of UI, you can kind of think of an entire view as being kind of (3) as long as you aggressively oversimplify the behaviors: so you click on some part of some view and it dispatches some ButtonClicked data structure into some view-wide event queue, but it does no logic of its own. Reminds me of Redux, also reminds me a lot of Lit and web components where they just kind of emit CustomEvents but aren't supposed to do anything themselves.

Q2, how do components fit in. We have to be a little more careful there. You're talking about a modular architecture though, real thick components. Componentizing, takes us a step back from that ideal, right? It says "I don't want this to look like a single unified whole that is all tested at once, I want this to look like a composition of subsystems that are reusable and tested independently."

A simple example might be a tabbed view or accordion control, I want to coax the viewer through these N different steps, the previous step needs to be complete and then you can go to the next one. And I want the components to be each of these views. (The actual tab view or accordion view is of course another component, but it's a "thin component" in the above sense, it doesn't actually have any imperative library and the logic is relatively trivial, it doesn't generate the sorts of questions you're asking about.)

So just to roll up a random mental example, one of these tabs is some PermissionsEditor component, once you initialize it, it has everything it needs inside the component to fetch permissions from the API, fetch the current user, see what permissions the current user is allowed to grant to other users (or themselves?)... but the other tabs need to be dynamically responsive, once you add yourself to the group that can edit Flotsam and Jetsam, going to the Flotsam tab the "Edit" button should no longer be grayed out etc.

Then I think the proper way to view these thicker components, is as being inserted at level (2) into the main application? So the main application just treats them as imperative libraries, "I will give you a div and call your init_permissions_editor function with that div and you render into there. I will give you a channel to communicate events to me on. You will provide me the defs of the immutable data structures you'll send down that channel, I will provide deterministic transformations of those events into other events that I need to do."

With some caveats, yeah, I'd basically say this is the web-component model. Your external application just integration-tests that init_permissions_editor will render _something_ into a blank <div> given. Your PermissionsEditor component is responsible for integration-testing that it can create permission, add user to group, all of that, and is responsible for testing that it emits certain events when these things happen.

I use data-testid all the time with Vue.

Playwright scripts might sometimes be infuriating to modify, but it's the one single thing that has improved my app most.

> apparently removing a guard is the normal professional practice for a lot of well-founded reasons.

Dunno why there are no transparent guard to use when you want to see properly.

A flap disc is the more general solution for surface prep and grinding, as opposed to cutting.

The entire catelogue is actually available for free on their website: https://publications.americanalpineclub.org/

The end of the cold war- and a true market due to systemic competition? It gave union leverage, it gave politician a metric "continued existence" and it gave companies something to be or not to be.

Also you are right about this being the norm: https://en.wikipedia.org/wiki/Gilded_Age

This is what a free market without systemic competition always boils down into.

I think workers in prior generations (largely Silent and early Boomer) told us exactly what deviance was becoming normalized starting in the 70s through the 90s: managers who’d only ever managed, and don’t much care what they’re managing. MBAs and finance majors replacing the people who might not have any degree but did know what actual labor the company did and how the productive (not spreadsheets) side of the business functions, because they had personally done some of it for years.

They’re still around to ask about this stuff.

I think cutting way back on antitrust enforcement starting in the mid 70s accelerated the shift (that part, you may or may not hear from the older workers who watched this happening—though I bet their stories include some M&A activity as inflection points)

> The interesting question then becomes: what is the deviance that has become normalized so broadly?

Welchian management. "Greed is good". It's so infected the American psyche that people believe corporate management has a fiduciary duty to shareholders to the point that they legally must put profit above all else. That is not in any way the case, and no law has formalized any such thing. It's a choice, a choice made every day in nearly every company, to create human suffering in pursuit of profit and to eschew any concept of loyalty or ethics.

Jack Welch destroyed GE doing this, and his acolytes destroyed IBM, Boeing, and many other American institutions. His brand of management has now become the only brand of management taught across nearly two generations of MBAs. It is now the normal culture of American corporations.

I mean, being one half of a duopoly can’t help. Even if an airline wants to buy A320neos instead of 737-Maxes, say, it realistically can’t; there’s a waiting list of years. The 737-Max can be almost arbitrarily bad, and people still have to buy it.

Arguably, this is on the FTC and EC; if the mergers which created Airbus and current-Boeing hadn’t been permitted, the market would look very different, and there’d be less space for making a Terrible Plane; no-one would buy it.

You see this elsewhere; look at the old Soviet/Warsaw Pact car industry, or somewhat more arguably the pre-European-accession British car market (before it joined the EU, the UK was quite protectionist around cars). _Terrible_ products, but people had to buy them because nothing else was realistically available. So, why bother putting any effort into making them good?

This is debatable. Perhaps the poor quality management issues and lack of rigour that have been seen in various Boeing production facilities are a case of normalization of deviance. However, the original problem with the 737 MAX was the top management decision not to invest in a new airframe design for cost/strategic reasons, to oblige designers to implement various unsafe workarounds to accommodate larger and more fuel-efficient engines that made the plane unstable, and to ruthlessly silence engineers who argued that this was unsafe. This problem was compounded by the FAA's move to increased delegation of safety oversight to designer-manufacturers, which left it with insufficient ability independently to assess the new design. These are both big, important decisions made by top leaders of the two organizations, rather than the slow progressive evolution driven by people's efforts to optimize their bit of the workplace which characterizes drift to danger.

That really doesn’t answer the question. I’ve been in Told You So situations particularly last year where people wanted to take the safeties off. These were literally the same people who voted to put them on in the first place.

Kaboom.

The collapse of Russia would also be the result of normalization of deviance. Russia is operating way outside of it's "normal" geopolitical parameters. But seems to be going on as if nothing is going wrong.

The collapse of Russia could lead to nuclear war, misplaced bombs, or other calamities. After the collapse of the USSR, the West took great pains to ensure that the bombs outside the newly formed Russia didn't fall into the wrong hands.

There could be a replay of that scenario, but with an openly hostile and fragmented set of former-Russian states that won't allow Western "interference".