What programmer things should every sysadmin know?

Solution 1:

• Version Control. Be able to generate, read and apply patches. Know how to use a version control system that presents repository wide versions and why you want one. Know how to write descriptive changelogs and why you want them. Know how to search a repository's logs for keywords and time frames.
• Scripting. Do something once and be on your way. Do it twice or more, do it once then write a script.
• Debugging. Know how to read a stack trace and how to report relevant errors to your software support contact. Finding the error is nice and helpful, but knowing how to fix it can take a lot of investment in reading the code. Do the part that's easy for you, and let them do the part that's easy for them.
• Testing. Monitor continuously and log errors. Used in conjunction with version control and testing, you have a strong idea of what may have gone wrong when and what changed around then. Monitor both production and preproduction.
• Peer Review. Propose and review changes to production systems. Test on preproduction, determine exactly what needs to be done and record what services may be affected for how long. Don't let Change Management degrade into political battles of bureaucratic power.
• Study Cryptography. A modern system administrator is in charge of network resources; adding security as a final step is somewhere between impossible and a very expensive proposition. Understanding public key cryptography, password handling practices, and encryption in general will be extremely valuable.

Solution 2:

I'd start with:

1. How to write more than the most basic scripts no matter the language. Automation is your friend.
2. How to run a debugger/know how to read crash reports of some kind: it makes figuring out a crash report and who to ask what the deuce to much easier.
3. Version Control - not just for code but for anything worth keeping a history or change control over.

Solution 3:

System administration is just programming. A configuration management system lets you see your entire infrastructure as a distributed machine. As a sysadmin, your job is to program this machine.

Know one text editor. Usually vi for sysadmins, emacs for programmers.

Know how to script. Pick a scripting language. Perl is a perennial favourite, as is the shell/sed/awk combo. Ruby and Python can work, but for a lot of things objects are the wrong paradigm.

Know how to write readable documentation.

Version control. Crucial for maintaining configuration files and audit trails.

Learn to think in programming terms. Understand procedural, object oriented and functional programming paradigms. These may never be used, but knowing them makes you infinitely more productive.

Learn to use a debugger (or more) and logging.

Learn to use a RDBMS. There are plenty of data processing requirements which can be simplified by using a RDBMS correctly. Even being able to switch to a DBA role on demand can do wonders.

Test before deployment. See the test-driven development philosophy.

Pair programming is good. Have someone else watch over your shoulder to learn/advise/correct.

Learn to at least have a passing familiarity with a bunch of languages. Learn a new language every year.

Solution 4:

• Know how to program. Yes, that's important: as one commenter said, if you do it more than once, then write a script - and write it well.
• Know the tools included in a standard operating system installation. For UNIX administrators, this means tools like Korn Shell (ksh) and Perl and vi. Don't rely on Emacs or Ruby or Tcl or C shell being present.
• Know the network. How are Ethernet packets put together? What does a packet look like? What are the differing packet types? Get to know tools like tcpdump, wireshark, snoop, and others.
• Write portable code. If the code is going to run under Linux - and Tru64 - and Solaris - and OpenVMS - then write portable code. Even if it will run under two versions of UNIX only - make it portable. But then, if it doesn't need to be portable, don't spend extra time on it.
• Know where the documentation is. For Perl, this means perldoc, Perl Mongers, perl.org, etc. For ksh, this means the man page and your favorite Korn shell books.
• Document, document, document, document! Document your code, create man pages, create inline Perl documentation, and whatever else is appropriate. Explain how to use the program and why you coded it that way.
• Know your system's packaging tools. Know how to create RPMs for Red Hat, or HP-UX depots, or Solaris packages: this will allow you to build packages for your systems, and thus to integrate them into the installation process.