Welcome back to another edition of T-SQL Tuesday. This month’s edition is hosted by Mike Walsh, who asks authors to write two short notes to yourself – one in the past, and one from the future.

A Note to My Past Self…

Or otherwise titled, learn from what I wish I knew then and know now.

Understand Business Value

And how to communicate it. This is the lesson that I wish I knew then, that I know now. As a technologist, especially my younger self, I never cared about the business side of things. I went to school for a computer science degree – not a business degree. Business folks are good at what they do, and I wanted to do what I wanted to do, which was play in tech.

But as we all know, oftentimes in our career, to play with tech, we need buy in from the business. There’s a lot of things we must justify and understand the why’s behind it.

• Want to fix some code? Translate that to how it impacts the business.
• Want to attend a conference or training? Understand how increased knowledge and skill will bring value to your business

Along those lines, I also wish I knew and understood the value of writing a business plan. Or at least a business justification document. And there are several principles of communication that I wish I understood better… like focusing on solutions that drive to desired outcomes. Former me would have brushed off those terms as business-speak jargon, but nowadays I firmly believe in this mindset.

That’s it for now. Mike may have asked for a message to my future self, but instead Sebastian the dog is demanding his evening walk. 🙂

Until next time – thanks for reading!

Welcome back to another edition of T-SQL Tuesday. This month’s topic is an inspirational one, hosted by John Sterrett. John would like us to blog about what we can do to help grow the data community.

Growing new speakers is a topic that I have done a lot with already, so I won’t beat that drum. Instead, what I will suggest is something that anyone can do:

TL;DR – Recognize, Ask, & Offer

Step 1: Recognize Talent and Potential in Others

If you’re reading this, you’re part of the data community. You may not speak or blog regularly, but nonetheless, you are a participant. As such, you can watch for and recognize others. Maybe you’re reading an interesting thread on the SQL Server sub-Reddit… maybe you’re watching a conversation on the SQL Slack channel… Look for statements by individuals that pique your interest.

Step 2: Ask or Invite Them to Contribute

You’ve noticed someone talking about something really interesting? Ask them to share more of what they know about that topic. Invite them to write something more in-depth about it. Being asked and invited to share more, is validation for that other individual. And I believe that each one of us should always be looking for opportunities to validate others and raise each other up.

Step 3: Offer to Help

Anyone can help anyone else.

Stop – re-read that first statement again.

You can help.

There’s a mental trap that many of us fall into (I used to be one of those), where we believe that we are not in a position to help, because we do not believe we are an expert. You do not have to be an expert to help. You can help, simply by encouraging someone get their ideas out there and become more involved in the data community. Words of encouragement… or saying thank you for something you found useful… these are all ways to help.

One More Twist

This blog has been written, from the angle of asking you, the reader, to recognize potential in someone else, encouraging you to ask them to contribute, and offering your own help to further grow them.

Are YOU, whoever is reading this right now, the one who has that potential?

Look in the mirror… the answer is yes. You can be a part of the next generation… and there are many out there who will help you. Don’t know where to find someone? Ask… ask me… you’re reading my blog right now… contact me.

Welcome to another edition of T-SQL Tuesday! This month’s host is Deborah Melkin, who asks bloggers to share some thoughts around mentoring.

My Experiences with Mentoring

Over the course of my career, I’ve had the wonderful opportunity to mentor others in addition to having a mentor. It has been a fantastic experience almost each and every time too.

I value mentorship because I believe that it benefits both parties: the mentor and mentee. Some of those shared benefits result from the sharing of experiences and perspectives. For example, a mentee may bring a question to a mentor, that presents a situation from a new angle that the mentor may not have ever considered before. In general, it is an amazing experience for both parties involved and a wonderful opportunity for mutual growth, not just growth of the mentee seeing mentorship.

So Why Don’t I Do This More Often?

As I think back, I’ve mentored others far more often than I’ve been mentored myself. One might think this is rather peculiar, given how I professed the benefits of being mentored just a few moments ago.

“Andy, why haven’t you sought out a mentor more regularly? Is it because you have a difficult find finding a mentor (a commonly voiced challenge)?”

Because I hate setting goals.

For me, I don’t have a difficult time thinking of someone who I would like to have as a mentor. And I am perfectly okay ASKING to be mentored (as that is another common challenge voiced by others). My biggest obstacle is if that person says yes, then what?

One of the generally accepted best practices for a successful mentoring relationship is to try and think of some goals of what you’d like to get out of the mentoring relationship. It helps to create alignment for both parties, so they know what the time is being spent for. And that’s something I’m terrible at.

Unpopular Opinion…

In my opinion, a mentoring relationship CAN work just fine without a specifically set goal. But what’s the point then Andy?

The point is that your mentor is your trusted advisor, to help you work through whatever challenges life may throw at you that week. And just life work life for most of us, our priorities and challenges change frequently.

While I’ve framed this as an unpopular opinion, I will also fully admit that I still need to ask, but just set the expectation up front. It’s no different than say, “hey, can you help me for a few hours to develop this presentation” vs “hey, can you help me just get a better handle on my career?” And the person being asked to mentor MAY be okay with a less focused mentoring relationship. What I’m guilty of, is assuming that they would not be since it is counter to the typical best practice.

Moral of the Story… is?

Simply ask anyway. But do be clear on what your expectations are, even if you do not have any specific goals in mind. Heck, the kick-off for the mentoring relationship could be a brainstorming conversation around goals!

(I should take my own advice sometimes… )

Thanks for reading – happy T-SQL Tuesday!

Welcome back to another edition of T-SQL Tuesday! This month’s blog party is hosted by Rob Farley who is asking bloggers to share some thoughts around a single word: Integrity.

To the Dictionary!

Like many words in the English language, Integrity has several meanings. I decided to look at a handful of dictionaries and am settling on this one from the Cambridge English Dictionary which states:

the quality of being whole and complete

In the realm of data, what does it mean for data to be “whole” and “complete?” Well, if I’m storing a simple value like “$14,693.31” or “fourteen thousand and six hundred and ninety three dollars and thirty one cents”… I would be rather upset if the value that wound up being stored was “693.31” or $1 ,6 3 .31″. That data is neither whole nor complete, thus the integrity of my data is compromised!

Garbage In, Garbage Out

I cannot tell you how many times I’ve encountered scenarios where “this data looks wrong.” Well… can one ensure that it is being retrieved and displayed correctly from the storage media that it resides on in the first place? Are you viewing/validating the data in question correctly? Whatever client/method you are using to review your data – that is suspect and its integrity is in question.

Assuming the answer is yes, well, did the data somehow get changed while it was “at rest” on its media? This is highly, highly unlikely – stable media like flash or even spinning disk, very rarely flip bits when the media is idle. But in extremely rare cases, okay, your storage media has lost its ability to maintain your data integrity.

But more often than not, questionable data was written to your media in an incorrect fashion. That is where the saying, “garbage in, garbage out” is definitely applicable. So, what application is writing your data?

“Oh no Andy, it’s not the application – it must be the storage that’s corrupt!”

“If the storage were corrupt, we’d be seeing random garbage data all over the place. Not just these and only these specific dollar values. So that’s HIGHLY unlikely here.”

“It’s got to be the storage is corrupt, check again.” (hours pass)… “… okay, we found a bug in our code.”

Step by Step

What’s the moral of this simplistic story here? As you determine the source of an integrity issue, you must carefully walk the stack and assess at each point in the stack, where your integrity was compromised.

But Andy, shouldn’t your database have already had other things in place like constraints, foreign keys, etc. to also ensure that all data written down maintains its integrity? Absolutely… but that’s another story for another day (that I hope another T-SQL Tuesday’s blogger tackled too).

Thanks for reading.

Welcome back to another edition of T-SQL Tuesday! This month’s edition is hosted by my good friend Tim Mitchell (b). In this month’s edition, Tim asks participants to share “What’s in your data detective toolkit?“

The All Powerful…

… Question. That is what I now believe is the most important tool for a Data Detective.

Asking Questions Effectively

This nuance involves HOW you ask a question. Some of this involves knowing your audience. Is this the right place or the right time? Sometimes there comes a point where asking questions is just counter-productive because your audience has no interest in answering. And it also means you need to make sure you’re asking the correct audience in the first place.

Asking Effective Questions

This nuance involves structuring an individual question to get the answer that you are after. There are times you just want a Yes or No – so say that as part of your question. There are other times you want more details… sometimes you best state that up front too.

Framing

Another critical aspect to asking questions effectively and asking effective questions, is to properly frame the entire interaction. State WHY you are asking what you are asking. If it is a higher-stress situation, doing this effectively can help others understand that you’re trying to work towards a common goal of solving a problem.

Active Listening

Finally, the most important thing to all of this is learning how to ACTIVELY LISTEN. Too often, people will only hear one or two tidbits then immediately start thinking about what they want to ask or say or do next, rather than continuing to listen to the respondent. If you are talking just as much or MORE than the respondent, you’re not questioning or listening effectively.

Stop Jumping to Conclusions

One thing I’ve see all too regularly, is that someone will present a problem or a challenge, and people will immediately try to start to answer or address the challenge. But more often than not, not enough information is ever given initially. Why are you seeking to do this? What have you tried thus far? What is your desired outcome? What problem are you trying to solve for here?

It’s not good enough to just ask questions. Questions can sometimes put people on the defensive. Why are you putting me on trial? One must also learn how to ask questions effectively and learn how to ask effective questions. Yes, these are two distinct but critical nuances.

A Recent Example…

I enjoy spending time on Reddit and also enjoy answering questions on the r/SQLServer subreddit. Recently, someone asked about a data load that was “overwhelming the resources” and “slowing the API down to a level that’s unacceptable in production.” Most of the immediate respondents jumped in, assuming this was an on-prem SQL Server and trying to solve the challenge using only the initial information given.

Instead, I saw the necessity to dig deeper. The original poster (OP) then shared that this was an Azure SQL Database. Okay, that changes some of the rules here… so I dug deeper.

And eventually the OP stated that it was a Azure SQL DB on a single vCore, General Purpose tier! FULL STOP! I/O characteristics and potential is tied directly to the number of vCores one has allocated to an Azure SQL DB and well, one vCore is basically the lowest one can go. Might be fine for development, but how can one expect to run a Production application on a single vCore?!

So while other respondents gave great advice on how to tune a data load, none of it would do any good until OP actually increases the number of vCores of their Azure SQL DB!

Conclusion

If you’re reading this, you’re most likely already an inquisitive and curious type. As such, I hope this blog will encourage you to dig deeper and hone your skills around asking effective questions and asking questions effectively.

Thanks for reading!

Welcome to another edition of T-SQL Tuesday! This month’s blog party is hosted by Kevin Feasel (b). Kevin also happens to be the maintainer of Curated SQL, which is an excellent resource to keep up on current trends! Anyway, in this month’s edition, Kevin has asked us to write about our favorite job interview question(s).

You Know Everything… Right?

In my personal opinion, a strong candidate for just about any position, isn’t one who happens to be a walking encyclopedia with a photographic memory. In fact, I really do NOT want a “know-it-all,” even one who truly DOES “know-it-all.” K.I.A.’s (a rather unfortunate acronym yes, but I’m feeling lazy so will keep using it) are oftentimes arrogant, lack empathy, and generally difficult to work with. They bring a library of knowledge to the table, and they know it… and unfortunately act accordingly. This has just been my unfortunate experience with K.I.A.’s, and there’s absolutely exceptions out there… and if you DO find one of those exceptions, well, make that exception!

Seek… and You Will Find Answers…

Anyway, I’d far rather find someone who is resourceful, especially when faced with something they do not know. So I will often ask questions that will test that resourcefulness. I’ll ask for stories or anecdotes, when a person got thrown into something and had to “figure it out.” What did they do? Where did they look for information? Did they turn to others? If so, who? I might also vary it, by asking hypotheticals. If you had to learn technology X tomorrow, where would you start? How would you go about it? What would be your learning process? And even better, have you had to do something like this recently?

Reading Between the Lines

The nice thing about questions like the above, is that one can also read between the lines and learn other things about a candidate. Are they excited when they answer? Do they have personal stories to draw upon or are they just giving generic answers like “I’d find a book.” Does being thrown into something unknown make them uncomfortable or excited? You may be able to glean what type of learner they are as well; some folks prefer to read, some prefer to dive in and get hands on first.

TL;DR – What Is Your Favorite Interview Question Andy???

One whose answer contains multiple insights. One where I can learn something about a person by their verbal answer, but also learn more deeply about them by their non-verbal answers.

Thanks for reading!