Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Normalization of Deviance (2015)

danluu.com

Post reply on HN
Print view View original

81–90 of 228 posts

Re: Normalization of Deviance (2015)

#81

Post by RoddaWallPro »

Sesse__ wrote: post #37
xnorswap wrote: post #25

Earlier quoted context omitted.

If you don't have a reader view in your browser, just paste this into your global CSS: p { line-height: 1.7; max-width: 60em; font-size: 1.2em; margin-left: 5em; } It pretty much fixes the default readability which is essentially zero on this site otherwise.

Dan Luu talks a bit about this here: https://twitter.com/danluu/status/1115707741102727168

One of the more hilarious takes I've seen. "There are no papers for this, and I choose to disregard the countless number of people who say it is much easier for them to read if the line lengths are constrained as they are in a book or scroll or every other form of human writing ever put on this earth, so I will not make my site easier to read. F you."

Re: Normalization of Deviance (2015)

#82

Post by jwilk »

sebstefan wrote: post #16
AlbertCory wrote: post #13

This guy needs to organize & format his writing better, since he does have really interesting things to say.

Firefox has the "reader view" option toggleable with F9 for when you stumble upon unreadable designs, if you want

It's F9 on Windows, command-option-r on macOS, and ctrl-alt-r elsewhere.

https://support.mozilla.org/en-US/kb/firefox-reader-view-clu...

Re: Normalization of Deviance (2015)

#83

Post by jpollock »

somat wrote: post #78

A thought experiment. When is it "Normalization of Deviance"? and when is it a "Efficiency Optimization"? I mean, the difference is pretty clear after something has failed, But very murky before.

It is Efficiency Optimization when you know why the rule is there, and having made an estimation of the risks, perform a cost-benefit analysis.

aka "Chesterton's Fence"

Otherwise, it's "Normalization of Deviance":

* The build is broken again? Force the submit.

* Test failing? That's a flaky test, push to prod.

* That alert always indicates that vendor X is having trouble, silence it.

Those are deviant behaviours, the system is warning you that something is broken. By accepting that the signal/alert is present but uninformative, we train people to ignore them.

vs...

* The build is always broken - Detect breakage cause and auto rollback, or loosely couple the build so breakages don't propagate.

* Low-value test always failing? Delete it/rewrite it.

* Alert always firing for vendor X? Slice vendor X out of that alert and give them their own threshold.

Re: Normalization of Deviance (2015)

#85

Post by robocat »

Sesse__ wrote: post #37
xnorswap wrote: post #25

Earlier quoted context omitted.

If you don't have a reader view in your browser, just paste this into your global CSS: p { line-height: 1.7; max-width: 60em; font-size: 1.2em; margin-left: 5em; } It pretty much fixes the default readability which is essentially zero on this site otherwise.

Dan Luu talks a bit about this here: https://twitter.com/danluu/status/1115707741102727168

Great thread!

Designer says: my opinion is right because A. Dan shows: A is not factual. Designer says: my opinion is right because of B.

Dan notices behaviours, and then he writes compellingly about those behaviours.

Re: Normalization of Deviance (2015)

#86

Post by whats_a_quasar »

jkaptur wrote: post #38
PaulHoule wrote: post #2

I like the bit about Let's look at how the first one of these, “pay attention to weak signals”, interacts with a single example, the “WTF WTF WTF” a new person gives off when the join the company. and kinda wonder if a company that prioritized not getting this reaction from new hires might find it is the most impactful thing they can do in terms of culture.

Just to give a different, concrete, perspective (and push a hot button HN issue), I've spent a fair amount of time working on extremely large web applications, and by far the #1 "WTF WTF WTF" thing that new hires say is "what do you mean you aren't using $TODAYS_HOT_JS_FRAMEWORK??" Once you get away from "should we use version control" and into actually difficult software engineering questions, it's not clear how to…

There's a whole section about how to balance a fresh perspective, in "solutions". The best way is for an effective VP to hear the WTFs of new hires, apply engineering judgement, and make changes based on that signal. If management is not the ones creating the deviance, they ought to be able to tell what reactions are just unfamiliarity with the system and what are signs of something actually being broken. The article is arguing that most people ignore those weak signals by default, and ought to pay more attention to them, not that they're always reliable.

Re: Normalization of Deviance (2015)

#87

Post by manicennui »

jpollock wrote: post #83
somat wrote: post #78

A thought experiment. When is it "Normalization of Deviance"? and when is it a "Efficiency Optimization"? I mean, the difference is pretty clear after something has failed, But very murky before.

It is Efficiency Optimization when you know why the rule is there, and having made an estimation of the risks, perform a cost-benefit analysis. aka "Chesterton's Fence" Otherwise, it's "Normalization of Deviance": * The build is broken again? Force the submit. * Test failing? That's a flaky test, push to prod. * That alert always indicates that vendor X is having trouble, silence it. Those are deviant behaviours, the…

Unfortunately I don't find that most software engineers understand the difference between actually determining costs and benefits and choosing to make certain tradeoffs and rationalizing whatever choice they already made.

Re: Normalization of Deviance (2015)

#88

Post by jpollock »

manicennui wrote: post #87
jpollock wrote: post #83

Earlier quoted context omitted.

It is Efficiency Optimization when you know why the rule is there, and having made an estimation of the risks, perform a cost-benefit analysis. aka "Chesterton's Fence" Otherwise, it's "Normalization of Deviance": * The build is broken again? Force the submit. * Test failing? That's a flaky test, push to prod. * That alert always indicates that vendor X is having trouble, silence it. Those are deviant behaviours, the…

Unfortunately I don't find that most software engineers understand the difference between actually determining costs and benefits and choosing to make certain tradeoffs and rationalizing whatever choice they already made.

I think that's ok, For me, it's more about "change the system, instead of ignoring it".

Once you change the system (document/rules/alerts/etc), then if it breaks, you change it again and learn the lesson. Both are conscious decisions by the org.

Re: Normalization of Deviance (2015)

#89

Post by msm_ »

albertop wrote: post #41
AlbertCory wrote: post #13

This guy needs to organize & format his writing better, since he does have really interesting things to say.

[flagged]

Maybe because it's an absolute statement ("this person needs to organise & format his writing better") for a something mostly subjective.

In my opinion the website is readable, fast, lightweight, not distracting and pleasant to read. It's also accessible for people with disabilities, responsive, and works everywhere. I understand that not everyone is as into minimalism as me, just pointing out the problem in "this person needs (...)".

Re: Normalization of Deviance (2015)

#90

Post by skissane »

PaulHoule wrote: post #17
lo_zamoyski wrote: post #7

Earlier quoted context omitted.

That doesn't seem like a healthy standard b/c it grounds decision making in appearances rather than principles and prudential judgements. Certainly, such feedback or opinions can be worth considering as a way of getting at what principles are being violated and deciding whether these violations are tolerable or what ought to be done about them. A fresh pair of eyes could help. But an untrained pair of eyes might also…

Yes and no. But 2/3 of the time the problem is that the company has no documented build process or something obvious like that . They have time to spend 2 years failing to deliver a product because they don't know how to build it, but when somebody asks "How do we build it?" the answer is "Don't waste our time asking stupid questions." Of course they have been wasting time not knowing how to build the system, the guy…

> It is not "Docker" that solves the problem, it is the discipline of scripting the image build process into a dockerfile. If you know how to write a dockerfile you can write a bash script that runs in 20 seconds as opposed to having Docker spend 20 minutes downloading images and then crash because of a typo.

The problem is the bash script may end up depending on poorly understood aspects of the local setup (global config files, installed packages, etc) - it might work fine now, but then nobody runs it for 12 months and there’s some churn in personnel and suddenly people are trying to work out why it crashes. Dockerfiles can avoid some of that stuff, although not always (e.g. the common problem that if you don’t fix the versions of packages to be installed, an updated package is released which then breaks the Dockerfile)

Post reply on HN