HN loves this idea of thinking in reverse. Is anyone here actually doing it? What problem did you solve?
Suppose I wanted to kill a lot of pilots
11–20 of 178 posts
Re: Suppose I wanted to kill a lot of pilots
#12Suppose I want to build a program that trades in the markets to make money. So to do the opposite I would try to lose money as fast as I could, according to this? But the way to do that is just to churn my book a lot and pay costs and spreads. It's not clear how that illuminates how to make money.
The interesting thing about the markets is that if you had a strategy that consistently lost money, oftentimes you can use the “opposite“ of that strategy, so to speak, to make money. This is one reason why it’s difficult to find these losing strategies.
> oftentimes you can use the “opposite“ of that strategy, so to speak, to make money
The opposite of Robinhooding might be buying a smattering of stocks and holding until infinity. It’s better than constantly trading options, a consistently losing strategy. But I wouldn’t call it a winner.
Re: Suppose I wanted to kill a lot of pilots
#13Suppose I want to build a program that trades in the markets to make money. So to do the opposite I would try to lose money as fast as I could, according to this? But the way to do that is just to churn my book a lot and pay costs and spreads. It's not clear how that illuminates how to make money.
> It's not clear how that illuminates how to make money.
I mean you did already start to think of some interesting starting points:
> But the way to do that is just to churn my book a lot and pay costs and spreads.
Don't churn your books, reduce costs, reduce spreads
Re: Suppose I wanted to kill a lot of pilots
#14Suppose I want to build a program that trades in the markets to make money. So to do the opposite I would try to lose money as fast as I could, according to this? But the way to do that is just to churn my book a lot and pay costs and spreads. It's not clear how that illuminates how to make money.
> the way to do that is just to churn my book a lot and pay costs and spreads
Iterate the question. Assuming a limited number of trades per quarter and a cap on spreads and commissions, how would one maximally lose money?
Re: Suppose I wanted to kill a lot of pilots
#15Isn’t this basically just a failure mode and effects analysis?
Re: Suppose I wanted to kill a lot of pilots
#16Suppose I want to build a program that trades in the markets to make money. So to do the opposite I would try to lose money as fast as I could, according to this? But the way to do that is just to churn my book a lot and pay costs and spreads. It's not clear how that illuminates how to make money.
Strawman. Suppose you are market maker and never have to pay a dime in fees. Morover, anything lost on spread is immediately refunded. If you have strategy that very quickly loses money in this harsh conditions, you have a winner.
> anything lost on spread is immediately refunded
This is unrealistic and produces fantasy strategies. Capping spreads over a unit of time is more realistic. That said, this way of thinking, iterated with discipline, does lead to a decent portfolio strategy. (Though not necessarily an outperforming one.)
Re: Suppose I wanted to kill a lot of pilots
#17Suppose I want to build a program that trades in the markets to make money. So to do the opposite I would try to lose money as fast as I could, according to this? But the way to do that is just to churn my book a lot and pay costs and spreads. It's not clear how that illuminates how to make money.
Think of it like the weather map that was mentioned. Your job is to fill in all of the parts of the map that will kill the pilot. Once you’ve exhaustively done that, the clear path will be evident.
Re: Suppose I wanted to kill a lot of pilots
#18HN loves this idea of thinking in reverse. Is anyone here actually doing it? What problem did you solve?
On a small scale I find this way of thinking useful in software development.
Say that you are implementing a role-based access control system.
And then ask yourself how can my RBAC system fail?
Well one way it could fail is if someone without the necessary role can operate on something that they ought not have access to.
So then create roles A, B, and C, and create a resource and say that group A can rw, and group B can r this resource. Then create a user and give that user role C. And then try to use this user in that role and try to read the resource. If it can, fail the test. Then another test where you try to write using such a user. If the resource was modified, fail the test.
This is as opposed to only thinking about what you want to happen, in which case you might be writing tests that only ensure that those that should be able to read/write can do so. And of course you want to test that too. But ensuring that those that should not be able to access a resource cannot is the more important thing to be sure of, and also the type of thing that might slip by unnoticed.
A system where those that should be able to access resources cannot, this will be detected in normal operation anyway, by way of users performing their usual tasks. But accessing resources you should not is the most critical and could go by unnoticed for a long time.
And that is why the tests that are written in the backwards thinking fashion are the most important ones.
Re: Suppose I wanted to kill a lot of pilots
#19Suppose I want to build a program that trades in the markets to make money. So to do the opposite I would try to lose money as fast as I could, according to this? But the way to do that is just to churn my book a lot and pay costs and spreads. It's not clear how that illuminates how to make money.
I know nothing about trading, so forgive me in advance - but I assumed the point of the article is to break it down a bit more specifically. What causes you to lose money quickly, what's the program doing - how do you stop it from doing those things? If you start to remove the roads to failure you're kind of forced onto the road to success - or at least a place where you're not falling into the places you're planning…
In the case of trading, removing the known roads to failure is no guarantee that you are now on the road to success. There are many MANY ways to fail in finance and more are being invented every day.
I suspect (but cannot prove) that this is because financial markets are "PvP" instead of "PvE", you trade against intelligent humans who can and do adapt their strategies to what they observe to be the strategy of other players in the market. If there is any form of rock-paper-scissors dynamic, this means that there will never be a stable strategy that keeps winning and so the method from the article will not work.
In most engineering problems OTOH, you are basically fighting against the environment. This can still be very difficult (see rocket science for example) but at least the laws of physics don't change from day to day. So, any progress in solving the problem you made yesterday will remain.
Successful application of the TRIZ method requires that the problem remains relatively stable, so that the options you "chip away" remain poor options forever. The markets are not like this and neither, I think, is career design.
Re: Suppose I wanted to kill a lot of pilots
#20Suppose I want to build a program that trades in the markets to make money. So to do the opposite I would try to lose money as fast as I could, according to this? But the way to do that is just to churn my book a lot and pay costs and spreads. It's not clear how that illuminates how to make money.
Think of it like the weather map that was mentioned. Your job is to fill in all of the parts of the map that will kill the pilot. Once you’ve exhaustively done that, the clear path will be evident.
How will you know you have indeed exhaustively done so though? This seems like a strategy that will only work for extremely well understood fields and things like "career development" that the article talks about are definitely not well enough developed that you can exhaustively enumerate all the ways it can go wrong.