Search results matching tags 't-sql tuesday' and 'lobsterpot'

Be the surgeon

rob_farley — Tue, 13 Mar 2012 00:13:00 GMT

It’s a phrase I use often, especially when teaching, and I wish I had realised the concept years earlier. (And of course, fits with this month’s T-SQL Tuesday topic, hosted by Argenis Fernandez)

When I’m sick enough to go to the doctor, I see a GP. I used to typically see the same guy, but he’s moved on now. However, when he has been able to roughly identify the area of the problem, I get referred to a specialist, sometimes a surgeon.

Being a surgeon requires a refined set of skills. It’s why they often don’t like to be called “Doctor”, and prefer the traditional “Mister” (the history is that the doctor used to make the diagnosis, and then hand the patient over to the person who didn’t have a doctorate, but rather was an expert cutter, typically from a background in butchering). But if you ask the surgeon about the pain you have in your leg sometimes, you’ll get told to ask your GP. It’s not that your surgeon isn’t interested – they just don’t know the answer.

IT is the same now.

That wasn’t something that I really understood when I got out of university. I knew there was a lot to know about IT – I’d just done an honours degree in it. But I also knew that I’d done well in just about all my subjects, and felt like I had a handle on everything. I got into developing, and still felt that having a good level of understanding about every aspect of IT was a good thing.

This got me through for the first six or seven years of my career.

But then I started to realise that I couldn’t compete.

I’d moved into management, and was spending my days running projects, rather than writing code. The kids were getting older. I’d had a bad back injury (ask anyone with chronic pain how it affects your ability to concentrate, retain information, etc). But most of all, IT was getting larger.

I knew kids without lives who knew more than I did. And I felt like I could easily identify people who were better than me in whatever area I could think of. Except writing queries (this was before I discovered technical communities, and people like Paul White and Dave Ballantyne). And so I figured I’d specialise.

I wish I’d done it years earlier.

Now, I can tell you plenty of people who are better than me at any area you can pick. But there are also more people who might consider listing me in some of their lists too. If I’d stayed the GP, I’d be stuck in management, and finding that there were better managers than me too.

If you’re reading this, SQL could well be your thing. But it might not be either. Your thing might not even be in IT. Find out, and then see if you can be a world-beater at it.

But it gets even better, because you can find other people to complement the things that you’re not so good at.

My company, LobsterPot Solutions, has six people in it at the moment. I’ve hand-picked those six people, along with the one who quit. The great thing about it is that I’ve been able to pick people who don’t necessarily specialise in the same way as me. I don’t write their T-SQL for them – generally they’re good enough at that themselves. But I’m on-hand if needed. Consider Roger Noble, for example. He’s doing stuff in HTML5 and jQuery that I could never dream of doing to create an amazing HTML5 version of PivotViewer. Or Ashley Sewell, a guy who does project management far better than I do. I could go on. My team is brilliant, and I love them to bits. We’re all surgeons, and when we work together, I like to think we’re pretty good!

@rob_farley

Slide-decks from recent Adelaide SQL Server UG meetings

rob_farley — Tue, 08 Feb 2011 02:31:15 GMT

The UK has been well represented this summer at the Adelaide SQL Server User Group, with presentations from Chris Testa-O’Neill (isn’t that the right link? Maybe try this one) and Martin Cairney. The slides are available here and here.

I thought I’d particularly mention Martin’s, and how it’s relevant to this month’s T-SQL Tuesday.

Martin spoke about Policy-Based Management and the Enterprise Policy Management Framework – something which is remarkably under-used, and yet which can really impact your ability to look after environments. If you have policies set up, then you can easily test each of your SQL instances to see if they are still satisfying a set of policies as defined.

Automation (the topic of this month’s T-SQL Tuesday) should mean that your life is made easier, thereby enabling to you to do more. It shouldn’t remove the human element, but should remove (most of) the human errors. People still need to manage the situation, and work out what needs to be done, etc. We haven’t reached a point where computers can replace people, but they are very good at replace the mundaneness and monotony of our jobs. They’ve made our lives more interesting (although many would rightly argue that they have also made our lives more complex) by letting us focus on the stuff that changes.

Martin named his talk Put Your Feet Up, which nicely expresses the fact that managing systems shouldn’t be about running around checking things all the time. It must be about having systems in place which tell you when things aren’t going well. It’s never quite as simple as being able to actually put your feet up, but certainly no system should require constant attention.

It’s definitely a policy we at LobsterPot adhere to, whether it’s an alert to let us know that an ETL package has run successfully, or a script that generates some code for a report.

If things can be automated, it reduces the chance of error, reduces the repetitive nature of work, and in general, keeps both consultants and clients much happier.

Why bother with database professionals?

rob_farley — Tue, 02 Nov 2010 05:49:32 GMT

Considering that I run a database consultancy, I should be fairly biased on this question, and suggest that you can't possibly cope without database professionals – except that I don’t really believe it all that much. I do believe it, and I’ll demonstrate why in this post – but the question of whether or not you actually get proper database people in or not isn’t quite as clear as you’d maybe think.

At university, I skipped the database subject – people said it was easy marks, but I was more interested in doing subjects that appealed to me, rather than ones that I thought would be boring and simple. I did Pure Maths subjects though, ones like Number Theory, Logic, and Set Theory. And in my Computing degree, I did interesting subjects like Machine Learning (using the LISP language), and Programming Paradigms (using Prolog and Haskell).

When I left university and got a job in a consultancy doing software development, I found that databases were a necessary part of just about every project we did. The language of choice for interfaces was VB3 back then (although on many projects it was PL/SQL too), but there was also a lot of database code needed, in either PL/SQL or T-SQL.

Databases just clicked with me, fitting in my Maths background better than I could have imagined, but with a combination of using different paradigms to fit the situation, basically being prepared to change hats into something that was List-focussed when using LISP, or Logic-focussed for Prolog, I found that I could quite easily fit into a Set-focussed paradigm for the data work. I also noticed that many of the people around me didn’t do this, and that their code generally paid the price for their lack of adaptability.

Later, when I managed to work out that it would be good to specialise, I chose SQL Server as the area that I wanted to specialise in, and have pushed further into the set-focussed paradigm. In the BI space, it applies even more. I enjoy MDX as a language, largely because I feel that it’s even closer to Set Theory than its T-SQL cousin. T-SQL seems remarkably forgiving for those people who don’t approach it with the right hat, whereas MDX seems to require the right approach.

And so I come back to the original question. I don’t know whether your organisation needs database professionals*, but I do know that your organisation needs people who can apply the right paradigm to their work, which means having a set-focussed paradigm for database work. If your non-database people fit this, and also possess the appropriate respect for data (and many other temperaments which are useful), then perhaps you already have people who will do.

*But if you would like to get some database professionals in, feel free to contact LobsterPot Solutions, of course. ;)