First off, you have long evolved from "amateur" status, so please: STOP IT! ;-)

And, to make it official once and forever:

~lights candles, dims lights, you know the routine~
Invoking hereby my powers invested in me by Brian Kernighan and his inborn son Denis Ritchie, as a loyal follower of the cult of David Korn and ordained disciple of Doug McIllroy i declare you officially to be of the status expert!

~waves wand of content (usb-stick) and scroll of knowledge (man page) at wisecracker~
Mumbo-Jumbo, Abracadabra, Kyrie Eleison, philosophus mansisses, <some more unintelligible latin here>

Well, this ritual returned RC=0, which means you are now an regular expert. Go forth and dost thou program in BASIC no more.


OK, after this litle exertion, i have to admit i don't fit into these categories either.

I like to script most of my work as an admin: not because of the development process itself but because this way i can assure that a certain work process is always done the same way and with a certified outcome. The key to administrating large environments is to industrialise and standardise as much as you can. Even if such a process turns out to be systematically faulty it will be done faulty in the same way on every system so it is (relatively) easy to create another script to correct that systematically.

Systems administration, on the other hand, is much more than to work on systems. It includes careful and long-term as well as short-term planning of the environment you work on. This means having a firm grasp of technological advances to expect, it means knowing the trends of usage patterns on your environment, it means taking into account maintenance- and life-cycles and so on and so on. Planning is everything and in systems administration it is even more important then some other areas.

At the same time there is troubleshooting: a systems administrator works as the "glue" between the hardware and the OS on one side and the application(-engineers) on the other. You need intimate knowledge of the systems interior (in more than one regard: from hardware to system calls to APIs, etc.) to be of help in this endeavour when not everything is working the way it is expected to do (which is more often than not the case) and you are the one to make it run no matter what.

Every admin('s knowledge) is a trade-off between fulfilling these widely divergent areas of competence (you can't excel at everything so you will specialise in one area cutting back on the other). But one needs to have at least a certain minimum amount of knowledge in any of these areas to be of any help in an admin team.

bakunin