Today we have a guest editorial from Phil Factor. 

I’d been beating my head against the keyboard, metaphorically, trying to get a PowerShell SMO script to function properly. If I remember right, it was to get a file of all the insert statements to fill the data of all the tables of a database. Then it hit me, it wasn’t important, and I’d probably never use it.  Then I got back to the task of getting it to work.

Why do we, as DBAs and database developers have such a stubborn attitude to recalcitrant jobs? It goes beyond logic, but most of my colleagues do it as much as I do.  I, like them, will stay with a job until I’ve got it working; sometimes well into the small hours. Why?

If something doesn’t work, or I’ve underestimated the complexity of a job, I feel compelled to know why. I hate not understanding a technology or technique enough to use it. It becomes a struggle against a machine which will result in only one winner, and I’d loathe the winner to be the machine. It is that instinct for mastery that will keep a DBA’s nose in books-on-line, searching for that detail that will unlock the secret to fixing a problem with a database, or making a routine work properly.

Do I care if the actual task that defeats me isn’t obviously important? No, because these little details can turn out to be a solution to a lot of other problems.  Ones usefulness to an organisation is not just based on knowledge, but on ability, through long practice, in working out how to solve problems, no matter what they are. Our skills may be forged from the heat of knowledge, but they are sharpened through frustrating, and often wearisome, struggles with the technology.  Ah, but the surge of contentment when suddenly you work out what is wrong, and suddenly things go right.  Yes, there are rewards as well.