Live data from Hacker News

Normalization of Deviance (2015)

danluu.com

11–20 of 228 posts

Re: Normalization of Deviance (2015)

#11

I'm still reading, but I just got to the part about flaky, and I got annoyed because there are clear use cases for flaky or pytest-retry. If you have an integration test that relies on an unreliable system you do not control. Sure you can mock it out for a unit test, but if you want to make sure you catch breaking API changes, you need to hit the actual system. And if it works after retrying it a few times, then so b…

I think the issue is people using it when they’re too lazy to fix the test case.

Re: Normalization of Deviance (2015)

#12
post #5

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.

Been told that before. When I spoke up, I was told that I was new and shouldn't talk about things I know nothing about.

To be fair, you really shouldn't. You know nothing of the constraints that people are operating under, or the political or cultural landscape you're dealing with, so you just come off like a preachy academic.

Re: Normalization of Deviance (2015)

#14
post #10
post #5

Earlier quoted context omitted.

Been told that before. When I spoke up, I was told that I was new and shouldn't talk about things I know nothing about.

There's often a wise tradeoff between criticizing systems you've just seen after being at the company 5 minutes and actually spending some time at the company to learn the historical context of why the thing you think is insane/shit is insane/shit before telling everyone who built it how insane/shit it is. People generally don't wake up in the morning and go into work motivated to make insane/shit things - context, t…

You (in fashion of the article) missed the point I made: I was explicitly asked to speak up as the new employee and when I did I was told to stop speaking up. When I brought it up in the meeting I gave my two week notice, he admitted to saying that and apologized.

Re: Normalization of Deviance (2015)

#15
post #5

Earlier quoted context omitted.

Been told that before. When I spoke up, I was told that I was new and shouldn't talk about things I know nothing about.

To be fair, you really shouldn't. You know nothing of the constraints that people are operating under, or the political or cultural landscape you're dealing with, so you just come off like a preachy academic.

See the other comment I made: I was explicitly asked to speak up.

Re: Normalization of Deviance (2015)

#17

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.

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 who started the project might be able to hit F5 in 15 different windows and get it to sorta kinda work, but new hires they are hiring to work on it are quitting right away and somehow they can never get it into production.

There should be no controversy at all that complete instructions for installing everything required for a dev to build the project and work on it should exist and it should be possible to complete this task in hours, not the weeks that it frequently takes. And, no, "docker" is not an answer to this anymore than "The F5 Key is a Build Process"

https://blog.codinghorror.com/the-f5-key-is-not-a-build-proc...

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.

You are right that a company might have good reasons for doing things in an unobvious way, but most of the time when nobody at a company claims to understand what the company is doing except for the CEO and people aren't too sure about the CEO, it is the fault of the company lacking alignment, not a natural property of freshers.

Re: Normalization of Deviance (2015)

#18
post #4

These stories ring so, so true. Once worked at a company whose infrastructure issues were so deep and festering that after fighting a fire, my boss told me, "If you go to the press about this, the client will sue us and everyone who works here will lose their jobs."

That's what I never understood about this story; did you guys have any suspicion it would dump radiation into the patient all at once, or was this like a concurrency bug

Re: Normalization of Deviance (2015)

#19
post #10
post #5

Earlier quoted context omitted.

Been told that before. When I spoke up, I was told that I was new and shouldn't talk about things I know nothing about.

There's often a wise tradeoff between criticizing systems you've just seen after being at the company 5 minutes and actually spending some time at the company to learn the historical context of why the thing you think is insane/shit is insane/shit before telling everyone who built it how insane/shit it is. People generally don't wake up in the morning and go into work motivated to make insane/shit things - context, t…

"Making good decisions, therefore, requires understanding past decisions. Without knowing how things came to be, it’s easy to make things worse."

https://thoughtbot.com/blog/chestertons-fence

Post reply on HN