This month’s T-SQL Tuesday attracted some great responses! Thank you to everyone who participated!

Reitse Eskens checked in with T-SQL Tuesday #138 – Keeping up with change. For whatever reason, his pingback did not make it to my blog. I apologize for the oversight, Reitse. Thank you for reaching out so I could get this corrected.

Reitse works a lot in Azure, and Azure changes all the time. He makes excellent points regarding changes in the security portal, which he and his team uses to compare baselines. The portal layout changes several times per year, which is a challenge. After providing additional examples, Reitse leaves through the door he entered with a great quote:

Everything changes. Constantly. Some changes are good, some are bad, some make no difference. But you have to keep up in some way. You’re the only one who can decide what your best way is.

Very true, sir. Good post and thanks for participating!

Rob Farley‘s response closely matches my response (at the bottom of this post). In a word, acceptance. Rob’s medical analogy is spot on, methinks. I love his conclusion: “…I just accept that technology will change in the moments when I’m not looking.” Same here, my brother from another mother. Same here. Thanks Rob!

Kevin Chant‘s post grabbed a lot of attention on LinkedIn (thanks Kevin!). Early on, Kevin makes an excellent point about the velocity of changes in Azure: “In reality, this is something that keeps me busy these days. Especially with the rapid changes to cloud services.”

He keeps up by watching Twitter and LinkedIn. One of Kevin’s examples is ” the evolution of Azure Synapse Analytics. Where it is gone from being viewed as a replacement for Azure SQL Datawarehouse to a fully integrated solution.” Preach.

In summary, Kevin offers this advice: “…I suggest you find a smart way to keep on top of changes that works for you. To avoid feeling like you need to be online all the time to keep up with changes.” Great advice, in my humble opinion. Thanks Kevin!

Greg Moore learned about Microsoft SQL Server in school, by experience, SQL Server Magazine, and the SQL Connections conference. He says, “I would say a bit part of keeping my skills up to date is not just learning from others, but from teaching. Teaching forces me to keep my skills up.” I concur, sir. Thanks Greg!

I admire Hugo Kornelis‘ transparency with statements like “…I regularly discover new cases that prove my previous understanding wrong. Or, rather, incomplete.” He contrasts in-person events with recorded online events: “Even if I want to have the recording changed, I can’t. But frankly, I don’t want to. A recording of a session is exactly what you’d expect it to be: a recording of something that took place. It should not be changed later. Then it’s no longer a recording of that event.” I love Hugo’s response, “You should expect them to become outdated over time.” His conclusion? “The bottom line is that there is no single answer.” Thanks Hugo!

Deborah Melkin classifies change events driven by:

• Something is “fixed” or improved
• [Something is] restructured and reimagined
• Shiny brand new features or technology

She makes an excellent point regarding new features:

But the reason I feel like I come across as opposed to the changes is I will hear about it in terms of “we’re having problems with ABC so let’s just replace it with FGH”. What I don’t hear is how have we tried to fix ABC or is the problem with ABC really something that is solved by FGH.

I love her conclusion: “But it always comes down to understanding the problem we’re trying to solve and what role the changes in tech have to play in it if we’re going to be successful.” Thanks Deborah!

In Dale Hirt‘s first-ever T-SQL Tuesday post (w00t!), he reveals his “three-step process to quickly evaluate, categorize, and handle tech change as it comes in”:

1. What is the purported purpose of the new tech? What is it’s philosophy, or viewpoint? Do I see things how it sees them?
2. What does it actually do? What are the limitations, features that work, features that don’t work, and do they add to my toolbox, or do I have to reconfigure everything around the new tech?
3. Is it mandated that I use it? Does management have a business need for this change? Or is it being driven by the end users?

In addition to these points (which you should read because of details Dale provides), he has some good thoughts on technical debt. Dale’s conclusion to this section is awesome: “We merely trade it for another set of debts.” Thanks Dale!

Barney Lawrence weighs in with his subtitle, “Grab it with both hands and cling on tight!” He then focuses: “One aspect of T-SQL that everyone should embrace is window functions.” I’m a do-what-you-are-passionate-about kind of guy, so I appreciate Barney’s passion and applaud it. Thanks Barney!

John McCormack titles his response Why I certified to become more than a SQL DBA. He explains he was enjoying being a DBA when: “Then I heard we were going to start using ‘The Cloud’. Not only that but I was going to be responsible for the operation of our Kafka clusters, EMR and ElasticSearch.” John admits: “Simply learning to use PuTTY to log into a linux VM was one of my early successes.” (Loving that transparency!)

I was particularly inspired by “I approached the [AWS] certification process from a genuine perspective of learning the technology well, rather than just passing the exam.” (Loving that attitude!) Thanks John!

Todd Kleinhans, another brother from another mother, checks in with a Star Wars-inspired quote: “I’ve been using SQL Server since the last millennium and I’ve seen a lot of things come and go (to echo my inner Han Solo).”

He offers good advice in a couple section headings:

1. Only the Paranoid Survive
2. Only the Plugged-in Survive

Todd then describes personal experience learning RAPIDS, about which he shares:

Alas, even as I’m taking copious screenshots and notes using OneNote, they are releasing new features with every release- roughly every six weeks, which at times feels like that is faster than I can learn about them.

His (near-)final advice? “Learn and try to stay plugged-in. Talk to people. Ask questions on forums.” Thanks Todd!

Chris Johnson speaks to SQL Server version upgrades, the Data Migration Assistant, and “Things the Assistant can’t help with.” His company is moving away from SQL Server 2008R2 (his experience is not unique), and he’s found lots of help by using Data Migration Assistant. There remain some pitfalls, some of which Chris covers in his third segment. He provides a poignant example that is definitely on-topic. Thanks Chris!

Props to Mikey Bronowski for working in both a Shrek and David Bowie reference and using the heading “Cloudvolution” which he opens with: “Cloud, Azure, in particular, was always a synonym of “change” to me.” Mikey shares an experience echoed by others:

I gave my first talk at the local user group. This helped me to understand problems even more. That time I figured out that by teaching I learn even more.

Thanks Mikey!

Near the beginning of his (excellent) response, Glenn Alan Berry states: “My basic mindset (which may be too optimistic) is that new versions are intrinsically better than older existing versions.” He concludes this section admitting:

Most of the time, new versions are an improvement over what they replaced, but not always. Especially with software, new versions sometimes make things worse.

Glenn compares and contrasts early adoption with “…an underlying resistance to change” before tackling the art and science of balancing such approaches. His concluding thoughts reflect personal experience: “I sometimes joke to my wife that I can’t leave well enough alone. This can cause frustration and wasted time, but I usually learn new things along the way.” I literally laughed out loud because I’ve made similar statements to Christy! Thanks Glenn!

Alex Stuart shares well-written thoughts on his theme: “Essentially – ‘adapt or die’. Technology will move either with or without you, so you must adapt to it or be left behind.” His use of a train analogy to explain responses to change is pretty awesome (in my humble opinion), with these thoughts:

• Do nothing, because I’m already on the train, at the front, on my 4th Heineken
• Jump on the train when it gets here as it’s shinier than I thought it would be
• See the train coming, but don’t get on, because the road is still open and I like driving
• Reluctantly get on the train after walking for days because the powers that be have blocked the road to build another trainline

I like his writing style.  Thanks Alex!

Chad Callihan shares his secrets to keeping up:

• Blogs
• Social Media
• Job Postings

He recommends “[combining] them all to stay ahead.” I love the transparency of Chad’s advice:

Don’t fake knowing what you don’t know.

That’s good advice right there. Thanks Chad!

Last but certainly not least, yet another brother from another mother, Steve Jones, identifies with my original plight (changes breaking the code in my newly-published book): “That’s a scary place to be, and it’s one I’ve rarely experienced.” It was not pleasant, Steve, I will tell you that!

Steve shares his preference: I prefer to have something fairly well settled before I spend time on it.

From experience, he shares:

A fair amount of code I’d written had to be abandoned. I felt as though I’d wasted some time, but as I stopped to think, I realized that I’d been learning and growing in this area. I’d understood how things worked, and while I had to write new code, I was able to write it quicker because I understand the general problem space already.

I’ve experienced the same thing and I admire Steve’s attitude. Thanks Steve!

Me

For me, the short answer is: I roll with it.

That sounds really awesome, doesn’t it? “Roll with it.” Sometimes it’s easier to roll with the changes than other times. If you read the post about the technology changing under my book code, you get a sense of my first response. I was the king of “OH NO!” Worse, I discovered the change during a live stream. I made up for it by streaming a few more times that day, each time failing to find – much less fix – the problem.

“So, What Worked, Andy?”

I’m glad you asked! I slept on it. I awoke the next morning with a plan to troubleshoot the issue. I love it when a plan comes together.

Conclusion

I’d like to thank Steve Jones for the honor of hosting a T-SQL Tuesday!

I would also like to thank everyone who responded – yall rock! – and everyone who read through these responses.

:{>