Suppose I wanted to kill a lot of pilots

Forgive me, but I think you've illuminated the exact way to be a great investor repeated by buffet ad nauseam. Don't buy and sell repeatedly - you lose on the transaction fees. Act like you have a punch card with 10 holes for your entire life and you use one every time you buy a company. That way you'll really consider you decisions and won't lose money on transaction fees from repeated buying and selling.

Buy great companies cheap or at a good price. Only sell if you think they are technologically threatened (horse and cart vs car situation) or have grown to take up too much of your portfolio (like up 50%+ of your portfolio).

This is basically how buffet got mega rich. Amex, Coca Cola, Apple, Geico, etc. These few big bets made him a very rich man and he still holds them today.

Losing 1% per year to transaction/currency/ management fees per year really adds up over a lifetime. And it doubly matters when you are rich enough to pass the cap gains threshold. 20% lost on every time you sell at a profit in the UK - that compounds too!

Or - if you can't be bothered with the effort to try and beat the market - you've also illuminated another bit of buffets advice. Invest in and hold an s&p ETF through your whole life.

In fact Munger is one of the biggest proponents of "invert, always invert"

Maybe not quite the same thing, but I recently won an innovation challenge for improving public bathrooms.

I started with what actions people take that make the bathroom as disgusting (pee everywhere, vomit, shoving food in the walls, etc) and then determining defensive mechanisms from there.

Suppose I wanted to make a program inscrutable, hard to modify, hard to test, heavily coupled, and hard to reason about:

- hide information so that it's not queryable

- force information to flow through multiple hops

- make it hard/impossible to set the true state of the system in its entirety

- allow state to be mutated silently

- give interfaces roles and force certain state to have to flow through specific paths

- multiple concurrent access

- pointers

- spray the app across as many machines as possible

Sounds familiar, maybe like a scathing criticism of OOP? Well check this out. What if I wanted to make a program as slow and bloated as possible?

- put all state in one place. Bonus points if you can bottleneck it and force all changes to be well-ordered and sequential

- all data has to be immutable and copied over in its entirety when propagated

- use larger data structures than necessary. Lots of wrapping and indirection

- no caching. Can't trust data unless it's fresh

- read/write from disk/net tons

- use scripty garbage collected languages

- spray the app over as many machines as possible

The latter kind of feels like a criticism of FP, though really it's more critical of distributed monolith. What if I want to make my app as vulnerable to outage and overload as possible?

- concentrate the app in as few machines as possible

It's really interesting how all the different tradeoffs of approaches just kinda appear when you take this inverted approach. It's all too easy to get caught up on the positives of an approach.

(opinion - I still think FP comes out looking better than OOP, but it does suggest that you need a lot of techniques to safely hide optimizations to make FP more performant, which can make it harder to scrutinize all the layers)

Could you please share more about what you have actually come up with?

If buuying OTM options is a consistently losing strategy, the opposite would be selling OTM options. And that's a reasonable way to make money.