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.
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.
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.
Hiring a new person and finding that literally nobody could get them set up to develop in a reasonable time frame led directly to cleaning those issues up.
Does it take two weeks to deploy a build to a production machine or the integration test farm? No. Then why would it take two weeks to pushh the code to a dev machine?
When I was younger and stupider, I accepted a 'limping' dev box for months at a particular new job, because everything was undocumented and I was afraid to ask for help.
If your new dev process isn't some close variation of:
1) Install IDE 2) Checkout code from repo 3) Run dev environment setup script 4) Open project in IDE
then you're doing it wrong.
A few things I do at my company to make sure:
* give developers a new machine every 12-18 mos (depends on Apple refresh cycles). Forces everyone to install it fresh, and fix any dependency/install bugs to be fixed
* all new dev hires must have it running and have deployed a change on their first day.
* encourage graphic designers, QA, and other folk to get it running locally for testing and the like. The install script and docs must be super clear so it allows them to install it with minimal hassle
I was using Vagrant for this, but ultimately it didn't provide enough value to outweigh the overhead and hassle. A shame, but I think they are on the right track with their approach. Just needs a lot more polish in my opinion.
Definitely this. But I object to the "bad developers" part. More often than not, this is a result of the environment and not of the developer himself.
In fact I'd guess most devs would be willing to sacrifice environment choice for editor choice if it came to that.
There's these new things called "remote X11 displays" that might revolutionize the way we work on remote servers from local computers. If only it ran in a browser[1], though!
[1] http://lifehacker.com/287085/control-tightvnc-from-the-web
http://misko.hevery.com/2009/06/12/what-pair-programing-is-n...
An additional benefit is that the experienced and more senior developer will also have to endure the pain of setting up, and the undocumented parts, and may even fix them.
However, if I was looking for a technical fix, I think using Vagrant is far better than anything cloudy. The cloud is a tradeoff - you get the benefits of virtualization, if you accept the downsides of it being all remote. The OP's solution doesn't even allow you to choose your editor! Vagrant gives you all the upside and none of the downside.
The last company I worked for had this problem initially. There were multiple layers of software that needed to be built and configured just so. If there was a problem with your build, it would take an hour to get and build everything from scratch if things went without a hitch. They often didn't.
This changed once we started using a build server and automated builds. This made a complete build script necessary. The benefit was that script could be used to both spin up a new dev environment (except for installing IDE and local database servers), and syncing the dev machine. Every morning I would run this script and let it chug along while I went to my standup and/or read my morning email.
I think an automatic configuration script combined with the pair programming idea, even if the programmers are paired for a day, would greatly speed up the new dev up the learning curve and allow them to be productive faster.
It's more about getting up to speed the system I'm developing on and I have difficulty seeing how that can be properly abstracted out into a general solution.
Oh and of course the obligatory "You can have my emacs running evil-mode when you pry it from my cold dead hands".
