Category: Editorial

It’s been a little over a week since the 2019 PASS Summit and Ignite conferences ended. These are two of the largest events for data platform pros, and quite a few people either attended or watched some streaming from the events. I didn’t attend sessions at either one, and I have been trying to stream a few of the sessions as I find time.

John Morehouse, of DCAC, wrote a nice piece at the end of the 2019 PASS Summit as he was thinking about how to grow his career after the event. He included a few things that he wants to do, such as looking over notes, touching new contacts, and sharing his knowledge. His post is worth a read, and you might follow along and try some of John’s ideas.

I am a huge fan of notes, and really, paper notes. I’ve had a laptop for decades, I’ve had a screen I could write on for eight or so years, and I’ve found that nothing replicates the feeling of writing notes on paper. Perhaps it’s the slower pace, or the ease with which I can scratch out something (as opposed to the backspace, backspace, backspace method). I find that writing things down helps me remember. I don’t go back and review them too often, but I do at times. If you didn’t take notes at this event, plan for the future. If you did, glance through them before you start sharing information with others.

At a few places I worked, the boss actually scheduled a half day or so (or hour meetings across a few days) in order for conference attendees to share some things with others. Attendees might present something to others, or just talk about sessions they attended. I do like the USB sticks (or downloads) that PASS lets you buy. If you attended, they’re steeply discounted. If you didn’t, they’re still reasonable. This is the chance to capture the presentations and watch those that conflicted with your schedule. I know a few people will do lunch and learns, watching a session a day for weeks. Some user groups do this as well. It’s a great way to think about how you can improve something at work and show an ROI.

I think networking is the best reason to go to a conference and not just because you might want a new job. Certainly that can be one outcome, but the best part of networking for me has been the ability to reach out later to someone and ask a question. This isn’t just to the MVPs, speakers, and other big names. I’ve made contacts that used similar software or had environments configured like mine. Being able to ask them if they have solutions has helped me at different points in my career. Make sure you reach out to people on LinkedIn if you met them. If you met me, please feel free to connect.

A conference is a fun, busy, inspiring, tiring, and exciting event to attend. I’m very lucky I’ve attended many, and even if you’ve only gone to one, you ought to feel the same way.  Whether it’s a week at a large event or a day at a SQL Saturday, take some time and ensure you get something out of the week to carry you along for the next few months.

P.S. If you want to share some knowledge with a wider audience, I’d love an article on something you learned at a conference.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Some of us have experienced lots of strange issues while working with SQL Server. Some from poorly configured or coded systems, some from heavy workloads, and some from bugs in the code. Encountering and solving those problems, even if self-induced, is one way that we have learned about the best ways to ensure SQL Server performs extremely well under many situations.

Others of us have had few issues and found SQL Server to be a very stable and solid product. In fact, I often find someone posting about an issue has been running an instance for years without any issues until one day something breaks or reaches a tipping point. I’ve seen this with numerous instances that were installed with plenty of disk space and without log backups. They may run for a year or more before logs fill and cause issues.

It can be hard to plan for the unknown disasters that might be lurking in your system, but one thing that might help you think more widely about potential issues is reading posts about the issues others have encountered. Certainly plenty of people blog about these, and we often put out in our Database Weekly newsletter, but there are other good sources.

The CSS SQL Server Engineers write some interesting posts about issues they’ve solved. Availability Groups are important and harder to configure and manage than many people realize. I caught a really interesting post about strange behavior under high workloads. This was with In-Memory technology, which I am starting to see more people experiment with implementing. This is the type of post that might give you pause, but also help you plan for and be aware of an issue that could occur.

In this case, it’s a bug and a CU fixes the issue. Without knowing this, you might open your own case and spend time debugging the issue. Reading an article like this might trigger you to go back and check on it if you experience the issue. The bigger advantage I see here is there is a lot of information about how to measure and understand the performance of various parts of an AG system with code and linked articles here. While others might tell you there’s a CU to fix a specific issue, the knowledge you gain about how to dig into the performance of your AG setup could help you solve lots of other types of issues.

Keep learning and keep reading. There’s lots of amazing SQL Server information on the Internet for you, and we’re happy to keep bringing some of it to you at SQLServerCentral.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

Most of us have applied for a job at some point in our career. In my youth, this was finding a listing in a newspaper or on a storefront and then going in to apply in person. At times I didn’t really care what the job description was, as I needed a job. Usually the title was enough to decide if I wanted to be a “waiter” or “cashier” or “laborer”. I am somewhat glad those days are behind me, at least for the most part. My wife usually expects her fence builder and cook to be regularly available.

In the technology fields, we often have very detailed job descriptions. In fact, I think most of the job descriptions I see have had too much input and ask for more skills than any individual is likely to have. In my experience, if I meet at least 50% of the required skills, I apply. I’d encourage you to do the same, as many of the requirements are flexible as hiring managers realize they can’t find someone that meets 100% of their desires.

Today, I’m wondering if any of you ever look back at the job description that you were hired to fill. Does your current work match what was written when you applied? Did you end up doing more or less of what was listed? Or has the job evolved as you’ve been in this position. Would you still be qualified for this position? Over-qualified? Or maybe you feel you’re still not quite qualified enough?

I’m kidding about the last one, though there are always people searching for a challenge and enjoying the struggle of learning and growing their skills. In fact, some of the most talented people I know have had lots of success and still struggle with impostor syndrome, which I think drives them to be better. Or maybe some just have the Jerry Rice training habits.

Take a few minutes today and think about your job and the description that was written for it. Has it evolved, or is it what you expected?

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.