There are two big things that happened in 2018: 1) I quit my job and moved, and 2) midway through the year, I fell into a slump. This post will discuss both, but I have turned them on their head and am focusing on what I learned from those experiences, rather than dwell on them. Hopefully I am more positive than negative. :)

I just wrote an email asking for feedback from my co-workers, and it got me thinking how I even started that practice - which in turn also led me to think of past bosses I have had and how they have shaped who I am today, professionally.

I can name several of my past bosses by name, easily, even though it has been a span of more than two decades. A lot of people or situations come up where you have a negative experience, and that is why you remember someone. In my case, thankfully, its due to an overwhelmingly positive experience with them. From personal touches, to handling difficult situations in a way that showed strength and compassion, to bolstering me technically, I have been truly honored to have worked for some incredible people. Whenever the topic of mentoring comes up, my first thought is normally - look at your boss! :)

Anyway, back to the topic at hand: asking for feedback. At my most recent past employer, the CIO tasked everyone in the IT department to ask their customers for feedback. From that assignment, I don't know how many of my co-workers actually followed through, but I did. I wrote a beautiful email (if I do say so myself). When I went to hit send, I found it very humbling, and it was hard to actually hit the send button. After all, I poured my heart and soul into the email and I felt I would get a lot of negative feedback (I was stuck in a bad position at the time). To my surprise, no-one in my immediate circle of co-workers responded at all. I did receive 2 replies from a couple of others in IT, both positive, and 2 others who just responded that it was a great email (and they asked permission to use part of it in theirs).

I will admit, I felt quite a bit let down. I was whole-heartedly wanting feedback in order to improve things within myself. While I know in my head that there are a lot of people who say they want to improve themselves, but in reality don't, in my heart it was hard to reconcile that.

Now, when I ask for feedback, I reflect on how the tone of my email was back then, and what I want to say now.  To me, they feel totally different.  When I re-read the first one, back in 2014, I can still feel the pressure I was under, how I really wanted to live up to other's expectations, and truly help every way I could.  Now, I still put that pressure on myself, but I also realize I have to set the expectations myself and live up to them for myself (although that is sometimes easier said than done).

I am including a pdf of the email I first sent to my co-workers back in 2014, and the one I sent this year. Feel free to use part of it, or all of it, if you would like to. I am very glad that the CIO, my boss at the time, wanted me to do this exercise. It has helped me more than I realized even at the time.  I still dread hitting the send button, but am very glad when I do. It feels good to know I am moving forward in my professional life, and I can re-read the email I send for inspiration when I am down.

I challenge you to draft an email, humbly asking for feedback, and providing an insight into what you see as your challenges. Hopefully you will get a response and learn something about yourself. :)

CLICK HERE for my feedback emails

This month's T-SQL Tuesday is being hosted by Malathi Mahadevan (blog) - Non SQL Server Technologies. Mala wants you to share about learning things which arent SQL Server, but help to make us more well-rounded as the data world expands.

I don't know if this qualifies exactly, but I have been learning more about servers and hardware. I don't want to be a server architecture or administrator, but I can see how it helps to understand the hardware to do an even better job at knowing how sql responds.

It all started by using the monitoring tool Spotlight for SQL Server Enterprise from Quest. While there are multiple great tools out there, to me, this has a clean interface and is very helpful in seeing how the moving parts work together. I started wanting to understand all the metrics that the Quest team thought were important enough to visually show. Some of them I was familiar with such as sessions, blocking, cpu usage, and total memory, but there were others I didn't know about. Metrics such as buffer cache, page life expectancy, I/O speeds, etc., were not something I had not been exposed to.

Add to all of this, I had a co-worker at my last job who loved helping others learn and was happy to answer any question you threw at him. Saying he was the server guy doesn't do him justice, yet he still took the time to explain things as they came up. He opened my eyes to how memory coming off the north-bridge was going to be faster than the sticks of memory that are plugged into the motherboard, and why; or how and why the disk and raid configuration matters, along with many other things.

I cant say I know a lot of the hardware "stuff", it is a continual learning process for me. But, that is something that I believe helps me do a better job than I did several years ago. Also, even though a virtual environment doesn't see the underlying hardware in the same way, the concepts are still the same.  My next foray will be learning about the cloud - but that is a topic for another day. :)

All of the companies I have worked for have individual AD accounts with permissions in SQL. They have all wanted to keep things easier by using AD security groups, but there are various reasons why that isnt always the reality, such as: software limitations, linked server config, legacy needs, changes impacting critical processes, etc..

I was recently introduced to the xp_logininfo stored procedure. It is a very handy tool to use to gather information about an AD account, or for user groups. Whenever someone asks for access, it is my go-to to find all of the groups they belong to which already have some permissions.  I still check AD to see if there are more appropriate groups (based on who else is in a group), but I thought I would share how this stored proc is helpful.

• xp_logininfo 'ADaccountName', 'all'
  By including the AD account name, you can get a list of all of the AD security groups that user belongs to, which have permissions on that particular instance being queried. That last part is important. It isnt a list of all of the network groups that user belongs to - it is only those that already exist on that instance of sql. For example, if my account belongs to GroupA, GroupB and GroupC; the sql instance I am querying already has GroupB with permissions; then that will be the only result returned even though my account belongs to all 3 groups in AD.
• xp_logininfo 'ADsecurityGroupName', 'members'
  By including the AD security group name, you can get a list of all of the AD members who belong in that group. This is an easy way of querying to get a list of everyone who has access.

This month's T-SQL Tuesday is being hosted by Wayne Sheffield (blog) - Brick Wall. He wants you to share about a time when you ran up against your own brick wall, and how you worked it out or dealt with it.

I find that, for me, most of the technical reasons for hitting a wall in a project have been solved by asking others for help or researching on my own. I havent come across a wall that I havent been able to climb or go around - so far (I am knocking on wood as we speak).

My professional and personal goals, however, are a different story. At the start of this year, Doug Purnell (blog) and I became accountability partners. I wrote a blog post about it, which you can read here. It was actually due to the Dec 2017 #tsql2sday blog chain! :)

Things were going well for me, I landed a new job which got me out of a bad environment, and was settling in ok. Unfortunately, in early June I felt like I hit a wall. I missed one of our bi-weekly meetings due to an unexpected family thing and to me it felt like a big thing. In that call, we had scheduled time with Grant Fritchey to answer some questions and pick his brain. I have started an email to Grant to apologize for missing that meeting and ask to reschedule, but I havnet sent it yet. I feel bad about missing, and this is where the wall comes in: I am beating my head against it waiting to bust through before I send it, which is silly because I know it doesnt work that way.

If it weren't for Doug and our continued meetings and communications, I dont know if I would be on track right now. If I am just setting goals and noone else knows about them, its easy to slide for a month with no momentum. But, since I have someone else to keep me going, it makes it harder to not move at all. Doug recently told me he was re-evaluating the list of goals that we originally set for ourselves at the beginning of the year, and that made me feel like I had permission to do the same. Its silly, but that really helped and made me feel relieved - it helped release a lot of the pressure I was putting on myself.

In summary, I think I am still at the wall today, but am on the track to finding my way around it, thanks to the help of Doug. I think we set ourselves up for success by finding each other when things were going well, so that we have a system in place for when things got messier.

I am very grateful for this topic this month... it really made me stop and think. I am going to send the email to Grant today so that I can stop beating myself up for not doing it yet.

This month's T-SQL Tuesday is being hosted by Bert Wagner (blog | twitter) - Code You Would Hate To Live Without. He wants you to share about the code that you would hate to live without, whether yours or someone else's.

I know there will be a lot of wonderful posts about this topic! I have 2 things that stand out as scripts I love.

• I changed a stored procedure which used a cursor and ran for 45 mins, into a set-based query that runs in less than 5 mins. While I know I am stretching the topic just a little, it is something I think about often, very proudly. This was something that helped cement the idea that I was on the right path in my career. I knew I loved working with data and databases, but I remember the level of excitement I had when I got it to work. :)

• The other script is something I put together which works with log shipping for multiple databases. I made a robust, automated process from start to finish. There are still improvements I would make to it, but I dont work for that company anymore, so I probably wont have a chance in production for a while. The vendor had multiple databases (approx 45) and that number would continue to grow as we added more businesses. Therefore, the solution had to be dynamic, nimble and easy to maintain. I am proud of the documentation (ohhh... I said a bad word), workflows and full process with error handling, I set up. It was also easy to troubleshoot and only run one or a few databases at a time if only some were lagging behind.

While neither script is a general purpose script (they are specific to the company I worked for at the time), they both make me feel confident in my abilities as a DBA. I know that I can keep at something to make it eventually bend to my will (muwhahha), and enjoy myself along the way.