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…
Normalization of Deviance (2015)
11–20 of 228 posts
Re: Normalization of Deviance (2015)
#12I 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.
Re: Normalization of Deviance (2015)
#13Re: Normalization of Deviance (2015)
#14Earlier 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…
Re: Normalization of Deviance (2015)
#15Earlier 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.
Re: Normalization of Deviance (2015)
#16This guy needs to organize & format his writing better, since he does have really interesting things to say.
Re: Normalization of Deviance (2015)
#17I 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…
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)
#18These 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."
Re: Normalization of Deviance (2015)
#19Earlier 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…