Learning Through Blogging and Speaking

This post is a response to this month’s T-SQL Tuesday prompt created by Mala Mahadevan. T-SQL Tuesday was created by Adam Machanic and is a way for SQL users to share ideas about interesting topics. This month’s topic is Setting Learning Goals for 2018.


Prefer watching instead of reading?  Watch my T-SQL Tuesday #97 response on YouTube.

What do I want to learn in 2018?

Next year I’m going to strive to learn more about tasks usually reserved for a DBA – backups, replication, user and role permissions, etc…

As a developer, I am generally isolated from the day-to-day work of a DBA.  Not that I necessarily want to be responsible for a system’s backups (and restorations!), but I do feel that I am missing out on a broader understanding of SQL Server by never having to perform these tasks myself.

I like being able to do-all-of-the-things, or at least know how to do them, because I think it makes me a better developer and a better architect of solutions.  By not having an expert knowledge of things like availability groups, I feel like it hurts me when it comes time to architect solutions.

The learning process

I like to learn by doing.  Since I’m not planning on becoming a DBA anytime soon, I’ll need to create my own scenarios to learn how these different DBA specific features of SQL Server work.

This won’t give me real-world experience, but for the most part I am ok with that – I’m trying to learn more details on the broader concepts rather than the nitty gritty of various real-world scenarios.

The best way I’ve found to learn by doing in this academic sense is through blogging.  I like blogging because it forces me to learn a concept well enough to be able to articulate it back easily to my readers (hi mom!).

Blogging forces you to create demos that point out features that are critical to understanding a demo.  If I can create a demo that recreates a real-world scenario, then my understanding of that problem in the real-world will be pretty good; at least way better than if I just read a book or MSDN article.

Implementation

Blogging is all good and fun, but the best way I’ve found to really understand a topic is to present it.  If you can teach someone else then you have a pretty good handle on the content.

Now, I’m not aspiring to give a 500-level talk about disaster-recovery planning, but I do think I can learn enough to present some 100-level topics to SQL Server beginners who are just a few books online articles behind me.

The best part about presenting is that you will have people smarter than you in the room with you.  Or at least people who have a different perspective about the topic than you.  These people will generally ask really good questions that…you don’t know the answer to!

But there’s no shame in saying you don’t know the answer.  It’s actually a wonderful opportunity – after the presentation, you can take your time and learn the solution.  Then blog about it so others can know the answer too.  Then incorporate into your future presentations.  It’s a beautiful cycle.

Thanks for reading. You might also enjoy following me on Twitter.

My Most Embarrassing SQL Moment

T-SQL Tuesday #92: Lessons Learned the Hard Way

This post is a response to this month’s T-SQL Tuesday prompt. T-SQL Tuesday was created by Adam Machanic and is a way for SQL users to share ideas about interesting topics. This month’s topic is Lessons Learned the Hard Way.


“Is this your query that’s killing the server?”

It was my first week on the job and I was learning to query one of our major databases.

Up until that point, my SQL experience was limited to working on a *tiny* e-commerce database. Query performance was never something I had to deal with because any query I wrote, no matter how poorly written, would always execute quickly.

This new database I was working on though had tables with a billion+ rows. I should have been more conscious about how I was writing my joins and filtering my records, but I wasn’t. I wrote my query and executed it in SQL Server Management Studio.

About 20 minutes into my query’s execution, I received an email from my new DBA, and it looked something like this:

Uhh, there might be a problem here

“Is this your query that’s killing the server?”

Oops.

I don’t think my mouse ever moved to the stop execution button as quickly as it did that moment.

I was incredibly embarrassed to have brought our production server to a crawl. I was also incredibly embarrassed to have had my first interaction with my new DBA be about a query that created major problems for him.

Although there were no long-term damages from my server-crushing query, it was a scenario that I definitely didn’t want to relive again in the future.

Next time: don’t do that again

Obviously, this was an experience where I learned that maybe I shouldn’t write queries against unfamiliar data in production.

  • I should have been practicing on a dev database.
  • I should have looked at table meta data and made sure I understood relationships between tables better.
  • I should have done some more preliminary querying with more restrictive filters to be able to catch performance problems earlier on with smaller result sets.
  • I should have examined what indexes were available and made sure I was attempting to use them.
  • I should have used a (NOLOCK) if I absolutely had to test on the production data so that at the very least I wouldn’t prevent the high transaction ETLs from modifying data in that database.

All of those “should haves” quickly became my checklist for what to do before running any query in an unfamiliar environment.

I’ve still written plenty of ugly and inefficient queries since then, however none of them ever caused me to bring the SQL server to a halt like I did in my first week. That was one lesson that I learned the hard way.

Thanks for reading. You might also enjoy following me on Twitter.

Will Technology Eliminate Your Tech Job?

This post is a response to this month’s T-SQL Tuesday prompt. T-SQL Tuesday was created by Adam Machanic and is a way for SQL users to share ideas about interesting topics. This month’s topic is The Times They Are A-Changing.


I think everyone’s had the same fear at some point in their career: “Am I going to lose my job because of X?” X can be a variety of things — company reorganizations, positions being outsourced, robotic automation, new software advancements, etc…

I think the answer to this question depends 100% on the type of individual you are and nothing to do with what your job actually is (was).

Being a Linchpin

Seth Godin discusses the concept of a Linchpin in his same-titled book. A Linchpin is someone who is so good at what they do that they become indispensable to their organization. Linchpins are the kind of people who are self-motivated and are able to consistently deliver quality work. They are integral to the operation of a business, even if they don’t get all of the glamour of having VP or Director in their title.

And why are Linchpins always guaranteed jobs? In one scenario, Linchpins will outgrow their role and be promoted or find a better job. They are always learning and growing in addition to delivering, and so this is the natural procession. In the alternate scenario, if the Linchpin has to lose his or her current job (ie. think company buyouts where entire departments close), they will either 1) become promoted to elsewhere in the company because management recognizes their great skills or 2) they will have no problem finding work elsewhere, especially with great recommendations from their former employer.

The Cloud, SaaS, PaaS, and other technologies

The past few years have seen many new technologies come into the SQL professional’s workspace. Administrators now have the ability to manage their server instances online in the cloud and use new features and functionality that weren’t previously available in local-network only instances. Developers also have new tools to interact with cloud instance, but also have totally new functionality available to them from a variety of online services.

As of now, I think most of these new advancements augment our current technology instead of replace it. I think this means that some professionals will choose to not learn about them or how to use them. And it’s really easy to justify not learning them — it can be hard for some to find the time to learn something that they can’t immediately use.

However, some professionals will be excited and will learn about these new technologies. Even if their environments don’t need to use cloud platforms and other new features, they will find small areas in their environment that can use these technologies so they start getting experience using them. Worst case, even if it’s not possible to modify something existing with these new tools, these professionals will create sandboxes for themselves and learn to use some of these technologies anyway. By doing this, they will be more confident in using these tools when the time necessitates that they be used.

When it’s time to be promoted or to switch jobs, which of the two professionals is more likely to get hired — the one who knows only his or her old technology really well, or the professional who has taken the time to learn these new features even if they didn’t have to use them in their old environment?

Is my role of business intelligence developer going to disappear?

I’m a professional learner. Officially I’m a business intelligence developer, but unofficially I also am a web developer, manager, DBA, and electrical engineer. I don’t pretend that I am an expert in all of those unofficial capacities (or even the official one!), but I do continually try to improve myself in all of those roles.

Do I worry about having new technologies replace my current job role? No. I do think the tools I use today will be outdated and replaced at some point in the future though.

I imagine some future version of SSRS will be able to generate the majority of the reporting needed for my database based off metadata. Data will continue to evolve and live in environments other than just SQL Server, making my need for SSIS less important — I’ll have to learn other ways to transform data, whether through C#, Python, some cloud querying tool, or all of the above. I’ll have to get used to not only using data from databases and flat files, but also mixing in data from APIs and cloud storage. Some of this data will be relational but a lot of it will not.

And all of that sounds exciting! Learning new ways of working with data is a thrill because it means I won’t get bored working on the same thing year after year. Sure, 10 years from now new technologies will replace my current job — fortunately for me though, by that point I’ll be working with those new technologies.

Thanks for reading. You might also enjoy following me on Twitter.