In my current workplace there is a disturbing trend where management seeks to standardize everything that it can. This includes standardizing the tools which we are allowed to use, even to the extent of telling us which IDE we must use. The reasons given are twofold: Firstly they believe that homogenizing the workplace enables them to better compare the productivity of different programming teams. Secondly, they hope to modernize the work habits of some of us older developers. Elements of management, who haven’t worked outside of Microsoft Office products in some time, and who have never really undertaken a study of how various development environments might affect the productivity of various developers, nevertheless are convinced that there exists a “best” development editor, that they know what that editor is, and seek to force us all to use it.
It’s easy to find examples where this homogenization appears to be a good idea. We have in our team some individuals who have, shall we say stagnated in their skill set. They use editors most people would find inefficient. They have work habits which are fairly inefficient — lots of repetition. They have stopped looking for better ways of doing things. This is reflected in the quality and nature of their code, the usability of the products they generate, as well as in their habits for interacting with said code. They see no problem with byzantine usage restrictions, complex and lengthy code. They don’t strive for simplicity or elegance.
Management (and unfortunately at least one other coder) hope to correct this problem by forcing us all to use Eclipse. At first glance this seems like a good idea — it will stir the pot up a little bit, get people out of their comfort zone. Unfortunately, their goal is not to get people to learn new things, nor to get people out of their comfort zones a little, their goal is to standardize everything. In my mind, based on my observations, standardization and control in corporate development environments is a root cause of developer stagnation. To keep coders current, skillful, and engaged means encouraging coders to pull themselves out of their comfort zones. To experiment. To be playful in their work. This is how people will constantly learn.
Of course, my primary concern is my desire not to lose my productivity. I spent a few months working with Eclipse while I was loaned out to another team to help with a Java project. Had my term with them been much longer, I would have gone to the effort to set up EMACS to work within their development environment. Why? Well, primarily find EMACS vastly more efficient for day to day development than Eclipse. Eclipse has a lot of fancy features that can save 5 or 10 minutes, but they get used every few weeks or so. EMACS has tiny optimizations that save me anywhere from a half a second to a handful of seconds, but they are used dozens or sometimes hundreds of times a day. They are intrinsic to the design and assumptions of EMACS and emacs mode in Eclipse is not an effective substitute. A second reason is mouse abuse. While I think the mouse is a very effective input device, it is abused heavily, particularly in the windows world. This kills my productivity in a number of ways. It distracts me, in that I have to navigate GUI elements when I want to be thinking about design or implementation. It gives me incredibly painful repetitive-stress injuries (yes, i’ve tried a trackball, that’s worse). Finally it forces me to remove my hands from the keyboards costing me a couple of seconds distraction and irritation while I try to find home row again.
I mention all this in an attempt to convince the reader that this is not a religious issue for me. I keep an open mind. I try using new editors and IDE’s from time to time. I think 3 months is sufficient time to evaluate my own productivity with a particular editor. I’m the kind of person who takes time and energy to learn how to use his tools effectively. And that right there is my problem with both the design of IDE’s and the general standardization approach followed by most corporations: rather than striving for excellence, they tend to enforce mediocrity. For individuals who are not touch typists, who aren’t willing to learn efficient keyboard commands and the effcient use of atomic macros, Eclipse is certainly better than EMACS. For individuals who don’t like to invest time and energy training themselves in the effective use of tools, Eclipse is also advantageous. But for guys like me who strive for excellence, who take joy in proficiency, Eclipse is a lead weight around our neck, and a little bell ringing in our ears at random intervals centered around a mean of about 1 minute. It disturbs both our productivity and the joy we take in our work.
More to the point, I understand that Emacs is the most efficient tool for me to use. I play guitar and find the chording in Emacs fairly natural. The same for the rapid opening and closing of windows within the main emacs frame. I enjoy playing around in LISP, and extending the editor. I like the way the Emacs community thinks and goes about solving problems. I find it very hard to live without Emacs macro features. I like using grep and sed, and version control from the command line. I hate having to use the mouse, indeed using the mouse can be cripplingly painful for me. I find all the GUI elements most IDE’s offer to be hopelessly distracting — BUT I realize that other people are different, and they should have the freedom to use, choose, and develop tools that suit their needs and idiosyncrasies.
In the end, standardizing our toolset removes yet one more choice. It’s one more area where we are told “don’t think for yourselves, just follow orders”. This is contrary to what programmers should be doing: obsessively thinking about what they are doing and whether or not it’s the best they could be doing.
Share on Facebook