[EditEdit: The clever Mr. Atwood has written another Blog article. In it he hits the nail I was trying to keep upright - without the aid of opposing thumbs - on the head. I want to learn to code because I think it'll be fun.]
[Edit: I was pointed to this Coding Horror article by a friend. It's actually what prompted me to write this article. And has prompted me to get on with something I should have done 20 years ago, at least.]
But in the name of [insert deity of choice] William, WHY?
I’m a SysAdmin and my job is the smooth running of all the bits end users like to be in perfect shape 24/7. Big things, like file servers, eMail, web services and also all the myriad of little bits that keep them running smoothly like DNS, LDAP etc.
I want a greater understanding of how stuff works. I have a yen to learn. I feel that if I understand how software is written I’ll have a better understanding of how it works, or at least a better understanding of how the person who wrote it intended for it to work. Having a better understanding of how it works leads to a better understanding of how to look after it and pre-empt problems that might make a play for ruining my day.
Or so my theory goes.
Being a SysAdmin involves a lot more housekeeping and monitoring than you might imagine. So I often have a need for software that does: some of this, some of that and some of the other. And while there may be software that does this, software that does that and software that does the other it’s rare for one piece of software to do all of them. Everyone’s needs are different and guess what? that’s what spurs most development. Or maybe that should be most Open Source development, who knows what goes on in the minds of corporations?
And mentioning Open Source brings me to another reason I want to ‘learn to code’. I want to give back. Over the years I have been lucky enough to have been helped out by some of the most amazing people. People I’ve never met. People like Mike Bombich of Carbon Copy Cloner fame, Joel Rennich of afp548.com. People who’ve written software that’s insanely useful and answered questions and point you in the right direction and are happy to do so. There’s a part of me that says “I need a tool that does X, Y and Z. Surely someone else needs it too!” People have helped me and now I want to reciprocate.
Most of the time I’ll knock together a script that’ll parse a log for signs of impending doom, or a script that’ll check a configuration and re-jig things if need be. But there are 2 non-ideal things about using scripts; they can be slow and they can lack interaction.
Of course, I know this doesn’t hold true for every case, a well written script will be faster than a badly written one, and is a reason alone to learn ‘best practice’ when scripting. But it’ll still be slower, as a general rule, than compiled code. And scripts can certainly be interactive but it’s invariably quite a basic interaction. Enter this parameter, enter that parameter, enter another parameter, etc. The nature of the command line is quite regimented and linear and meaningful feedback can be difficult to implement and at worst utterly confusing and misleading.
GUIness is one of those things that’ll divide the people reading this article. Some would say that a command line tool, even if it’s just a script, is preferable to a GUI tool. And yes, there are instances – over an ssh connection, for instance – where this is absolutely true. But in day to day admin of a server, GUI tools give you a better overview of what you’re doing than the CLI. And this can be very important for a few reasons. Firstly, humans are visual animals. We take cues from how relationships in data are presented to us and process that data allowing us to more quickly assess and understand a situation. I wrote a bit about this in Pies, Ham Pies and Statistics. Following on from that, given a better understanding of a situation we can make better judgements and (hopefully) prevent ourselves doing something too stupid. The GUI tool can help us out here by disabling a button if we’ve given non-sane input for instance Something we can associate easily with squiffy input. With a command line tool we’d type in the input and only after we try to use that input will we be told it’s not legitimate, slowing us down and in a worst case requiring us to go back to step 1.
Here comes the rub. ‘Learning to code’ will take a month or 2 to pick up but years to get right. I’ve been working with computers professionally for 20 or so years and I know a lot about them. But this is 20 years of experience and stored up knowledge that’s seeped in through doing and doing and doing. As with everything new, starting to ‘learn to code’ will mean every bit of IT knowledge I have is now worth diddly-squat. I’ll have to work hard at it, do it every day and practice.
This is going to be no small undertaking, I’m going into the ‘learning to code’ thing very late in the game. Most programmers my age have been doing it for half their lives or longer. I’m under no illusions that I’m going to know it all in a month, a year or even 10 years. Though in 10 years I hope I’m at least passingly familiar with it.
I’ll keep you updated.
And I’m going to steer clear of Java if I an possibly help it!
Pingback: woodgie.net – FizzBuzz