SELECT asterix

It’s not what you say, it’s how you say it…

 

Roman history

When I was a slip of a lad, I spent waayyy to much time reading Goscinny and Uderzo’s Asterix books. I loved the idea of this little village in Normandy full of larger-than-life characters always getting one over on the Romans.

Of course, I read these in English (although they were written originally in French), but the translators did an excellent job of turning french idioms into relatable jokes.

So much did I admire this skill that I originally intended to be a Translator for the UN, but there just weren’t the right circumstances for that (like having a degree in French, for one). No matter, being a data nerd works for me, too.

What does this have to do with data ?

So, when looking at wierd-ass T/SQL, PowerShell, gnarly execution plans or whatever, it helps if you can visualise the intent of what’s in front of you and then apply your ‘local‘ knowledge to tune, improve and optimise – you know how the platform works.

It’s a skill that all DBAs should have – being able to look at code and feel what’s wrong. Developers (and some DBAs) call this ‘code smell’ – when something’s not quite right and there’s a challenge there to find out what.

Right, so you’re very clever. What next ?

It would be a very sad state of affairs if the DBA just made the changes and released the code to production – it’s happened in the past and is pretty much guaranteed to annoy the developers – and hope that the changes make it back into the source if anyone bothers to ask.

So, we use source control to start the conversation with the team. There are myriad ways of doing this, and I’ll leave the mechanics of that to you. It’s not why I’m writing this, and hopefully not why you’re reading it.

What happens next it the tricky part – the softer skills you need to be able to artiutlate atruicutate articulate your reasons and listen to the responses you get. Being able to have technical conversations at the appropriate level while making (or retaining) good relationships.

There’s something else – what are you not saying ?

OK, this is where I make the connection between Asterix, code, and relationships.

In today’s remote-working environments, we deal with any number of people from different backgrounds and cultures, all with their own back-story and ways of doing things. It’s rare for anyone to see eye-to-eye with someone else immediately (unless they’re also a DBA), so we need to change what has been written in code into something that is readily explainable and, more importantly, alter that message according to the audience. Exactly like the translators of Asterix took the original text and images, changed some of the words, localised the content and delivered it back with the original artwork – message substance unchanged, but more relatable.

When approaching a new project or technology, or talking concepts and architecture, I find it much easier to explain things with pictures (I’m loves me a whiteboard, I doos). There are universal signs for ‘database’ and ‘server’, but I once explained the concept of a data lake using a Fire Engine and a simple sewer system (you might want to talk to me offline about that one).

What ??!!??

I guess what I’m really saying here is that optimising code is hard, but talking about code and concepts is harder, and needs to be very carefully handled. If you’re talking about replicas in MongoDB to a Project Manager or Solution Architect, it’s probably best not to bang on about partitions, surrogate keys, and JSON too much – try to find a concept that’s relatable.

Again, what ??

Replicas in MongoDB is a bit like a supermarket chain. All the products that the supermarket chain sells are delivered to a distribution center, and then identical items are dispatched to each supermarket so that:

1. Each supermarket has exactly the same products on offer
2. Customers can go to the local supermarket to get any product they need that that the supermarket has in stock
3. New products are delivered to a central location and automatically distributed.

That’s probably over simplifying things for a technical audience, but hopefully you get the idea.

Executive Summary

A good DBA knows their platform well, and can achieve performance miracles on an almost daily basis

A great DBA can explain what concepts are important and start to embed ‘best practice’ by advocating for the platform to a wide variety of people with different levels or abilties ablitbe skills.

A superlative DBA can use images and language to take people with them to shape that best practice and sharpen those skills.

I hope one day to be superlative.

Thanks for reading.