Headline: Minimize changes to the development environment unless you’ve got a really compelling reason to make changes.
The Problem
I have worked with many developers over the years and one thing that drives me crazy is changing defaults from what Visual Studio uses. I change machines and installs quite frequently (3 times in 2014) and don’t like to spend time making changes without a good reason.
The Solution
Minimize making changes. Have a very valid reason for making those changes.
Some Valid Examples
Line Numbers
I work with lots of developers remotely. And even if I’m in the same room it is so much more convenient say to others “On line 26 we seem to have a potential bug.” Particularly if you don’t have control over the cursor. So now everyone is on the same footing and can talk about the code efficiently. (To be perfectly honest, I have NO idea why having line numbers on isn’t the default.)
Spell Checking
I use a Spell Checker to check spelling of strings and comments. Since many times the code I work on needs documentation and I tend to use the code comments for the documentation, I’d like to make sure that things are spelled correctly.
Productivity Power Tools 2013
I like having only the using statements needed. I like having the documents properly formatted on save. I like having the tabs on the left when I use my wide monitors (which is 98{f073afa9b3cad59b43edffc8236236232bb532d50165f68f2787a3c583ed137f} of the time). The list goes one.
Other examples…
I’m thinking… But none come to mind 
Some Painful Examples
Virtual Space
What is virtual space?
It means that when you use the up/down arrows that it will remain at the same column even if the next line doesn’t go that far! I’m surprised that’s even an option. Word doesn’t do that. Notepad doesn’t do that. I can’t think of much of anything in today’s world that does that. My typing was SO thrown off when I got on another developers machine (I do lots of pair programming) and tried to use their keyboard.
Modifying Team Foundation Server (TFS)
Several times in the not to distant past I’ve been involved with TFS implementations. In two instances people wanted to modify the existing templates by adding approximately 100 (yes… didn’t double type that zero) custom fields. In both cases we were able to limit the changes to less than 10 fields.
I view using a template as an opportunity to pick up some best practices. But many like the idea you can customize and want to change TFS to work they way they’ve been working for the past several decades.
Modifying Team Build Numbers
It’s great to know that a build was the 3rd build on 9 Feb 2015. That’s unique. Now there are some reasons you might change your versioning of your files with the best reason being that you have libraries that need to follow Semantic Versioning so that things like NuGet can work properly when referencing dependencies. But for everyday use, why change the Team Build numbering to something else?
Summary
I could go on with examples, but I find it very frustrating to move from one developers machine to another and find HUGE differences in the way Visual Studio or Team Foundation Server (TFS) works.
Do your fellow developers a favor and minimize changing things from the default settings.
Leave a Reply