|
|
|
|
|
|
by rdw
5055 days ago
|
|
|
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. |
|
|
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.