Live data from Hacker News

Normalization of Deviance (2015)

danluu.com

211–220 of 228 posts

Re: Normalization of Deviance (2015)

#211

Earlier quoted context omitted.

The flip side of "quality first" / stop the line is getting killed in market by a worse but faster or cheaper solution. You are locked in game theory with your regulators (if you have any) and your competitors. It's disappointing (and career limiting) to do the "right" engineering and lose because you didn't correctly gauge the risk tolerance of the market. I don't think there's any one answer for this. My observatio…

This is mostly true but for things like medical devices, aerospace, industrial control and so on any corner cutting should be allowed. I'm pretty sure that Philips right now has some thoughts on this as does Medtronic. Those two should have never happened and personally I'm all for liability of executives in such cases.

Should not be allowed, apologies. I always spot these errors only after the edit window has closed.

Re: Normalization of Deviance (2015)

#212
post #38

Earlier quoted context omitted.

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…

> 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??" To that speaks of the caliber of programmers hired. If all they have seen is $TODAYS_HOT_JS_FRAMEWORK and wrote nothing but a web app using $TODAYS_HOT_JS_FRAMEWORK they might not grasp the fundamentals that would make then realize that frameworks are just abstractions (and not that different from…

There are less complicated VCSes than git, so this sounds like a cop-out.

Re: Normalization of Deviance (2015)

#213
post #156

Earlier quoted context omitted.

> More importantly, I think more accurate nukes along with good satellite multispectral and signals intelligence means that top generals carrying out orders for nuclear first strikes can be more certain that they're signing their own death warrants. How would you do that? In the event of a nuclear war, my understanding is they'll mostly be flying around on special command and control planes. I don't think nuclear int…

Ahh, yes, the flaw in my optimism is that those doomsday planes do in fact have direct radio links to send the PAL codes and authenticated launch orders directly to the silos, submarines, and standby bombers. The tier of generals just not senior enough to have a seat on the doomsday planes isn't in the emergency line of command to the nuclear weapons. So, regardless of how powerful a small coalition of those generals…

> So, I guess our last hope is that a small conspiracy of generals just under the doomsday plane tier would stage a coup once the nuclear sabre rattling reached a sufficient magnitude, before the nuclear first strike order is given.

Even if that happened, it's just buying a little time. Some set of leaders/generals in the future will push the button (or build automated systems that do it for them).

Disarmament ain't gonna happen, and anything with a small chance of happening will happen, given a long enough period of time.

Re: Normalization of Deviance (2015)

#214
post #175

Earlier quoted context omitted.

> 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??" To that speaks of the caliber of programmers hired. If all they have seen is $TODAYS_HOT_JS_FRAMEWORK and wrote nothing but a web app using $TODAYS_HOT_JS_FRAMEWORK they might not grasp the fundamentals that would make then realize that frameworks are just abstractions (and not that different from…

I do not understand how teams work without source control. I don't mean that (only) in the "WTF are you doing, I don't understand why you would do that" colloquial sense. I literally cannot conceive how they work. Do people just... change files and then email the whole file to the other developers and hope nobody else was working on that file? Do they at least have patches ?

I've seen people exchanging thumb drives.

No concept of a patch. They spent most of the afternoon and evening "performing the manual merge and stabilizing the release", meaning rebuilding and deleting lines until it compiled.

I wish I was kidding.

Re: Normalization of Deviance (2015)

#215

Earlier quoted context omitted.

Form over substance. Toyota, and other Japanese companies, are living the substance of Lean and TPS. Most other companies implement the form and hope they magically get where Toyota is without any additional effort. Same goes for Agile and any other management "philosophy".

Yes, it's the essence of cargo culting. The tech world is also full of this stuff. The number of small companies that I've seen that implement the Spotify development team structure is pretty tragic. People are always looking for silver bullets and the industry is rife with examples of this kind of thing.

Even better, "we're like Google" except they give you a blank stare where you ask about the 20% time, free food, compensation or where they hire from. Turns out it's all bootcamp/local wages no stock, no 20% time. But hey, they have beanbag chairs!

Re: Normalization of Deviance (2015)

#216
post #111

[flagged]

Can you please not post unsubstantive comments? It looks like you've been doing it repeatedly, and we're trying for something else here. https://news.ycombinator.com/newsguidelines.html

Dang, I try to behave, I really do. That little quip so clearly suggested itself it would have been physically uncomfortable not to make it. I will re-read the guidelines today and redouble my efforts.

Re: Normalization of Deviance (2015)

#217

Earlier quoted context omitted.

This is true, but there are cases where "months" makes sense. E.g. avionics, industrial, medical.

That can extend the time, yes. I had a caveat about that but apparently edited it out before submitting. But that only explains or justifies the delays if there is value added. I work in aerospace and these were avionics and related systems. The bad ones did not have quality as a reason, though the good ones did. The bad processes were swamped with manual testing (which was non-comprehensive and error prone) or reall…

I totally agree that "process" on its own doesn't justify long turnarounds. If you had one part of your code that was taking 2/3 of the run-time, it should get plenty of scrutiny, and the same is true of processes.

Re: Normalization of Deviance (2015)

#218
post #107

“Let's say you notice that your company has a problem that I've heard people at most companies complain about: people get promoted for heroism and putting out fires, not for preventing fires.” My first day at work at big-laser-company. Manufacturing engineer for a laser (then) so complex, it required a PhD to solve problems to get units out the door. The product was a ring laser. What that means is that the laser bea…

They proved you wrong, at great cost.

A more correct and polite version of your advice: "It will cost us a lot more to ship this as-is, and fix it later, than it will to delay shipment and fix it now. Is it too late to do that? Did we over-commit to shipping now?"

It wasn't your responsibility to come up with that version. It was your manager's responsibility. It was also their responsibility to find the necessary decision-makers and involve them directly. I would argue that this sort of work is the only real way that "management" can provide value in the first place.

Somehow, socially, it's incredibly common for people to value the inverse of that job. People assume it is "good work" for a manager to successfully ignore unpopular concerns, and push through to the end, no matter how inefficient that makes the journey.

That works out in the case that the shipping date was over committed, such that a delay would cost more than fixing it later. Even so, that entire situation would be avoided by refusing to over-commit shipping dates in the first place. That's the same responsibility applied earlier in time, so a manager that behaves the way I have described could factor out the entire problem at its source.

This is what the average person should learn about management. Even if it's not their job personally, there is a lot of leverage behind the decision a worker makes about what management behaviors to socially favor, and what behaviors to socially reject. That leverage is multiplied at every level up the hierarchy, making that the opinion of someone in a management role is very significant, and the opinion of someone in an executive role is crucial.

It's really difficult to be explicit about opinions. You can't really put them in your resume, but at the same time, an opinion on management style may be an executive's primary value contribution!

Re: Normalization of Deviance (2015)

#219
post #66
post #63

Earlier quoted context omitted.

> Every time I've heard someone quote Chesterton's Fence, it's always been as a means to halt the conversation. From here forward you can say that almost every time you've heard someone quote Chesterton's Fence, it's almost always been as a means to halt the conversation. Today, you've encountered a counter-example, and a very firm counter-example, at that. To my mind, Chesterton's Fence is explicitly NOT about shutt…

These kinds of responses shouldn't be uttered as a way of shutting down a conversation. If that's someone's intent, they are abusing their privilege. To be perfectly honest, your quote came across in that spirit. Anywho, peace!

This is very good feedback, thank you.

Re: Normalization of Deviance (2015)

#220
post #152

Earlier quoted context omitted.

Type systems do not replace testing, and if a test works after retrying it then it is probably not something that a type system would be able to catch.

> Type systems do not replace testing They're a good substitute for many of the use cases of testing. > if a test works after retrying it then it is probably not something that a type system would be able to catch. Type systems are pretty good at catching incorrect concurrency logic these days, and getting better all the time.

Yes they are not equivalent, but creating languages without a strict type system and the proposition of test driven development are going back and fort in strictness. It is beneficial to have a more strict programming language, but it can be uncomfortable and burdensome. So I find interesting we keep going back and forth in this dimension.
Post reply on HN