How Completely Messed Up Practices Become Normal • Hacker News Board

Re: How Completely Messed Up Practices Become Normal

#21

Post by spacecowboy_lon » Wed, Dec 30, 2015, 2:50 PM UTC

TazeTSchnitzel wrote: post #7

This reminds me that I've acclimatised to one specific test in the PHP interpreter test suite always failing on OS X. I should go and make it either not run on OS X, or modify it so it will actually pass. That way, when someone eventually actually breaks that function, they'll notice.

That also reminds me back when I did x.400 mail for a living (at british telecom) Sprint had a implementation that completely contradicted the ITU standard - Sprints response was well just put a fix in for sprint's mail systems.

ICL also though that even if the standard said such and such index MUST start at 1 that they woudl start it at 0 - cue some nice divide by zero errors - Not surprised we don't have a UK Mainframe company any more.

Re: How Completely Messed Up Practices Become Normal

#22

Post by vinceguidry » Wed, Dec 30, 2015, 2:51 PM UTC

apalmer wrote: post #19

vinceguidry wrote: post #15

Most of what the author is complaining about boils down to business needs being more important than the needs of the engineering team. To be blunt, they're paying you to do a job, not to make the organization better. That's what they pay the leadership for. You want to be part of the leadership, work your way through the ranks or start your own business. My life got much, much easier once I learned to stop straining…

This is my thinking also... it came to me over a long time, and typically has a lot to do with why I switch jobs. At a certain point i give up struggling against the 'WTF' and just start going along with the flow, then one day i look at the stuff i am doing, realize working at the place is making me a worse professional, and move along... However I do want to note that in general these things do have real concrete ne…

> However I do want to note that in general these things do have real concrete negative impacts on the bottomline of the organization.

Oh absolutely. But your duty to that organization is to raise these issues to the person best-equipped to see the bigger picture, and to do your best to convince him it's a real problem. Once you've done that, your work is done, you have just done more to help your organization than 100 blog posts would have accomplished, and more than 90% of the other employees would have ever done.

You can comfortably use this approach once a month and be vastly more effective than everybody else at your company at bringing about change. Simply raise an issue, have a conversation about it, then drop it if you get no support.

Re: How Completely Messed Up Practices Become Normal

#23

Post by mwcampbell » Wed, Dec 30, 2015, 2:55 PM UTC

> There’s the company with a reputation for having great engineering practices that had 2 9s of reliability last time I checked, for reasons that are entirely predictable from their engineering practices. This is the second thing in a row that’s basically anonymous because multiple companies find it to be normal. Multiple companies find practices that lead to 2 9s of reliability to be completely and totally normal.

I'd like to know more about these practices that lead to 2 9s of reliability. Can you give specific examples of such practices, albeit not the companies themselves?

Re: How Completely Messed Up Practices Become Normal

#24

Post by draw_down » Wed, Dec 30, 2015, 2:56 PM UTC

This post seems so good and so self-evidently true that I'm surprised at the amount of pushback it's getting here. Not sure what else to say about it.

Well, I'll say this- the "@flaky" thing is pretty mind-blowing. In my own company I have noticed many engineers have a disturbing level of comfort with deciding something is a "mystery". There are no mysteries in what we do. The test fails because something is fucked up. Flappy tests are annoying, but the right thing to do is to address the situation.

Re: How Completely Messed Up Practices Become Normal

#25

Post by karlkatzke » Wed, Dec 30, 2015, 2:58 PM UTC

The author detailed precisely why I left a former Y-Combinator company, Return Path.

"As far as I can tell, what happens at these companies is that they started by concentrating almost totally on product growth. That’s completely and totally reasonable, because companies are worth approximately zero when they’re founded; they don’t bother with things that protect them from losses, like good ops practices or actually having security, because there’s nothing to lose.

The result is a culture where people are hyper-focused on growth and ignore risk. That culture tends to stick even after company has grown to be worth well over a billion dollars, and the companies have something to lose. Anyone who comes into one of these companies from Google, Amazon, or another place with solid ops practices is shocked. Often, they try to fix things, and then leave when they can’t make a dent."

Re: How Completely Messed Up Practices Become Normal

#26

Post by draw_down » Wed, Dec 30, 2015, 3:00 PM UTC

TazeTSchnitzel wrote: post #7

This reminds me that I've acclimatised to one specific test in the PHP interpreter test suite always failing on OS X. I should go and make it either not run on OS X, or modify it so it will actually pass. That way, when someone eventually actually breaks that function, they'll notice.

Sounds like a good idea to me!

Re: How Completely Messed Up Practices Become Normal

#27

Post by dfc » Wed, Dec 30, 2015, 3:08 PM UTC

This post's style and "quality" of writing is really aggravating. I felt like I was banging my head against the wall after reading so many run on sentences or paragraphs that start with the same contraction. Other times the writing is so poorly executed I cannot tell what the author is trying to convey. For example what is going on in this paragraph:

"There’s the company with a reputation for having great engineering practices that had 2 9s of reliability last time I checked, for reasons that are entirely predictable from their engineering practices. This is the second thing in a row that’s basically anonymous because multiple companies find it to be normal. Multiple companies find practices that lead to 2 9s of reliability to be completely and totally normal."

Re: How Completely Messed Up Practices Become Normal

#28

Post by turnip1979 » Wed, Dec 30, 2015, 3:24 PM UTC

Good article. I could think of reasons why people kept leaving in their first year at the company where they had freedom. The author says the company had the beat parts of Netflix and valve. What is the author referring to?

Re: How Completely Messed Up Practices Become Normal

#29

Post by dman » Wed, Dec 30, 2015, 3:29 PM UTC

An anecdotal observation is that the worst offenders in terms of institutionalized bad practices also have a culture of failing upwards. ie incentive structures are setup in a way where you create your mess so fast that you get promoted and someone else has to deal with the aftermath of what you did. In such an environment slowing down to do the right thing invariably means that you are setting yourself up to inherit a mess created by someone else.

Re: How Completely Messed Up Practices Become Normal

#30

Post by hyperpape » Wed, Dec 30, 2015, 3:36 PM UTC

dfc wrote: post #27

This post's style and "quality" of writing is really aggravating. I felt like I was banging my head against the wall after reading so many run on sentences or paragraphs that start with the same contraction. Other times the writing is so poorly executed I cannot tell what the author is trying to convey. For example what is going on in this paragraph: "There’s the company with a reputation for having great engineering…

It's a little bit awkward. Still, I find it oddly fascinating that you're confused, because I can't figure out what's confusing.

There is a company Dan Luu knows about.

This company has a reputation for great engineering practices.

This company had 2 9s of reliability when Dan last checked.

The reason it has 2 9s of reliability is a predictable result of its engineering practices.

Although this example is about a specific company, you can't identify the company from the description.

You can't identify the company from the description because it is a description that applies to many companies.

You also can't identify the example from the previous paragraph [of Dan Luu's post] because that paragraph's description also applies to many companies.

Multiple companies have engineering practices that cause such reliability problems and find these engineering practices to be completely and totally normal.