"I am not sure that more serious* companies...I mean with actual paying customers and such."

Cheezburger has been a profitable business since inception. We have been profitable every single quarter, and never had a quarter with negative cash flows. Our revenues and profits are in the millions.

Very, very few startups can make that claim.

We operate three different lines of business: we sell advertising, we sell merchandise (at http://lolmart.com) and we publish printed materials such as books and greeting cards (http://amzn.to/buztLM).

I assure you that having fun and LOL is a serious business.

Scott

Oh come on now, how could you have negative cash flow? Your whole business model is based around publishing content on the web you didn't create, (and 99% of the time probably don't even own the rights to), this is not exactly an expensive business to run.

My point is: I'm not sure why Cheezburger thinks it's impressive to set up Wordpress blogs of other people's images without breaking the bank.

These guys have a GREAT growth curve and healthy margins- rare in the content world. Heck, look at Reddit. Great company, soaring page views, barely profitable.

I'm sure you're similarly unimpressed with Yelp? Threadless? Digg? Reddit?

You mean like Twitter? Facebook? Youtube?

There's nothing inherently different between a website and "real" software that makes being agile (which this is really about) more possible on websites.

Now, to the point at hand. Having a new hire show up on the first day, get their work station setup, and complete a round trip of checking out code, fixing something real, and getting it back into the repository is a very real milestone. You might take it as being flippant or process-ignorant, but by getting that new-hire through that hurdle on day one can be seen as a major accomplishment. It may not be right for some businesses, but if you instead got your new hires to submit a change for review rather than for integration into a production build you'd achieve the same effect.

Wow.

I can't believe how angry something this utterly nonsensical makes me, but at least I know it's being done by other companies, not by mine.

Overall, it strikes me as a nice idea; I know I would appreciate having a first day like this.

For someone with pretty grandios claims about Microsoft it seems like you definitely didn't double check your statements. One of the most helpful things that anyone did for me when I started at Microsoft was when my office mate helped me get setup on the network, pull the source code, find the target area, and "check-in" (not a real check-in, the MS final check-in process is complex) a trivial patch with a full recompile.

The actual quality of their check-in shouldn't be terribly important, as what they're checking in is usually something very simple.

Doing it all in a single day is aggressive, but doable. I suppose you'd find holes in the new-hire documentation pretty quickly.

It's wonderful that their codebases can be enhanced by adding another case to a switch-statement, but that's far from what you'll encounter with complex projects. It works for web 2.0 PHP/Rails stuff. It doesn't translate to much else.

[EDIT: My tone struck me as a bit too condescending, sorry about that. Still: Rushing new developers into their first commit doesn't work for many projects!]

In the past I have worked at or consulted for places where doing so was a black art that could easily occupy a week or more of a new hire's time. Most small companies had a single "expert" and the rest of the developers would copy code, libraries, and settings from one machine to another in cargo-cult fashion.

I don't think that's true. Even complex projects have some simple bugs. The example given was making the software produce a nicer error message if the output was out of bounds; you can do that kind of work for almost any program. It's not like they assigned a random bug...