From the fringes - how typical is a 8:45am - 4pm (3 days a week anyways) schedule for HN googlers?
I almost never work longer than that. (I honestly wish I could sometimes. I end up having to interrupt myself in the middle of things to leave on time, but such is life when you have kids.)
If he's also doing a bit of email in the evenings, leaving at 4:00 doesn't seem unreasonable. I've never seen or heard anyone fret about work hours at the office. My experience has been that the company is very results oriented.
(This is still hard for me to adjust to coming from EA where I worked a lot of hours and company culture, unintentionally or not, placed a lot of emphasis on how long you kept your seat warm.)
But why? You won't produce more, you won't earn more, you won't learn more?
If you're "in the groove" so to speak with coding, continuing work could be much more productive. At the times he wishes to work later, his additional work could be dozens of times better than a typical day. In contrast, coming back to code you were in the middle of a day later can have an hour of delays as you work just to get back to the state of understanding you had before.
In this way he will produce more. Producing more sometimes leads to earn more (that one's not as definite). Learning more... well, the more projects you complete the more you get to do; the more chances to learn.
This isn't to say that having a fixed end time is bad, just that your statement is false.
More time spent staring at a text editor (or even spent pounding on a keyboard) does not mean that you produce more. Maybe if your production metric is characters typed you produce more, but in terms of usable features there is going to be a point of negative returns on time spent.
I don't at all think my long term productivity increases if I work more than 40 hours a week, but I think it would increase if I could be more flexible (just +/- an hour or two a day) about when those 40 hours happen.
My role was also one that was pretty amenable to sprints of intensive working followed by periods of rest. I did a bunch of prototyping and working on high-profile, tight-deadline projects, and there was naturally a bunch of downtime in between them.
I've always wondered how google manages this process.
I talked about how my team at Google, specifically, handles this in https://news.ycombinator.com/item?id=8941915
We have more or less a rolling set of goals/projects and individuals who own those. As projects move from in progress to something we're willing to attach the word 'done' to, the folks working on them either pick up the next best thing on the list (that is, the next thing on the list for which they're the best suited person to own it) or they find another project where the owner is looking for some help and pitch in. Engineers are mostly expected to self-allocate based on what we understand to be really super important rather than simply really important.
The projects are sometimes defined internally ("Hey guys, wouldn't it be neat if...") and sometimes externally; rarely do they have hard ship dates associated with them[0]. Additionally, individual components have moderately well defined ownership, although this can shift over time as people's interests change (for example, I currently own the virtual NIC presented to GCE guests, so I tend to end up on networking projects).
My experience is that (for us) this works fairly well. From time to time someone puts on their manager hat (someone who actually has direct reports, that is) and asks people to shuffle around a bit. My experience with this workflow has been uniformly happier than my time (prior to Google) working with sprints, story points, and rigid deadlines that always slipped anyway.
Again, this is not necessarily indicative of how Google works in general, and your mileage may vary. Also, we're hiring :D
[0]: There are targets to help with prioritization and dependency tracking, though.
It's interesting to hear this - can you expand?
Is the frustration level a constant problem if reviews can take ... X longer than thought?
I'm an SRE, which means most of the code I write isn't directly user-facing, and thus isn't normally subject to hard external launch deadlines. That means I'm rarely rushing to push my changes through on a tight schedule. If there's a production emergency and I need to make an urgent change to avoid or mitigate an outage, there are escape hatches at our disposal to temporarily circumvent the code review system when no one is immediately available to do a review, but the need for that is pretty infrequent.
I rarely find it frustrating. On the contrary, I really appreciate Google's emphasis on code quality, even though it does come at the cost of some agility. I used to work at a company where the implementation of code reviews was generally resisted, and though we did get new code out the door faster, we ended up with some real maintenance nightmares as a result.
I've seen lots of self-+2s under the following circumstances:
1. You are the only engineer on your team, or all other engineers on your team are out for an extended period of time.
2. All other engineers have very different skillsets, and are not capable of doing effective review. Think Rails engineer attempting to review a touchpad firmware fix.
3. You have a hard deadline (e.g. product demo or factory build) and you're desperately trying to get as much working as you can. You may even be in a location where coordination is difficult and Internet access is poor.
For SWEs working on, say, web services, you probably have at least a medium-sized team (4+ engineers) and a week's slip is no big deal. But not all software is like that at Google.
Probably 2-3 days a week I put in an hour (or two, rarely 3) after the kids are in bed.
I don't always go in "that early" (normal people would slap me if i didn't put that in quotes), but i'm completely responsive on email/IM/etc by about 8:30.
The main difference from Matt is that when I drive (i bring my dog in, and it's not safe to bike with her on shoreline), if I don't get in before 9, IMHO, it's essentially not worth driving in until ~10am.
You'll just waste the time sitting on shoreline.
Biking, yeah, it's always 10 minute for me.
It's difficult to work with folks with 'unconventional' schedules if they are involved in cross-functional or managerial stuff. Fine if you're an individual contributor, but if you need to get a few folks in a room together frequently (project leads, etc) and their working hours have zero overlap, someone's going to get grumpy. I appreciate flexibility in schedule, don't get me wrong, but I also appreciate a bit of self-awareness :)
Matt, your schedule looks so much better than mine! :-)