Chris Done has an article on Emacs that is getting some attention over at Hacker News. And I’m partly just (as I always am) annoyed by the self-congratulatory tone of Done’s article, but it also commits a fallacy that’s important:
That phenomenon is not a problem for Emacs. Work environments are a very personal thing. They exist to serve only one person: you. Me-me-me is a winning attitude when dealing with your environment. Maybe in the real world, out there, where you have to share programs with other people, where other people will see or even use your efforts, you have to care or take consideration about other people. Not in your environment. Not in your Emacs. It is your virtual home for at least nine hours of the day, every day.
No, that’s not true. Because other people need to be able to use your work environment.
This was really driven home to me working at Pivotal Labs (I was working at Pivotal, not for Pivotal, I note). They don’t have individual workstations. Everyone pairs all the time, and the workstations are designed to stand alone and to have people rotate off of and onto them. So they’re all set up with the same IDEs, the same tools, the same everything.
And as a result, when you stand in front of a computer, you can make it work. Whereas when I stand in front of a workstation at my current job, I probably can’t. I certainly can’t fluently and swiftly run the specs for a given module with a key-press. Someone else may be able to (though probably not), but I can’t.
This is important! Even if you aren’t formally pairing, it turns out that an essential part of software development is saying, “I don’t know how to do this. Teach me?” And if you’ve ever tried to dictate code to someone, you know how impossible it is to teach the person without actually typing at their workstation. When I do that at my current job, I’m often presented with an editor that uses arcane commands I know little about (like vim), or even a keyboard I can’t use (because it’s Dvorak or some arcane ergonomic thing without keys in the right places).
The other advantage of a standardized work environment is that you can make people use some advanced features. For example, I can run a test in an instant with a key-press. Most of my colleagues switch windows and then type a command-line. Possibly a rather difficult command-line. This is crazy, and counter-productive, but since they don’t use my environment, I don’t know how to teach them to use a quick test-running shortcut.
These advantages vastly outweigh the potential for someone to develop just their absolute perfect development environment in Emacs. The difference between an absolutely perfect development environment and a pretty good one are fairly negligible. The differences between a pretty good development environment that someone can give you useful help on, and a quite bad development environment that only you can use, are quite large.