(scottish) sql bob blog


Some thoughts of your typical data shepherd / data plumber / data dance teacher sort of person.

A picture can be worth > 1000 words
It's been a interesting time in my new role which l have been in for about 12 months now.  The product l get to work with is fantastic in so many ways for the end user.  The way that is configured allows it to be changed and moulded to fit the users wishes (within reason).  The downside to this is that there is a lot of complexity. 

The team l work with has responsibility for migrating data from our clients existing system to our system.  Speaking for myself, this can be a bit of a Rubik's Cube puzzle of what bit of data goes where and how.  Which speaking as a data geek can be fun.  Its taken me a while to understand both the product and the data model that supports the product and l am still learning very day!

Whilst working on a migration for one client, the form in which we received the data was a set of a large number of spreadsheets.  The information was spread over several spreadsheets mapping the data had been done by my colleague.  During a regular telephone conference with the client, we released that the client was not completely clear on how the data was being mapped from the spreadsheets to the application.  The spreadsheet view was a in a form they as the client understood and trusted (think trusted blanket).   Where as the application was still new shiny complicated and cold.  So my colleague took some screenshots of the spreadsheets, and of the application of where the data was being mapped to.  Using Google Diagrams, they drew some lines showing where values on the spreadsheet was placed in the application.  This was then passed to the client to review.

During the next telephone conference, the client was delighted with this simple diagram.  What my colleague had done was to delight and reassure the client at the same time.  They received from both the client and our own team praise for we saw as a simple task.

As l write this post l am creating some diagrams for another client we are working with.  One their requests was for a data dictionary for the views we provide for reporting.   The data dictionary was to include primary and foreign keys including which tables the foreign keys referenced. I was tasked with this bit of work, which l duly delivered to the client, it when down well.  The client then asked could be do some Entity Relationship Diagrams, with the object names and foreign keys.

At first l did not think this was going to be of much benefit.  All the required information was in the data dictionary after all.  Once l had completed the first one l had to say that my mind was changed.  Even though l had a good grasp of the data model, mapping the data dictionary to the ERD diagram was not as easy and simple as l first thought.  Even worst than that first l was enjoying the process, secondly l was learning as l went along.  Another of our regular meetings came round again.  So l had completed a rough draft of two diagrams, so l presented them.

During the updates l presented the two diagrams, explaining that they where intended primarily for non-technical users who might be required to do some work on reporting.  Much to my surprise the client was delighted, and related that these would prove to be very useful to all users.

The take away for me is that even the simplest scruffiest diagram (back of a paper napkin) can communicate so much more than we might appreciate.  As adults we spend much of time, complicating verbally.  We should from time to time get the crayons out and just draw lines, circles, shapes.  It might be possible to explain in words something.  Yet l am reminded of the simple diagram of joins that has cemented firmly in my mind SQL joins (http://blog.codinghorror.com/a-visual-explanation-of-sql-joins/).  To this day, when l am thinking of a left or right join, that diagram pops into my head.  This says to me that what l need to remember its not how l communicate something, more that l communicate it in a way the client can readily (or instantly) understand.  Sometimes a picture is worth more than a thousand words.

Why go to SQL Bits?
On the face of it going to a conference looks expensive.  So why should you commit the time and effort to go?  That's a good question.  Do you know everything you need to know to do your job?

a) if not then going to SQLBits is the ideal opportunity to learn more, make yourself a better ( insert your job tile here ) assuming you want to be?

b) if you do then why are you not speaking at SQL Bits?  Knowledge matures, develops and then fruits as it is shared.

Stand on the shoulders of giants
At the conference there is a wide variety of subjects covered these range from technical deep dives, to the geekest technical humour you could ever ask for.  All the way over to advice on leadership, and managing your career .  You also get learn from other peoples hard won wisdom and experience, which has been won over thousands of person hours.   The speakers are delighted and eager to share their experience and save you the hours of effort it to gain the knowledge they have.  Writing this post after SQL Bits XXII l feel that l gained more practical knowledge in 4 days than l did in the previous 12 months.  That alone is what l call value for money. 

Continuing Professional Development 
Having worked with a number architects (they that design building) companies l have been made aware of the concept of Continuing Professional Development. In that any qualified architect is expected to learn and refine their skills for as long as they are a practising architect.

Another big part of the conference is the sponsors, they have stands set up in the main part of the conference.  Yes they are their to sell their products, on the other hand they are very generous and have many have prizes to give away.  Entering the competitions to win prizes can be as simple as giving your email address, others you might have to work for.  Such playing a racing car or sail boat simulator, these are geeks what do you expect !  Some of the sponsors have technical evangelists who are there to speak all of whom in my opinion are worth going to just for their sessions alone.   Next how often do you get to meet with representatives from Microsoft and ask them questions face to face.?

Fun and Games
There's even more fun to be had.  So far l have only attended two SQL Bit conferences.  The evening parties are well something to be experienced, the best way to put it is that these are dreamed up by geeks and attended by geeks.  Both of these groups of people know how to have a good time.  Also if you visit the sponsors you might just come away with tokens, for free drink, at the parties.  Need l say more?

The last question that occurs to me is why do l go?  Personally and ultimately l want to be the best possible person doing my job.  To provide my customers with the best possible service l can offer.  To achieve that will take time, energy, and sacrifices.  Part of that will be paying my way these conferences till l can convince my manager to pay for at least part of them.  Until then l will go to learn and develop, then one day return and speak myself to starting paying back my technical debt.