> if i walk in at 9.08am and you're going to moan at me for it, no thanks
I'm all for relaxed starting times, but at my current company that seems to have led to other, bad things: relaxed deadlines or other accountability.
It also sucks when something is broken at 8:00am and the guy that wrote that module (or made changes to it on Friday evening) isn't there for another hour.
It does suck, but it also sucks when the guy that broke it is an 8am starter and left at 4.30, when I discover his fault at 5pm and my last hour and a half is wasted. It works both ways.
Also 8am is unreasonably early :)
I prefer a nice leisurely start at around 10.
In our case, it's an app that's really only used from 8am-5am EST. If there's a problem at 4:00AM it's not a big deal. It's a different story when there are live customers.
Although, (ideally) any problem like that would be cost by a testing suite.
If you have developers making changes to production systems with live customers, the real problems at your company have little to do with when people show up for work.
I rarely roll in to work earlier than 10 am, and that is down from about 11 am at my last job since this one has a regular 10 am scrum meeting. Yet, I wouldn't consider leaving a broken build active on Friday evening, and I'm just talking about the tip build in source code control, not a broken production system. I wouldn't even consider working for a place where developers just pushed new code willy nilly to live production systems, because that's just stupid.
I'm all for relaxed starting times, but at my current company that seems to have led to other, bad things: relaxed deadlines or other accountability.
It also sucks when something is broken at 8:00am and the guy that wrote that module (or made changes to it on Friday evening) isn't there for another hour.