jpaulson

Comments

question: the 40 hour work week vs Silicon Valley?

I think a more likely explanation is that people just like to complain. Why would people do things that everyone thought were a waste of time? (At my office, we have meetings and email too, but I usually think they are good ways to communicate with people and not a waste of time)

Also, you didn't answer my question. It sounds like your answer is that you are compelled to waste 20 hours of time every week?

question: the 40 hour work week vs Silicon Valley?

I don't understand. Are you saying you could get 2x as much work done in your 40 hour week, or that due to dependencies on other people you cannot possibly do more than 20 hours of productive work per week no matter how many hours you are in the office?

question: the 40 hour work week vs Silicon Valley?

False. At a company-wide level, Google makes an effort to encourage work-life balance.

Ultimately you need to produce a reasonable amount of output ("reasonable" as defined by your peers + manager). How it gets there doesn't really matter.

question: the 40 hour work week vs Silicon Valley?

Sort of. My opinion takes that objection into account.

But on the other hand, I don't have any data to quantitatively refute or support your point.

question: the 40 hour work week vs Silicon Valley?

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.

Applications of logical uncertainty

Why not start with a probability distribution over (the finite list of) objects of size at most N, and see what happens when N becomes large?

It really depends on what distribution you want to define though. I don't think there's an obvious "correct" answer.

Here is the Haskell typeclass for doing this, if it helps: https://hackage.haskell.org/package/QuickCheck-2.1.0.1/docs/Test-QuickCheck-Arbitrary.html

Power and difficulty

Unfortunately, it seems much easier to list particularly inefficient uses of time than particularly efficient uses of time :P I guess it all depends on your zero point.

A discussion of heroic responsibility

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.

Power and difficulty

I was using "power" in the sense of the OP (which is just: more time/skills/influence). Sorry the examples aren't as dramatic as you would like; unfortunately, I can't think of more dramatic examples.

Power and difficulty

I disagree.

1 and 2 are "negative": avoiding common failure modes.

3 and 4 are "positive": ways to get "more bang for your buck" than you "normally" would.

Load More