Micromanagers of Programmers

To me, the scariest thing as a technical worker would be having a micromanager to be my manager.   Here is the problem.  In programming, there are many ways to do the same thing.   If someone expects me to exactly follow their commands on simple mundane tasks such as how to list a directory or how to read a file, life would be extremely dreadful.

The most obnoxious type of micromanagers are those who are also self-important and self-righteous.   So to push the absurdity to its extreme.  Consider when you need to list the content of a particular directory.  How many ways can you do it?

ls -al?
ls -U?
ls -1?
find . -name "*"?
find . -name *?

Most of the time, if you just want the file name, doing one way or the others are completely fine.  You might waste couple of keystrokes to get the extracted results.  In real-life, I would always choose the right and the shortest one in a particular situation. 

Micromanager would insist that his way is the best and insist that everyone should just use his version.  For argument sake, let's say ls -1. Consider the dilemma of a programmer : should he follow the manager literally?  If he did, he would likely find that the said method might not even give him the right information.    If he didn't, he would be insubordinate to the manager.

It's good to bear this in mind.   Programming is always a creative business.  Have you seen how a oil painter work?   Until the last stroke, you should never judge a picture because it was still not finished by the painter.   And there are many ways to paint!   Would that be annoying to interrupt the process by saying, "The Picture doesn't look good! Stop it! Do it my way!"

Similarly, as a manager, you may want to fully understand what the programmers tried to do before dismantle someone's thought.    Remember, it's very unlikely you know every single command in the planet.   For example, if you are good at perl, you might not know why people use awk.  If you are good at awk and sed, then you might not be good at perl one-liner.  

These are supposed to be learning opportunities.  But if you goal is just to control, you will lose these valuable experiences.  Also you kill the creativity and productivity of another programmer.