This isn't really an absurd level. They're talking about minor bug fixes or simple error catches that no one has gotten to yet. They're not asking new hires to design and implement an entire new feature on a full bladder.

You are right.

My (Extremely badly put :() point was, why does it matter so much to make new hires productive as a race to zero countdown? If a employee going to work at an average for 2 years, to me, it feels OK to give them sometime to get accustomed to new environment.

I'd say it simply reflects the work environment. It's a lot more fun to go home after your first day at work and have something to show for it. You, after 8 hours of working at Company X, have already created or improved something for them.

I'd say it's a lot more fun than going home thinking "Damn that was a lot of paperwork. I hope I can get a computer tomorrow and start to work.."

I just took it to mean "we train our new hires on day one on how to commit into our version control system". Nothing more.

I mean, c'mon, it's not rocket science these days to get a devbox up and running and talking to a svn or git server.

I think the whole point is that being extreme about it turns it into forcing function to make sure that the dev setup process is extremely fast and easy. As soon as you start relaxing the timeline (to, say, pushing code in the first week) the urgency to keep the process fast disappears.