Most systems administrators are quick, perhaps too quick, to tell you “I’m not a coder.”  Oddly, this admission normally comes after boasting about how many programming languages they know or have used.  Why is this?  Can this be changed?  Here is my 5 step plan on how any SA can become an honest to goodness programmer.

Step 1: Find a problem you care about solving, for yourself

SysAdmin’s don’t actually use tools, they study them. The point isn’t to solve a problem but rather to know how to solve a problem if the need ever arises. SA’s are filling their tool chests full of handy hints and useful solutions for nearly any problem that can be encountered. Whats more, this is a subconscious tendency…. they want to use things, but because their true goal is simply learning and knowing the tool, when they wish to build something with this thing they’ve just learned, they blank out. Learning is the goal, goal achieved, next tool.

This causes any SA approaching programming languages to become masters of hello_world in a dozen languages. Again, the goal is to have a basic understanding of the language and then to move on.

The only way to break out of this rut is to find a problem you actually yourself have, and solving it. Don’t write a program for someone else, write it for yourself. Write something that integrates with your LDAP servers or pulls metrics and stores them in a database… whatever it is, make it practical, not an abstract academic exercise.

Step 2: Pick a language and stick with it

Because they are masters of adaptation and have so much hello_world foo, they are likely switch languages before making any real progress. If you want to write in C, then do that, but don’t switch to Ruby or Python because writing regex in C is a PITA…. push through and learn how to do regex in C.

SysAdmin’s also need to know what everyone else knows…. or more. This is a point of pride, master of all trades. Just because Go is on the rise, don’t think that PHP or Python is obsolete and useless. If you want to use Go, then fine, but stick with it. If you want to use Clojure, fine, but don’t just feel lame because suddenly people are talking about Node.js.

To facilitate this, write lots and lots of small programs that exercise different parts of the language and let you build a deeper knowledge of the core language. Save all those in a source control repository for later review and to help you build your confidence.

Step 3: Scripting isn’t programming

SysAdmin’s are tool masters… they know as many of them as possible. This is why scripting is a natural thing for us, it allows us to plug different tools together. But this isn’t really programming, its plumbing. This becomes more apparent when you start programming in a non-shell language. A sysadmin’s code tends to have a lot of execs… that is, essentially writing shell scripts in a non-shell language.

Step 4: Modules and libraries aren’t cheating

SysAdmin’s are purists and have a lot of ego. Using a module or library is akin to cheating. This is why many SysAdmin’s only know basic C, they don’t have the drive to implement their own protocol implementations, but view using a library as cheating…. so they are masters of pointers and little more. Many programmers look at modules and libraries like SA’s look at programs themselves, as building blocks to be plugged together to achieve a goal.

Don’t exec a tool, use a module or library, and don’t feel weird about doing it.

Step 5: Don’t think about other people

One of the biggest impediments to coding is embarrassment. That your code isn’t good enough or its formatted wrong or your not doing things in a certain “normal” way. This is the equivalent of going to the first day of school and being made to feel like an outcast for not having the right clothes or shoes… you like it and it works for you, but some how you’re wrong and just not cool enough to fit in. For anyone this is discouraging, but for a SysAdmin who’s pride is in being a master of all things its unbearable and causes them to throw in the “I’m not a coder” towel.

The solution is to just not give a shit. If your lines of code exceed 80 characters, so what. If you use curly braces instead of “end”, fine. Just don’t listen to those people. What matters is functional programs, not pretty syntax. If you truly pick a language and stick with it, at some point you’ll fall into common practice fairly naturally, but until then don’t allow yourself to give up just because you constantly feel like some imaginary critic is yelling at you while you code. This is why its important to, first and foremost, write for yourself to solve problems that you yourself have.