The Mendoza Line In Programming

For those who are unaware, there is a concept called "The Mendoza Line" in baseball.

Short description, there was a baseball player named Mario Mendoza, who (to put it frankly) wasn't a very good baseball player.  Now, making it to the major leagues is an accomplishment itself, and Mario Mendoza was able to scrape together a 9 year career mostly as a utility player.  He represented the minimum level one had to perform at to play and have a career in baseball.  Thus the term the "Mendoza Line" was coined.  If you fell below the line, you couldn't be a major league player.

I've wondered at times what is the "Mendoza Line" for a programmer?  I have a suggestion for the line.

Lets say there is some manual activity that will take you time X to complete. For this example, lets say there are similar typos in a lot config files.

If time X is really small, like a minute, we'll probably just do it manually.  This is perhaps the case when the typo is only in a small number (e.g. 1-2) of config files.

Lets consider if time X is a reasonable size and non-trivial.

If it would take you > time X to write a script to do the manual activity, you still might do it manually.  In my example above, perhaps the typo is in 5-8 config files.  Perhaps the config files and typos aren't similar enough to warrant figuring out the right regex.  So even if it's annoying, you still do it manually.

If you can develop a script faster than time X, obviously you should develop a script to do this manual activity.  Using my config file example, perhaps the typos are in over 500 config files.  Now finding the right regex is worth the time and energy so you don't have to do this task manually.

Now, we all have to do some manual activities in our day to day lives on a computer.  Some of these things are automatable (sp?), but we continue to do the manual activity b/c the effort to automate just isn't worth it (e.g. most don't script hitting the brew button on a coffee maker).

I like to think of this as the "Mendoza Line" for programming.  If you can recognize some manual activity is taking up some time X, can you recognize a script can do it faster, and write the script in less than time X.  If you can do this, you probably can have a career as a programmer.

Now I do want to say that the variable "X" does depend on a number of factors.  It can include job function, experience, and skill set.

I know very talented system administrators that can pump out very nifty sed/awk lines to do things in just a minute.  This makes sense.  There are probably many manual things that they have to do in their jobs so they have found it worthwhile to learn and commit to memory all the advanced parsing that sed/awk can do.  I personally have not b/c I don't do it enough in my day to day life.  So "X" for a task might be small for an advanced system administrator (lets say ~5 minutes) while it'll be larger for me (lets say ~15 minutes) for some setup/config activity.

Another variable to X is how often you might repeat it.  If you don't believe you'll ever have to do the manual activity again (b/c it's not your job and you're doing it as a favor to someone else) perhaps time X is viewed as small only because it's a one time activity.  But if your job function involves doing the activity many times, the potential cost is much larger.

There are perhaps other factors that affect "X", but hopefully the point is understood