Mental Health Day/Week

My new company, Redgate Software, has a Mental Health Week every year and also has a day dedicated to Mental Health. The goal of the day is to take a day off work, reset, and focus on something related to your mental health.  

I’ve never really had this at former companies, so I thought I would discuss it a little here on the Blog and get thoughts from others. I have taken plenty of days off for my mental health in the past, and I’ve suggested it to many of my employees, but it was an informal thing that I did on my own; none of the companies I worked for had a dedicated day/week for it.  

For many of us in this technical industry, we don’t really “shut off”. Meaning even if you give us days off, we still work. This is very true for me and most of my career, as I’ve been on call or managing teams and rarely am “shut off”. The few times this was true were when I’ve been out of cell range in the mountains. Even then, I would seek to find wifi after about a day to check in with the team.   

That brings me to my new role and the very different life I live. I’m not on call, I don’t manage anyone else, and I can be officially “shut off”. That is very scary to me.  

For anyone who has spent half their life doing something, you know it’s not easy to just change that something. It takes time to change habits, thoughts, and processes you have built over many years. 

I see myself as a Recovering DBA, someone who has spent the better part of their life in the Operational DBA role, but now that’s not my role anymore. 

I have a plan for my day off. Yes, I plan to get some work items done, but I also intend to take a long bike ride, do some cleaning around the office, and move things around. Something that makes my space feel more like it’s ready or my role vs the DBA role I had in the past.  

I very much appreciate that my new employer gives us a mental health day. I’m sure it’s going to take me a lot more of these days to truly reset. We do things one day at a time, though, and keep moving forward every chance we get.  

Would love to hear your thoughts on what you should do for a Mental Health day.  

T-SQL Tuesday #195 Summary 

What a great collection of stories all about aging!  I really appreciated everyone take time to reply to the question.  

I’m going to do this a little differently for my summary. I will list the blogs below and provide key summary points for each.  I also created a video summary. I intend to do more of this in the future. 

You choose how you would like to consume the content, and share with me how you would prefer to see it in the future!  I intend to do a lot more video/audio work in the future. 

You will have to find my perspective on this topic in the video link. 

Rob Farley

Key summary: Rob talks less about specific code and how it has aged, he reminds us how important it is to understand that databases live, breath and change over time.  The queries will need to be updated and reviewed in the future.  It doesn’t mean the original query was bad; it’s just not as new as it once was, and it’s important that we review these older queries to determine whether they are still performing well.  

Hugo Kornelis 

Key Summary: Hugo talked about code he started way back in 2013(not too long ago for some of us). He took what he could from the code, improved it, documented it, and sent it on its way.  Over the years, he had to continue providing support, but there were no real changes to the system beyond that.  That speaks to the dedication and hard work of putting time into a project to leave it better than you found it.  Investing time up front in your code and in the logic can pay off in the long run.  I’m happy I could take him for a trip down memory lane! 

Steve Jones 

Key Summary: Steve shows us some old string-manipulation code he wrote a long time ago. He makes it clear that some of the functions or code we have used in the past can still do the work today. Sometimes minor changes are needed, or perhaps a more efficient approach is possible, but for the most part, it still works well!  This reminds me of a Date script I keep around and will discuss in the video version of this summary. 

Chad Callihan 

Key Summary: Chad told a story about how a simple idea and solution he presented for an open opportunity are still useful.  It shows that even if it’s not your specific area, it’s a good idea to provide solutions, and they may last a very long time.  

Andy Brownsword

Key Summary: I really like what Andy said at the end of his post, “It’s not enough to make it work correctly. It needs to fail correctly too”.  I think this does a really good job of summarizing aging code.  If we plan and prepare for failures better, then we will handle aging that much better. 

Deb the DBA

Key Summary: Deb focused on how to keep your code from becoming legacy.  I enjoyed this take on the question, which provides guidelines on how to ensure that, as it ages, it does so well and remains useful moving forward. 

Todd Kleinhans

Key Summary: I’m pretty sure I’ve run into Todd at some event in the past. If not, I need to!  He shares many of the same philosophies as I do: “Keep Moving forward”! Focus on what you can do right now, use documentation, best practices, and good guidelines, and push forward with what you are doing.  Focusing on the past just enough to learn from it and then move on.  Love this perspective. 

T-SQL Tuesday #195 –“How has your code aged”

T-SQL Tuesday #195

I’m a little late getting this together, but that’s not entirely my fault.

For this month’s T-SQL Tuesday, I wanted to once again talk about Aging!  But not in the human sense.  I mean in the code sense. It’s a simple question that can be interpreted in many ways, and I look forward to all the ways you might see this.   

The question is.  “How has your code aged?”   

Pick a project or code script and decide if it “aged well”.  Is it still in use?  Is it functioning?  Did it do what was needed, and now it’s no longer around?   Perhaps talk about how useful it was for the time, but now it would never be needed because of AI or other aspects.  

Knowing what we have done in the past and how we have improved is very important to moving forward.  It’s also a great time to be grateful for something you created in the past, and perhaps it is still working.  Very often in this fast-paced world, we spend all of our time looking at the new project and the next big thing, and we forget to enjoy the things that created the foundation for our future.  

I hope you will join this exercise by posting on February 10th, 2026.   Please make sure to link to this original post and include the T-SQL Logo on the post.  I’ll write up the summary after Tuesday, and we have all the posts listed.