This past year, I have been thinking quite a bit about how "programmers" and "system administrators" are viewed in an organization (at least in my experience). Regardless of which group of professionals are more valued by an organization, they are nevertheless often viewed differently.Philip Kizer
, president of the League of Professional System Administrators
, noted that programmers may well be included in the umbrella of system administrators. Conversely, I believe system administration could be viewed as a specialized type of programming.
Programmers produce a system by writing code in one or more languages, which interact with users, operating systems and other applications through clearly defined protocols. (An example: coding an application that interacts with databases through API library calls, or code that interacts with a display and human interface through other API library calls, etc.)
System administrators produce systems by writing "code" to configure one or more component applications which interact with users, operating systems and other component applications, again through clearly defined protocols. (An example: configuring a service to authenticate users via SASL accessing an LDAP directory that stores user data in a database replicated across a network...etc., etc.)
If you abstract both of these roles away from the specific technologies involved, and agree to view configuration files and source code files as a similar expression of directives to the system, I believe the two roles will match at least 90%.
Thus, I propose that system administration _is_ programming, but the "languages" are just abstracted one level higher than what is commonly accepted as a "programming language".
It could be said that system administrators do not require the knowledge of algorithms or complex data structures that a programmer might routinely need. But I think that would be a misconception. A system administrator _could_ produce a system without some algorithmic knowledge or experience, but even dealing only with configuration files (many of which support abstract data structures), knowledge of data structures or algorithms vastly improves the flexibility and efficiency in producing a desired system.
Also, the basic cycle for either role to produce a system is also the same, approximating the following: collect requirements for, design, prototype, develop, test, deploy and support the system, optionally leading into the requirements for the next "version" of the system.
(In truth, you could widen the net much more than just this, as one example: electricians and electrical engineers working with banks of relays or other forms of "programmable logic controllers".)