Changing Technologies – T-SQL Tuesday

Select <columns> from Some_Table where Condition=’Some Value’

T-SQL Tuesday Topic

The above statement is pretty much the basis of what started my current career. Of course it actually goes back further than that. I have a Computer Science Degree from RPI. So I’ve done programming, learned hardware and more. I even took an Intro to Databases course while at RPI. I still recall the professor talking about IBM and something called Structured Query Language. The book had a line that went something like “while not the most popular database technology, its use may grow in the future.” Boy did it.

When I first started working with SQL Server, it was 4.21 and for a startup. I had a lot to learn. Back then, a lot was by experience. Sometimes I made mistakes. But I learned.

When I started at that startup, if one could write basic queries and backup and restore a database, one was a half-way decent DBA. Knowing how to tune indices was a definite bonus, as was knowing things like how to set up log-shipping and replication.

Back then, besides experience, I learned new stuff two ways: SQL Server Magazine and the SQL Connections conference. Work paid for both. It was worth it. But honestly, there wasn’t too much to learn. But there also weren’t as nearly as many resources as there were today.

Fast forward 30+ years and here I’ve written a book, worked for several startups, regularly write about databases and database related topics, and often presented at User Groups, SQL Saturdays and at the now defunct PASS Summit. Today as a consultant I regularly touch the SQL Server Query Engine, SSAS, SSRS, SSIS, use PowerShell, write the occasional C# and VB.Net, sometimes do work on a Linux machine or VM and more. A lot has changed.

Obviously the technology has changed. So how have I responded? By doing what I said above. This may sound like a tautology or even circular reasoning but it’s true. When I would go to a SQL Saturday, I’d often attend 3-5 different topics. I’d learn something. But then I started presenting. And that forced me to learn. As much as I may like to think I know about a topic, when I go to present about it, I like to ensure I know even more. This forces me to read white papers, other articles and perhaps attend other sessions.

When I’ve written an article, I’ve often had to do a lot of research for it.

So strangely, 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.

In summation, I’ve responded by learning from others, but also forcing myself to teach myself before I taught others. It’s a feedback loop. The more technology changes, the more I reach out and learn and the more learn, the more I do outreach.

The impetus for this week’s blog was Andy Leonard’s call for a T-SQL Tuesday topic.

Hiring

Not sure why it came to mind last night, but I was thinking of the best hire I never made. This expanded into me thinking about folks I have hired over the ages. As a Director of IT and later a VP of IT, I’ve had to make a lot of hires over the years, some better than others. Even when I can’t remember their names (an unfortunate weakness of mine) I can almost always remember their faces and how they worked out. And fortunately, most of them worked out quite well, even the ones who surprisingly might think they didn’t.

Looking back, I would say there was probably only one person I absolutely should not have hired and she was the only person I ended up having to let go because of performance issues. There were a few how were less than stellar, and a few I had to let go because of budget cuts, but even those weren’t necessarily bad hires.

But then there’s the one that “got away” and honestly, when I reflected upon it, I was glad, for both of us. Back in the early days of the first dotcom bubble I was working for a company that was quickly expanding. I can’t recall how many interviews a day I was doing, but it was a lot. We were looking to ramp up quickly and I couldn’t afford to be too picky. That said, some of my best hires came during that period.

In this case she was an ideal candidate, both on resume and in person. She had a great college background, ticked all the checkmarks in terms of classes taken and experience. She did great during the interview, both technically and in terms of how I thought she’d be for the team I was looking to build. In fact, looking back, I think she would have been the first member of said team and as such would have been a good role model for others.

There was only one issue, and we both recognized it in time. We were a startup. We didn’t ask that stereotypical (and I think bad) question of “where do you see yourself in 5 years?” because, heck, we didn’t know where we’d be in 5 years. We didn’t have a clear career path of growth for employees. I mean it was obvious we’d grow and there would be steps up, but there was no clear org chart.

On the other hand, companies like GE, especially back then, had a very clear progression path. If you wanted management, you knew the path to take and it was pretty clear that both parties would work to make it happen.

And, it became apparent, she wanted to know where she would be in 5 years. And there was absolutely nothing wrong with that. We made her the offer, but I half-hoped she’d turn it down and was relieved in some ways that she did. Yes, she would have been a great hire for us. However, honestly, for her own career, it probably would have been a mistake.

But, I have to wonder what things would have been like had she joined the team. She would have been great. She’s the one that got away. And I’m OK with that.