leyton.org

A curious coincidence perhaps, but I’ve been asked “What is it you do for a living?” at least three times in the last few months, mainly by family members. It’s therefore struck me I perhaps need to make a stab at trying to explain what I do as - until now - I’d sort of assumed people had at least something of an understanding. However, IT jobs suffer from being relatively new to the world. Job titles such as Accountant, Nurse, Lecturer, Postman are all well-understood, and many formal definitions of my job title are laden with techno-speak, which defeats the purpose.

So, here’s an attempt at explaining what I do for a living. I make no apology to the many technology-types - many of whom are likely to be my friends - who read this and think “What? Don’t be silly” when reading something I may have simplified: There are of course many subtleties that need to be put aside when simplifying. I’d perhaps suggest you have a stab at explaining what you do (perhaps below, in a comment?) in similar terms: To a relative or friend who wants to understand what you do for a living. It’s harder than you think!

Firstly, my job title. The short answer is either “Systems administrator” or “DBA”. The long answer gets a bit more complicated: Technically, these days I’m the director of my own company, and as I’ve spent the last three years provide consultation. So if I want to impress, I can bandy about “Director”, as that’s reasonably easy to understand. “Consultant” has lost a lot of the cachet associated with it in years gone by - it now seems to stand for “expensive contractor who simply doesn’t seem to understand the detail of our organisation”.

But that’s a digression: For anybody who works in IT, a “Systems administrator” (the main job description I use) is, essentially, the fix-it guy. As most of my friends work within IT, or are very familiar with it, we are to our other IT colleagues (Programmers, managers, support staff and so on) the guy they turn to when things need to be done.

This means we’re responsible for setting up the computers people use, ensuring all of the technical services the company needs are available, and the software works properly. If it stops working properly, we fix it.

But, and I want to make this very clear, this doesn’t mean I can (or want to) fix your home computer! There is a very big distinction between the sorts of computers I look after on a daily basis, and the ones that you probably have sat on your desk as you read this. This is where the complexity and confusion probably creeps in. I look after “servers” - generally much larger computers that on the whole don’t run anything made by Microsoft.

Here’s where another complexity often creeps in. Most people seem to think that every computer runs Windows. Perhaps, given their experience, that’s a valid inference to draw. However, it’s not the case: The computers I look after run a variation of what’s called Unix: The vast majority of computers that make the internet work are running such (called ‘Linux’ or ‘Solaris’, if you’re curious). Unix is perceived as a much more complex operating system, but that belies much of the technical simplicity underlying it. That’s not to say it’s not complicated, but once somebody has learnt how to work on a Unix computer, they rarely forget the experience, for good and bad reasons!

Just a side-note: If I do actually look after home computers, I generally suggest Apple Mac’s, because they both run a variety of Unix that I use on a regular basis at work, but also because I find them inherently more reliable, stable, dependable and predictable. I find the Microsoft Windows approach, both from a technical and a user perspective, unnecessarily complex and unreliable. Home computers “should just work”: Apple Macs do that, and last for a long time. Microsoft home computers just don’t in my experience.

But I digress once more. Essentially, I manage those computers, those Unix servers - the ones you connect to when you visit a website looking for something; the ones that you rely on when you send an e-mail; the ones that you blame when you can’t save a documents.

A subtlety is that all IT jobs are not the same. Frances and I do very different jobs (she’s a programmer) that require an entirely different set of skills and experiences. That’s not to say Frances couldn’t do my job if she had to, or vice versa (I used to be a programmer in fact), it’s just both jobs rely on previous experience, neither of which we have in particularly large quantities in the others field. A programmer creates applications to solve the business problem at hand. She deals in abstract, but relevant business or technology issues, and creates solutions to that. When she has written her application she will often turn to the systems administrator to install the software so that it can then run on a daily basis to do what it was designed to.

We tried to search for an analogy to try and explain the difference between a programmer and a systems administrator. I came up with the notion of cooking: Frances, as the programmer, makes the cake. She combines the ingredients, and puts them in a large cake tin in the right quantities and the right mix of ingredients. Once she has made the cake, she hands it to me: Before she even made the cake, I’d installed an oven, wired it up, checked it worked and got it ready. Together we discuss the settings on the oven for the cake in question and put the cake in, hoping that the end result is a good cake that satisfies the customer.

That’s not to say that we System Administrators and Programmers work together in some technology utopia, smiling at each other. We often have quite conflicting goals and targets. My role, as a Sysadmin, is to setup a system that can cope with what’s thrown at it, and run reliably. The programmer develops software that needs to run, but may not be aware of the implications of their approach on a ‘real’ server. Similarly, they may not be the ones called up at 3am when it stops working. From another perspective, a system administrator may not be grasping the complexities of the problem at hand, and be a troublesome obstacle to delivering a vital business requirement. The system administrator sometimes has to take what is delivered, or demanded, and install it against their better judgement. Quite frequently, the developer simply knows more than the system administrator (as many of the good developers do), and is puzzled by the reasons for delay. All of this can, and often does, lead to friction between two groups of people. Whilst we both need the other, there is often a lot of disagreement between programmers and system administrators!

My personal approach at solving this is to try and involve myself at an earlier stage in the process, ie. talk to the developers and ensure they appreciate the issues and concerns I and my colleagues might have, and to better understand their challenges and approaches. Often, especially with more experienced developers, this dialogue is fruitful and often quite stimulating: We both learn from the other. A shared understanding of a problem and the demands can result in a better solution, drawing on the knowledge of both. Sadly, I find many developers and - more frequently - system administrators are unwilling to have any sort of discourse with programmers, resulting in ill feeling and, more often than not, a poor solution to the businesses requirements.

My other job title is “DBA”, which stands for Database Administrator. Much like a systems administrator, a DBA is a gatekeeper to something, in this particular case a database. In a business context, the database is some master repository for a particular business application. Depending on how the IT department structures itself, this can either be a role for the System Administrator, or a separate role altogether (many Sysadmins don’t know database technology in detail). Where it’s a separate role, it can be quite technical: Looking after a complex piece of software; or more business oriented: looking after the way the data is organised and structured. I’ve done both of these roles, and find them uniquely challenging and interesting.

As with a system administrator and programmers, DBA’s often have to work with developers and support staff. Again there are sources of friction and disagreement over how data is accessed, and again I prefer an earlier dialogue to strident refusal to engage in discussion. I’ve experienced both, and find the latter, whilst it has merits in a larger business context, frequently undermines a collaborative atmosphere where better, more practical, solutions may present themselves.

Anyway, that’s my attempt at explaining what I do to non-technology friends and family. I know it’s digressed a little, talking a bit about some of the subtleties between what Frances (a programmer) and I (a system administrator) do and don’t do, but hopefully it’s given at least an outline. If there’s one thing that’s particularly useful, it’s the cake making analogy: It’s quite a good one. But I’d suggest you don’t ask me to bake a cake: Despite my interest in cookery, I’m not particularly good at baking!