I’ve been operating computers for the last 25 years of my life and I’ve done a bit of everything in that time, using computers to make a living for the last 17 years. I’ve been a systems administrator full-time. I’ve being a technical journalist, writing about modern PC technologies and 3D graphics. Most of all though, for fun and profit, I’ve been a programmer.
Programming for a living, for utility or for fun, I’ve connected people to the Internet, written desktop application software and sold it for big money, built web applications and tried my hand at many different programming languages to further my craft.
The most liberating thing it’s allowed me to do is ask computers questions about things. Questions about themselves and the data they hold. Questions about how they’re connected to other computers and the Internet. The questions are always followed by answers. The answers are what give you power.
Systems administration concerns itself with data more than anything else. Think about it. Users. Files. Permissions. Access controls. Configuration. Settings. There’s generally a lot of it, too. Hundreds or thousands (or hundreds of thousands!) of users with millions of files with myriad permissions and access controls in programs with countless configuration and potential settings.
That means there’s inherent (and usually unending) repetition built into everything. Repetition kills efficiency. Think about manually having to visit every seat in your company to perform a certain task. Programming is about avoiding repetition and making using computers more efficient. Programming is what enables you to stay seated and avoid that physical trek to every machine to do that tedious piece of config you can’t do remotely.
You might get lucky and have the software you use be able to ask all the questions you need about your systems. But I bet that frequently you find that you either have to make the software jump through hoops to give you the answers, or the answers are completely elusive.
Need to find all the inactive accounts in your Active Directory? Need to email everyone with connection to a certain printer to tell them it’s being serviced? What about inviting everyone with a high incidence of getting their password wrong to a workshop about good password policies?
Chances are you don’t have anything to hand that can easily help you with the last couple of things. What about if your infrastructure is modern and you have a nice virtualised setup running on top of VMware. What about automatically increasing resource pool allocation for hot-running VMs on a bunch of ESX servers, or finding out how much disk space you’re losing over time to datastore growth?
That kind of data-rich reporting and monitoring activity, where you need to do the same thing across a bunch of systems, usually over time, repeated periodically, is where knowing how to ask the questions yourself becomes incredibly powerful.
You stop needing to buy expensive reporting packages or trust one-off scripts you found online not to do bad things on your systems. You stop having to repeatedly click through terrible GUIs and wonder whether you remembered to check a certain tick box five levels of cascading property sheets deep inside the management console.
You write a program yourself, likely saving money, reducing your reliance on Google and random scripts and tools, usually getting it done faster and automating it for you so you save time in the future. A program doesn’t forget, or miss anything out in a large set of data.
The best part is that learning to engineer that kind of simple, time-saving, incredibly efficient, very useful software doesn’t take much. You can accomplish much of it without even to learn more than a scripting language. Scripting languages tend to have easy-to-use hooks into your OS, are simpler and easier to learn and wield effectively than more heavyweight languages, and are quicker to start executing on a system since they don’t have to be built.
You just write and go.
So the next time you catch yourself repeating a tedious task you wish you could automate away, or find yourself wishing for some software to do a new thing entirely, as a sysadmin I bet you already have most of the mental skills to learn how to write software to do it yourself. I bet you caught yourself wishing about 5 minutes before reading this, and the reason you stopped off to read Tom’s excellent blog is because you needed help doing something you could mostly automate with code.
The benefits are clear for your current employer, and your future employment elsewhere too. It can only open doors in your career, give you much greater power and flexibility over your systems and save you so much time in the long run.
The post [Guest spot] – Why Sysadmins Should Learn to Write Computer Programs appeared first on The Sysadmins.