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.