Gaaagh, I hate painting! But it comes with the territory of home ownership, so I suppose I shouldn't complain. But I will anyway. It's not a matter of motor skills or patience. I can--and do--hand-sew, embroider, crochet and even tat. And if I say it myself, my penmanship has been the object of many, many compliments. But anything involving a brush is probably better left to someone else. Brushes, in my hands, are agents of frustration, if not pure evil. (Eeeeeevilllll, I tell you!) Contrast that with my husband, who painted many tiny figurines in his D&D heyday, but who writes in what he refers to as "Engineer block capitals."
The geek-centric point of the above navel-gazing is: If you can't expect a tool as simple as a brush or pen to be used identically by two different people, why would you ever expect programmers to all use the same programming tool merely for the sake of "consistency?" Let's face it, unless your code-base is joined at the proverbial hip with what I call "infrastructure" companies--and that's a whole 'nuther blog post--there's no valid reason, in my considerably-less-than-humble-opinion, why you shouldn't let your developers choose their own tools.
To illustrate: My language of choice is Java. Yet I have three Java Integrated Development Environments (IDEs) installed on my workstation: NetBeans (which, alas, will probably be smothered in its sleep after Oracle finishes its takeover of Sun), Eclipse and BlueJ. Each is better suited to different programming objectives. For instance, BlueJ is very minimalist--in other words, awesome for one-off utilities. But I'd never use it for any sustained development. In fact, its limitations were quite evident for the near-trivial programming I just handed in as my "semester project." On the flip side, more integrated environments such as NetBeans and Eclipse often require more extensive project setup. Merely correcting a mistyped project/package/class name can be an absolute nightmare. Not to mention that the so-called "intelligent" features can be more nuisance than help, and some have a tendency to create extraneous files under the proverbial hood.
That sort of variability in features is argument in itself for leaving the choice--within reason--to the individual developer. Significantly, not all your programmers are at the same level in their careers. Some prefer to be "spoon-fed"--if you will; others are quite comfortable in a minimalist environment.
That being said, there are a few caveats to go with this laissez-faire attitude. At some point, you will almost certainly need to integrate code written by different programmers. This could well come at a price. As noted, some IDEs introduce gratuitous files. Or--as odd as it sounds--you can trigger a civil war of sorts among (some) programmers by introducing the question of tabs-vs.-spaces for indentation. I wish I were making that up.
However, these are programmers we're talking about. Thus, you can quite fairly make the case that the flip-side of freedom of choice is the responsibility to check in source code that meets whatever standards of consistency and hygiene apply to your organization. (You know, that whole "with great power comes great responsibility" Spidermantra.) So they might have to write some custom file-copying and/or string-parsing code. Big deal. That's not something that should take all day. Even if it did, that time would very quickly pay for itself in terms of letting each developer work in her/his comfort zone. Everyone from the n00b who's still attached to the IDE s/he was required to use in school to the...ummmm..."old school" type who has vi key codes hardwired into her/his brain-stem.
Ultimately, it's always a matter of balancing consistency in the underlying--and trust me, inconsistency is not a trivial cost, over the life-span of a product--against the equally real cost of martinet management.
P.S.: Oh, and by the bye...Tabs rule, spaces drool! So there. Pppppplbbbbtttt!!! ;-)
