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.