This guy needs to organize & format his writing better, since he does have really interesting things to say.
[flagged]
Normalization of Deviance (2015)
41–50 of 228 posts
Re: Normalization of Deviance (2015)
#42Earlier quoted context omitted.
"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
I was once told this after raising the issue that "hey maybe an API that responds with root ssh passwords is a bad idea, and our clients are going to be pissed once they find out." And.. I was right. So often, citing Chesterton's fence is significantly more naive than what it attempts to criticize.
How is being right about wanting to make a change a refutation of the idea that knowing why people made a decision in the past is an excellent idea? Nothing about Chesterton's Fence asserts that people in the past always made good decisions, nor does it assert that perhaps what was a good decision then is a bad decision today.
It simply asserts that understanding why a thing is the way it is is valuable when making a decision to change it.
That understanding could be as simple as--to take a real world example that most readers here will remember--"They chose to install a hidden web server on the user's system, because they felt it was the best way to deliver user convenience given the resources and time the team had available."
We can still say it was a bone-headed choice to do that because it opened a massive back door to every user's system. And? What is the problem with looking into why they made that choice before arguing that the choice should be reversed with maximum prejudice?
Chesterton's Fence isn't a suggestion that no changes should be proposed, or that if you look into the original motivations you will change your proposal. Think of it as insurance against the possibility that every once in a while, you will discover a requirement that needs to be addressed with your suggested change.
I don't see where you're coming from that quoting Chesterton's Fence is even "criticism." It's a suggestion to take out a little insurance by doing a little homework.
Re: Normalization of Deviance (2015)
#43Earlier 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…
> There's often a wise tradeoff between criticizing systems you've just seen after being at the company 5 minutes and waiting 6 months to understand the context.
I know this is reasonable advice, but it makes me deeply cynical. After 6 months I will have learned to live in the shit (to use your term), and so it still seems like I have nothing to gain by speaking up or trying to fix things. A culture that accepts shitty code probably isn't supper demanding for an experienced developer who is accustom to the mess, so I'll just coast through my time and hop jobs after a few years.
If nobody wants to respectfully talk about my criticisms on day one, then they wont really want to at 6 months either. In the end I'm lead to believe I should have zero concern for code quality and only worry about my personal reputation.
Re: Normalization of Deviance (2015)
#44I 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.
In my experience, you cannot change an organization's culture with rules, mission statements, listing values, or giving speeches. They only way is to take down the old culture bearers. Some of them may be managers, but more often they are employees who have gained some organizational power. You'll often find them at the center of sticky organizational spider webs with approval processes such as purchasing and service…
> They only way is to take down the old culture bearers. ... To change the culture, these people have to go.
I was briefly head of engineering at a company that had several "old culture bearers" that made change impossible. I was something like the 3rd or 4th engineering leader over the space of a year. Apparently the person after me was actually allowed to fire a few of these people and was able to turn things around.
Re: Normalization of Deviance (2015)
#45"rictus of horror" - What a set of words to describe a response.
Re: Normalization of Deviance (2015)
#46I welcome others to share stories of the normalization of deviance in their companies.
One company I worked had no unit tests, no infrastructure as code, and no build server. This held strong for a while until enough developers implemented some unit tests, infrastructure as code (e.g. terraform), and a build server as skunkworks projects. Eventually management tolerated them, but never endorsed them. Some teams at the company still never embraced good practices because it wasn't forced on them.
I guess I've never worked at a company that valued unit tests across the whole of the engineering team. I introduced them and implemented them on my own team, but others ignored it.
Re: Normalization of Deviance (2015)
#47This guy needs to organize & format his writing better, since he does have really interesting things to say.
[flagged]
Probably being downvoted because the HN guidelines explicitly say to not comment about such things:
"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
Re: Normalization of Deviance (2015)
#48I 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…
> Like, how does the new hire (or anyone else) know the difference between "learning the complexity of the new system" and "internalizing/normalizing the deviance of this culture"?
If a new hire can't checkout, build, and test the software on the first day, then there is likely something either wrong with the hire or the infrastructure. A sufficiently old and arcane software system might take weeks before a new hire can make even a simple change, but that shouldn't impact those three items.
Re: Normalization of Deviance (2015)
#49Earlier quoted context omitted.
[flagged]
Probably being downvoted because the HN guidelines explicitly say to not comment about such things: "Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting." https://news.ycombinator.com/newsguidelines.html
As a matter of fact, it's in positive territory right now.
No, it's not a tangential annoyance. There are times when form IS function.
Re: Normalization of Deviance (2015)
#50This guy needs to organize & format his writing better, since he does have really interesting things to say.
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.
Yuck! I hate it when sites monkey around with max-width. I've got a nice 27 inch monitor. I want to use all of it. It's refreshing to see a site that doesn't insist on second-guessing the width that I set my browser window.