I suspect if you took a look at your life, there are a lot of things you don't understand.

I would probably be able to get the same amount of work done in a 30 or even 20 hour week, given the amount of time wasted on meetings/email/waiting for data in an average office. Boss wouldn't want to pay me the same for a 20hr work week though.

It was my understanding that Google provides free food for its employees partly because people who get company dinner are also expected to work past dinner hours. Is this false?

I think you can get more done by working longer hours...up to a point, and for limited amounts of time. Loss in productivity still means the total work output is going up. I think the break-even point is 60h / week.

Does that figure take into account that the bug rate that you produce at 60h/week is going to be higher than at 40h/week?

I work at Google, and I work ~40 hours a week. And that includes breakfast and lunch every day. As far as I can tell, this is typical (for Google).

I think you can get more done by working longer hours...up to a point, and for limited amounts of time. Loss in productivity still means the total work output is going up. I think the break-even point is 60h / week.

So, for statements like "the billionth digit of pi is even", it's provable from your beliefs. But you're still uncertain of it. So, the problem is, what's its probability? Well, 1/2, probably, but from what principled theory can you derive that?

I don't mean to butt in, but for God's sakes, can somebody please tell me what keywords to search in order to find Solomonoff or Kolmogorov-type work for putting a probability measure on countably infinite sets of structured objects? Is this just a matter of defining the correct \sigma-algebra, with countable additivity of subsets? The actual problem here is very simple: it's just a matter of taking the definition of an inductive type and putting a sensible probability measure over the resulting objects.

The problem is that you can't just assign equal probability mass to each constructor (with parameterized constructors "containing" each possible tuple of parameters as an event inside their portion of the probability mass), as this results in believing (at least, as a prior) that 50% of all linked lists are empty.

I had that problem too (from the commentary here, this lack of specific examples is the post's biggest issue) -- whatever examples I could come up with seemed distinctly unspectacular.

However, I think avoiding common failure modes -- being less wrong -- is a decent way to increase the expected value of your power.

I think for most things, it's important to have a specific person in charge, and have that person be responsible for the success of the thing as a whole. Having someone in charge makes sure there's a coherent vision in one person, makes a specific person accountable, and helps make sure nothing falls through the cracks because it was "someone else's job". When you're in charge, everything is your job.

If no one else has taken charge, stepping up yourself can be a good idea. In my software job, I often feel this way when no one is really championing a particular feature or bug. If I want to get it done, I have to own it and push it through myself. This usually works well.

But I don't think taking heroic responsibility for something someone else already owns is a good idea. Let them own it. Even if they aren't winning all the time, or even if they sometimes do things you disagree with (obviously, consistent failure is a problem).

Nor do I think dropping everything to fix the system as a whole is necessarily a good idea (but it might be, if you have specific reforms in mind). Other people are already trying to fix the system; it's not clear that you'll do better than them. It might be better to keep nursing, and look for smaller ways to improve things locally that no one is working on yet.

A list of useful things to do, or a list of effective ways to do something are not ways to get "power for cheap".

Avoiding minor failure modes does not get you power. Getting a little bit more bang for your buck is still not "power for cheap".

None of your examples look like they provide power for cheap.