I think this is probably a problem more with new developers vs seasoned developers. I've noticed that configurations woes plague people who haven't got to a point where they have already configured their environments to their liking tens of times. i can get a machine configured for development use in a few hours and be productive the next day. Why? Because I have a repo of all my latest dotfiles including my vim plugins and configs. I also have a list of software I need to download the moment I use a new machine in my 1Password notes. Lastly I have another note with all the stuff I usually change in OSX and Linux. I've even been thinking lately about make it even more streamlined by having scripts actually do all my work.
To get up to speed with my developing environment, I just need to sync a couple of dropbox folders on my dev machine, checkout my repos, or bring a usb (if not allowed to dropbox sync my stuff, in which case I'd really consider getting a job where I'm not limited by stupid policies that make little sense for developers) with my latest configs. Lastly I might spend a day configuring the companies environment architecture (svn I'm looking at you), but even in the worst situations this things are generally trivial.
For a developer, his machine should be free to configure to his liking as long as security constraints are taken into account. If the developer can't be up and running with his environment in a few days, he's either not experienced enough or the IT department utterly sucks. Generally, it's the first option.
If you're an experienced developer, but the project you join requires a different toolset and/or set of executables than a previous one, then it'll take you a good while to get up to speed on it.
E.g. you've got Visual Studio the way you like it, but the new project has different code organization and code conventions and requires a different version of C++. You were developing for Android on Juno and now you're using GWT on Indigo. The libraries aren't checked in, and also Bob built them himself because he wanted to patch the logging library. The build system depends on ActiveState Python 2.5, it breaks in subtle ways if you use another distribution or version, but no one can tell you because they just all happen to have installed their copy when that was the latest.
[Remembered another one: we're using a library, but it's broken, and the workaround involves setting up absolute paths to a number of files in your user directory, and no one has a complete set of the necessary because we're all working on a different subset than you.]
A repo with dotfiles ain't gonna help you with any of that. I suspect that these scenarios describe the vast majority of development environments by quantity. It's a luxury to have your build environment be describable by a few text files whose location are known rather than bundled up in binaries, Windows Registry entries, and cargo-culted tribal knowledge. Yes, that's a horrible state of affairs, but to point the finger at "new developers" is to miss the point.
I agree that sometimes a new job might bring into light a toolset you;ve never used. I've never taken more than a day or two to get everything up to speed though. Interestingly enough, after being a unix guy for more than 10 years, my latest job required me to use visual studio. My first commit was three days after I started. This days I even have a file with all my VS configuration.
You also gave a perfect example of the only case I explicitly said you shouldn't point the finger to "new developers", which is when IT - or even the senior developers - are at fault for having a crappy development environment.
To get up to speed with my developing environment, I just need to sync a couple of dropbox folders on my dev machine, checkout my repos, or bring a usb (if not allowed to dropbox sync my stuff, in which case I'd really consider getting a job where I'm not limited by stupid policies that make little sense for developers) with my latest configs. Lastly I might spend a day configuring the companies environment architecture (svn I'm looking at you), but even in the worst situations this things are generally trivial.
For a developer, his machine should be free to configure to his liking as long as security constraints are taken into account. If the developer can't be up and running with his environment in a few days, he's either not experienced enough or the IT department utterly sucks. Generally, it's the first option.