Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Suppose I wanted to kill a lot of pilots

historyofyesterday.com

Post reply on HN
Print view View original

151–160 of 178 posts

Re: Suppose I wanted to kill a lot of pilots

#151

Post by bumby »

nohuck13 wrote: post #138
bumby wrote: post #134

Earlier quoted context omitted.

It can depend on accountability mechanisms. I would like to see more contracts that give bonuses to companies that come in under budget and under schedule and penalize the overly optimistic ones that never seem to hit their target. This is becoming more common in some domains.

What domains is it becoming more common in, in your experience?

The predominant domain to use this type of contract is infrastructure construction. I haven’t personally seen it used in software development outside of control systems but I can’t immediately think of reasons why it couldn’t be extended to other domains as well

Re: Suppose I wanted to kill a lot of pilots

#152

Post by radicalbyte »

jacquesm wrote: post #45
ethbr0 wrote: post #42

I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…

Spot on. They used to call me 'Dr. No' because that is exactly what I would do, but it saved us tons of money so it was tolerated. We also actually delivered on time and within the budget but I'm sure it cost us contracts to more optimistic competitors.

I do exactly the same thing - it's all part of the project and system analysis and it helps you neatly sidestep potential pitfalls.

It reminds me of the whole "hero developer" or "hero team" myth; teams who do not do proper analysis, build a turd, but work insane hours stopping the turd falling to pieces.

The people who do that come out looking like heros, when they could have totally avoided the drama in the first place.

Re: Suppose I wanted to kill a lot of pilots

#153

Post by fastball »

hansvm wrote: post #115
fastball wrote: post #51

Earlier quoted context omitted.

We've built a React/Redux application[1] that people keep telling us is very snappy, and we definitely haven't optimized as much as is possible, so from my experience React/Redux is not inherently slow and bloated. [1] https://my.supernotes.app

It seems pretty snappy aside from the first page load (and refreshes, ...). Not perfect (some actions take a few frames sometimes), but not anything I'd spend more dev time on. The first page load is nightmarishly slow. I tend to avoid services that pull in that much data because they're nearly unusable in low bandwidth scenarios (e.g., lots of stores or other commercial buildings made from steel, if you wanted to ch…

Thanks for the feedback! After first load the assets should actually all be cached in your browser, so subsequent loads will be much faster (including full page refresh). But yes the initial bundle size is one of those things we could probably spend more time optimizing for.

We recently released desktop apps (and will hopefully release mobile apps soon) where this is of course a non-issue.

Could you tell me which keyboard shortcuts you are having problems with? Our intent is definitely not to hijack anything we don't use.

Thanks for the note on the friend finder. Unlike many other platforms, we don't actually require users to have a surname, so we felt that if privacy was a concern with regard to name the best solution is for a user to only include their first name. But I can see how that still isn't perfect from a privacy perspective. We are working on improving the way friends work on the platform and will try to improve that as part of it.

Thanks again for all the feedback, very helpful.

Re: Suppose I wanted to kill a lot of pilots

#154

Post by asimjalis »

I did not like this article because it was superficial, clickbaity, and did not explain the main idea with a worked out example.

> Charlie inverted the problem in a similar way to the TRIZ practitioners — if he wanted to kill pilots, he could get them into icy conditions whereby they couldn’t continue flying, or put them in situations where they would run out of fuel and fall into the ocean. So he drew more applicable maps and better predicted the weather factors that were relevant by keeping in mind the best ways to do the exact opposite of bringing his pilots home.

This tells me nothing about how Charlie Munger avoided planes crashing. There has to be more to this than this trite summarization.

Can someone shed some light on this and explain why this is insightful.

Re: Suppose I wanted to kill a lot of pilots

#155

Post by fastball »

olvy0 wrote: post #105
fastball wrote: post #51

Earlier quoted context omitted.

We've built a React/Redux application[1] that people keep telling us is very snappy, and we definitely haven't optimized as much as is possible, so from my experience React/Redux is not inherently slow and bloated. [1] https://my.supernotes.app

FWIW it takes 7-8 seconds to load on my computer as well, on the latest Firefox, with a good CPU. This has finally convinced me to not waste my time learning React, at least for now.

Yep, first load isn't very quick, as there are a lot of things that need to be loaded which are never going to be very small. However, first load only happens once. After that the assets should be cached in your browser and loads should be much faster.

There is definitely something to be said for faster first loads, but unlike many other sites on the web, ours is of course optimized for consistent/repeated use, so in the scheme of things first load is negligible compared to making sure it runs fast while actually using it 100s of subsequent times, which (I hope) it does.

Definitely wouldn't let that discourage you from learning React. If you want a smaller bundle size, you can use Preact[1], which is nearly a drop-in replacement for React's runtime but much smaller.

[1] https://preactjs.com/

Re: Suppose I wanted to kill a lot of pilots

#156

Post by bluetwo »

asimjalis wrote: post #154

I did not like this article because it was superficial, clickbaity, and did not explain the main idea with a worked out example. > Charlie inverted the problem in a similar way to the TRIZ practitioners — if he wanted to kill pilots, he could get them into icy conditions whereby they couldn’t continue flying, or put them in situations where they would run out of fuel and fall into the ocean. So he drew more applicabl…

I thought the article was well written. Can I suggest trying again?

The point was not tho explain HOW to avoid planes crashing, it was to explain how he saw his job not that of providing super-clear weather reports ,but focusing the reports on factors that would cause problems for pilots.

Re: Suppose I wanted to kill a lot of pilots

#157

Post by Wronnay »

asimjalis wrote: post #154

I did not like this article because it was superficial, clickbaity, and did not explain the main idea with a worked out example. > Charlie inverted the problem in a similar way to the TRIZ practitioners — if he wanted to kill pilots, he could get them into icy conditions whereby they couldn’t continue flying, or put them in situations where they would run out of fuel and fall into the ocean. So he drew more applicabl…

Imagine the worst possible outcome and do the opposite. That will light your focus on what matters.

I think that's the essence of the article.

Re: Suppose I wanted to kill a lot of pilots

#158

Post by bluetwo »

ethbr0 wrote: post #42

I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…

You know at first glance I would say this isn't true, since SWOT analysis covers this pretty well. Then again, I didn't learn SWOT in any programming class, it was in business classes.

Re: Suppose I wanted to kill a lot of pilots

#159

Post by panarky »

ethbr0 wrote: post #42

I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…

Instead of doing more "post-mortems" after projects fail, try doing "pre-mortems" before projects begin.

Imagine it's 6 months from now, and the project we're about to begin is half complete and twice over budget. What factors will the post-mortem identify as causes for the failure?

Learn the lessons before the project begins, not after it fails.

Re: Suppose I wanted to kill a lot of pilots

#160

Post by bluetwo »

kaycebasques wrote: post #11

HN loves this idea of thinking in reverse. Is anyone here actually doing it? What problem did you solve?

All the time. When a politician, member of the media, or a client says "X causes Y" I'll usually follow up with one of the following:

- Does X ALWAYS cause Y? - Can Y happen WITHOUT X? - Could X cause OTHER things that cause Y?

Post reply on HN