SQL Saturday Albany 2020

So, another SQL Saturday Albany is in the books. First, I want to thank Ed Pollack and his crew for doing a great job with a changing and challenging landscape.  While I handle the day to day and monthly operations of the Capital Area SQL Server User Group, Ed handles the planning and operations of the SQL Saturday event. While the event itself is only 1 day of the year, I suspect he has the harder job!

This year of course planning was complicated by the fact that the event had to become a virtual event. However, it’s a bit ironic we went virtual because in many ways, the Capital District of NY is probably one of the safer places in the country to have an in-person event. That said, virtual was still by far the right decision.

Lessons Learned

Since more and more SQL Saturdays will be virtual for the foreseeable future, I wanted to take the opportunity to pass on some lessons I learned and some thoughts I have about making them even more successful. Just like the #SQLFamily in general passing on knowledge about SQL Server, I wanted to pass on knowledge learned here.

For Presenters

The topic I presented on was So you want to Present: Tips and Tricks of the Trade. I think it’s important to nurture the next generation of speakers. Over the years I was given a great deal of encouragement and advice from the speakers who came before me and I feel it’s important to pass that on. Normally I give this presentation in person. One of the pieces of advice I really stress in it is to practice beforehand. I take that to heart. I knew going into this SQL Saturday that presenting this remotely would create new challenges. For example, on one slide I talk about moving around on the stage. That doesn’t really apply to virtual presentations. On the other hand, when presenting them in person, I generally don’t have to worry about a “green-screen”. (Turns out for this one I didn’t either, more on that in a moment.)

So I decided to make sure I did a remote run through of this presentation with a friend of mine. I can’t tell you how valuable that was. I found that slides I thought were fine when I practiced by myself didn’t work well when presented remotely. I found that the lack of feedback inhibited me at points (I actually do mention this in the original slide deck). With her feedback, I altered about a 1/2 dozen slides and ended up adding 3-4 more. I think this made for a much better and more cohesive presentation.

Tip #1: Practice your virtual presentation at least once with a remote audience

They don’t have to know the topic or honestly, even have an interest in it. In fact I’d argue it might help if they don’t, this means they can focus more on the delivery and any technical issues than the content itself. Even if you’ve given the talk 100 times in front of a live audience, doing it remotely is different enough that you need feedback.

Tip #2: Know your presentation tool

This one actually came back to bite me and I’m going to have another tip on this later. I did my practice run via Zoom, because that’s what I normally use. I’m used to the built-in Chroma Key (aka green-screen) feature and know how to turn it on and off and to play with it. It turns out that GotoWebinar handles it differently and I didn’t even think about it until I got to that part of my presentation and realized I had never turned it on, and had no idea how to! This meant that this part of my talk didn’t go as well as planned.

Tip #3: Have a friend watch the actual presentation

I actually lucked out here, both my kids got up early (well for them, considering it was a weekend) and watched me present. I’m actually glad I didn’t realize this until the very end or else I might have been more self-conscious. That said, even though I had followed Tip #1 above, they were able to give me more feedback. For example, (and this relates to Tip #2), the demo I did using Prezi was choppy and not great. In addition, my Magnify Screen example that apparently worked in Zoom, did not work in GotoWebinar! This feedback was useful. But even more so, if someone you know and trust is watching in real-time, they can give real-time feedback such as issues with bandwidth, volume levels, etc.

Tip #4: Revise your presentation

Unless your presentation was developed exclusively to be done remotely, I can guarantee that it probably need some changes to make it work better remotely. For example, since most folks will be watching from their computer or phone, you actually may NOT need to magnify the screen such as you would in a live presentation with folks sitting in the back of the room. During another speaker’s presentation, I realized they could have dialed back the magnification they had enabled in SSMS and it would have still been very readable and also presented more information.

You also can’t effectively use a laser pointer to highlight items on the slide-deck.

You might need to add a few slides to better explain a point, or even remove some since they’re no longer relevant. But in general, you can’t just shift and lift a live presentation to become a remote one and have it be as good.

Tip #5: Know your physical setup

This is actually a problem I see at times with in-person presentations, but it’s even more true with virtual ones and it ties to Tip #2 above. If you have multiple screens, understand which one will be shown by the presentation tool. Most, if not all, let you select which screen or even which window is being shared. This can be very important. If you choose to share a particular program window (say PowerPoint) and then try to switch to another window (say SSMS) your audience may not see the new window. Or, and this is very common, if you run PowerPoint in presenter mode where you have the presented slides on one screen, and your thumbnails and notes on another, make sure you know which screen is being shared. I did get this right with GotoWebinar (in part because I knew to look for it) but it wasn’t obvious at first how to do this.

In addition, decide where to put your webcam! If you’re sharing your face (and I’m a fan of it, I think it makes it easier for others to connect to you as a presenter) understand which screen you’ll be looking at the most, otherwise your audience may get an awkward looking view of you always looking off to another screen. And, if you can, try to make “eye contact” through the camera from time to time. In addition, be aware, and this is an issue I’m still trying to address, that you may have glare coming off of your glasses. For example, I need to wear reading glasses at my computer, and even after adjusting the lighting in the room, it became apparent, that the brightness of my screens alone was causing a glare problem. I’ll be working on this!

Also be aware of what may be in the background of your camera. You don’t want to have any embarrassing items showing up on your webcam!

For Organizers

Tip #6: Provide access to the presentation tool a week beforehand

Now, this is partly on me. I didn’t think to ask Ed if I could log into one of the GotoWebinar channels beforehand, I should have. But I’ll go a step further. A lesson I think we learned is that as an organizer, make sure presenters can log in before the big day and that they can practice with the tool. This allows them to learn all the controls before they go live. For example, I didn’t realize until 10 minutes was left in my presentation how to see who the attendees were. At first I could only see folks who had been designated as a panelist or moderator, so I was annoyed I couldn’t see who was simply attending. Finally I realized what I thought was simply a label was in fact a tab I could click on. Had I played with the actual tool earlier in the week I’d have known this far sooner.  So organizers, if you can, arrange time for presenters to log in days before the event.

Tip #7: Have plenty of “Operators”

Every tool may call them by different names but ensure that you have enough folks in each “room” or “channel” who can do things like mute/unmute people, who can ensure the presenter can be heard, etc. When I started my presentation, there was some hitch and there was no one around initially to unmute me. While I considered doing my presentation via interpretive dance or via mime, I decided to not to. Ed was able to jump in and solve the problem. I ended up losing about 10 minutes of time due to this glitch.

Tip #8: Train your “Operators”

This goes back to the two previous tips, make sure your operators have training before the big day. Setup an hour a week before and have them all log in and practice how to unmute or mute presenters, how to pass control to the next operator, etc. Also, you may want to give them a script to read at the start and end of each session. “Good morning. Thank you for signing in. The presenter for this session will be John Doe and he will be talking about parameter sniffing in SQL Server. If you have a question, please enter it in the Q&A window and I will make sure the presenter is aware of it. This session is/isn’t being recorded.” At the end a closing item like, “Thank you for attending. Please remember to join us in Room #1 at 4:45 for the raffle and also when this session ends, there will be a quick feedback survey. Please take the time to fill it out.”

Tip #9: If you can, have a feedback mechanism

While people often don’t fill out the written feedback forms at a SQL Saturday, when they do, they can often be valuable. Try to recreate this for virtual ones.

Tip #10Have a speaker’s channel

I hadn’t given this much thought until I was talking to a fellow speaker, Rie Irish later, and remarked how I missed the interaction with my fellow speakers. She was the one who suggested a speaker’s “channel” or “room” would be a good idea and I have to agree. A private room where speakers can log in, chat with each other, reach out to operators or organizers strikes me as a great idea. I’d highly suggest it.

Tip #11: Have a general open channel

Call this the “hallway” channel if you want, but try to recreate the hallway experience where folks can simply chat with each other. SQL Saturday is very much a social event, so try to leverage that! Let everyone chat together just like they would at an in-person SQL Saturday event.

For Attendees

Tip #12: Use social media

As a speaker or organizer, I love to see folks talking about my talk or event on Twitter and Facebook. Please, share the enthusiasm. Let others know what you’re doing and share your thoughts! This is actually a tip for everyone, but there’s far more attendees than organizers/speakers, so you can do the most!

Tip #13: Ask questions, provide feedback

Every platform used for remote presentations offers some sort of Q&A or feedback. Please, use this. As a virtual speaker, it’s impossible to know if my points are coming across. I want/welcome questions and feedback, both during and after. As great as my talks are, or at least I think they are, it’s impossible to tell without feedback if they’re making an impact. That said, let me apologize right now, if during my talk you tried to ask a question or give feedback, because of my lack of familiarity with the tool and not having the planned operator in the room, I may have missed it.

Tip #14: Attend!

Yes, this sounds obvious, but hey, without you, we’re just talking into a microphone! Just because we can’t be together in person doesn’t mean we should stop learning! Take advantage of this time to attend as many virtual events as you can! With so many being virtual, you can pick ones out of your timezone for example to better fit your schedule, or in different parts of the world! Being physically close is no longer a requirement!

In Closing

Again, I want to reiterate that Ed and his team did a bang-up job with our SQL Saturday and I had a blast and everyone I spoke to had a great time. But of course, doing events virtually is still a new thing and we’re learning. So this is an opportunity to take the lessons from a great event and make yours even better!

I had a really positive experience presenting virtually and look forward to my PASS Summit presentation and an encouraged to put in for more virtual SQL Saturdays after this.

In addition, I’d love to hear what tips you might add.

Advanced Braining

I’m currently reading the tome The Power Broker by Robert Caro. For those not familiar with it, it’s the Pulitzer Prize winning biography of Robert Moses. “Robert who?” you may be asking? Robert Moses, perhaps more than any single person literally shaped New York City in the mid-20th Century. Due to his power, he was responsible in NYC alone, for getting the Triborough Bridge, Brooklyn-Battery Tunnel, West Side Highway, Cross-Bronx Expressway, and many other large scale projects built. He outlived a number of borough presidents, mayors, governors and even Presidents. Arguably, for decades he was the most powerful man in NYC, at least in terms of how many was spent and what projects were completed. In many ways he was a visionary.

However, as the chapter I’m currently in discusses, he also could be extremely short-sighted. I’ll come back to that in a moment.

In the past week, several small incidents occurred in my life. Separately, they don’t necessarily mean much, but taken together, I realized there was a little theme associated with them.

Last Tuesday I posted an update on my dryer repair and an issue at one of my clients. I described the work incident as an example of the normalization of deviance. A few hours later, someone I’ve known for decades, originally online, but have since met in person, Derek Lyons (who has a great blog of his own on anime, a subject about which I know nothing) posted a reply to me on Facebook and said he had read my article, liked it, but thought I was wrong. I was intrigued. You can see his comment and my reply at the bottom of last week’s post. The general point though is I think he showed my thinking was incomplete, or at least my explanation was. In either case, it made the overall article a better one.

Then on Wednesday, my editor at Redgate, Kathi Kellenberger  emailed me with changes to my most recently submitted article. One of the changes was to the title of the article. Now, I’ve come to value Kathi’s input, but I wasn’t keen on the title change, so I suggested something different. She wrote back and recommended we go with hers, How to Add Help to PowerShell Scripts because she said “How to…” generates more hits on search engines and in fact a previous article of mine How to Use Parameters in PowerShell was one of their most read articles at the time (106K hits and climbing). I went with her advice.

Yesterday, a friend contacted me. He was in the middle of doing grading for his students and the numbers on his Excel spreadsheet weren’t quite making sense. The errors weren’t huge, but just enough to make him go “hmmm”. So, he reached out to me to take a look. After a few minutes of digging I understood what was happening and able to write back to him and give him a better solution.

All these have something in common: the final product was better because of collaboration. This is a common theme of mine: I’ve talked about the chat system I use at RPI, I’ve talked about making mistakes. In general, I think that when trying to solve a problem, getting additional input is often valuable.

So back to Robert Moses. In the early part of his career, before his efforts focused mostly on NYC itself, he was responsible for other projects, such as the Northern State Parkway and the Southern State Parkway and Jones Beach on Long Island. He started his career in a time when cars were mostly a vehicle of the well-off and driving a parkway was expected to be a pleasant experience (hence the name). His efforts were built around more and more parkways and highways.

By the 1950s though, it was becoming apparent to most everyone else that additional highways actually generated more traffic than they routed away from the area surface roads. What was originally considered a blessing in disguise, where a bridge, such as the Triborough would quickly generate more traffic (and hence more tolls) than expected, was soon seen as a curse. For every bridge or tunnel built in or around NYC, traffic increased far more than expected. And this came at a price. Urban planners around the country were starting to see the effects. Efforts to build more bridges or highways to ease traffic congestion were actually creating more. Even in NYC as Moses was planning for his next large projects opposition was slowly building. However, Robert Moses was blind to the problem. By the 1950s and 60s he had so surrounded himself by “yes men” that no dissidence was permitted. In addition, opposition outside of this offices was silenced by almost any means Moses could use, including apparently the use of private detectives to dig up dirt on opponents.

In the current chapter I’m reading, Caro, the author, details exactly how much money the Triborough Bridge Authority (which was in practice, though not theory, under Moses absolute control) and the Port Authority had available for upcoming projects, including the planned Verrazzano-Narrows Bridge. He goes on to explain how badly the infrastructure of the NY Subway system and the LIRR had fallen into disrepair. Caro suggests how much better things could have been had just a portion of the money the TBA and PA had at their authority had been spent on things like the Second Avenue Subway (something that is only now coming to fruition and will take possibly decades more to complete). Part of the issues with the subway system can be lain directly at the feet of Moses due to earlier efforts of his to get the city to fund his other projects. The issues with the LIRR however were more an indirect result of his highway building out into Long Island.

I suspect some of Caro’s claims are a bit idealistic and would have cost more than the projections at the time (like most projects) and while I think most of the projects he touches upon probably should have been built in the 50s (the Second Avenue Subway being one of them and the LIRR East Side Access being another) they weren’t because of a single man who brooked no disagreement and was unwilling to reconsider his plans.

Robert Moses was a man who got things done. Oftentimes that’s a good thing. And honestly, I think a number of his achievements are remarkable and worthy of praise.

But I have to wonder, how much better of a city could New York be, had Robert Moses listened to others, especially in the 1950s and 60s.

Today’s takeaway? Take the time to listen to input and ask for it. You may end up with a better solution in the long wrong.

 

 

 

Pushing Solutions, not Products

Earlier this week, the governor of New Jersey put out a call for more COBOL programmers. Everything old is new again. Last time I remember such a call was around the year 2000. That said, while I never had the opportunity to learn COBOL, I’m amused by this. It reminds me of a quote I heard in college about Fortran and how one expert didn’t know what language engineers would be programming in in the 21st Century, but they’d call it FORTRAN.

But, I highlight these two languages because the truth is, they are the exception. In reality one has to constantly keep learning. The times, they are a changing as a poet once said. Fortunately for me I’ve been busy during this Covid-19 lockdown, but even still I have free time (some who read my blog may argue too much time!) That said, I’ve been trying to take more time to catch some webinars and to learn new skills.

Over the past few weeks I’ve got a couple of SQL PASS WIT Webinars under my belt. Last week however, I took advantage of Redgate’s Streamed event. (full disclosure: Redgate does pay me for the articles I write for Simpletalk but what I write here is not paid for by Redgate in any way).

There were a lot of great webinars and I did not catch all of them, so please don’t take my lack of mentioning any as a comment on their quality. There were also some I could only listen to partly as I was actually doing work at the time.

First off, I started with Kendra Little‘s session using git for database development. I’m still moving in this direction and it gave me a good insight into what I’m doing right and moreover what I’m doing wrong and how to improve it. I recommend this session to anyone trying to get version control into their database development.

Unfortunately I had to split attention to Grant Fritchey‘s session on learning to effectively use Extended Events (I do have to do billable work from time to time) but did catch some good stuff. Again, if you haven’t played with Extended Events, please do! I recently used them to help debug an issue I was having with a client and their Reporting Server (yes! you can write them for an SSAS instance!) Go Team #ExtEvents.

Andy Mallon’s session on shortcuts for the DBA was excellent and seemed to generate the most feedback in the chat window. I suggest you go to his page and find his print-out for keyboard shortcuts for SSMS. It’ll save you a lot of time. That said, watch the video if you can and see how well Kendra Little did on her “job interview”. (To be fair, I suspect most of us would have done about the same!)

Steve Jone’s session on unit tests was good, at least what I caught of it. Again, client work got in the way. I may go back to specifically watch this one.

After that, I had time to catch Grant Fritchey’s session on SQL Injection. It still amazes me how many programmers STILL write code so susceptible to this. He had a lot of great examples and offered some solutions. Note there’s no single right answer, but there’s definitely a lot of lousy answers.

Friday brought Rob Sewell speaking about SQL Notebooks and using Jupyter. I haven’t used this yet, but it’s on my list for the year.

Again, a great presentation by Grant Fritchey, this time on convincing the DBA to support DevOps. I’m come back to this in a bit.

I think the highlight of Friday was the costumes. In honor of SQLBits which was postponed this year, several of the presenters wore costumes. I think Steve Jones, with his hat, wig, and glasses won in the pure costume category. (You’ll have to check out the videos). But, that said, Kendra took the overall prize with her corgi Freya on her back in a pack. There was just something so wonderful watching her talk about index tuning as she’d casually feed a carrot over her shoulder.

Again there were other sessions and speakers, and even if I didn’t mention them, their presentations were top notch and worth the watch. Again, you can go to: https://www.red-gate.com/hub/events/redgate-events/redgate-streamed/ and catch them o demand. I recommend it.

One of the overarching themes I picked up on was an emphasis on DevOps and using both tools and processes to achieve a successful DevOps environment. Note that I think both are critical. One can have all the best tools, but without good processes, not much will be accomplished. Honestly, one take away I got was I’d rather have good processes and develop my own tools than have tools, but no process. This focus makes sense given Redgates focus on DevOps.  I now in the past I’ve made the mistake of simply thinking of them as a company that sells some cool tools.

I want to close with saying, one thing I appreciate about the #SQLFamily and Redgate does this well, is generally members focus more on solving problems than pushing specific products. I’ve attended more than one webinar hosted by RedGate where other than mentioning them as a sponsor, their name hasn’t come up at all. I’ve seen other members of #SQLFamily do the same thing. They may work for a company that provides tools and solutions, but if you use #sqlhelp on Twitter, you’ll find almost always it’s people there are about solving your problem, not pushing their software or solution.

So that was how I spent part of last week in lock-down. How about you?

P.S. I also made some boule bread to with the homemade chili on Saturday. It was a winner in the Moore House Hold.

 

Bits are cheap

And, as unfortunately as a recent incident in our #SQLFamily community illustrated, apparently at times so is respect.  Bear with me as I relate these two ideas and another incident.

Let me start with a statement that should make more sense by the end of this post: My name is Gregory, but I prefer that you call me Greg. My pronouns are he/him/his.

But first a trip down memory lane. Many of us recall the Y2K issue. This was a direct result of programmers decades ago trying to save bytes in storage (and to a lesser extent memory and CPU cycles) because storage was expensive. By storing dates as just the last two digits of the year, they could cut the storage for years in half. This was important back then because it saved money. But, as many of us recall, as the year 2000 approached, this started to cause more and more problems. (As a point aside, the first example I’m aware of was brought to my attention by a programmer who worked for a bank in 1970. Seems as if they suddenly had issues handling 30 year mortgages!)

Since then of course the cost of storage has dropped and as an industry we’ve moved to storing years as a 4-digit year. No one in today’s day and age would normally question this decision.

But enough of ancient history, let me get to the point of this article: respecting others.

As many readers know, those of us on Twitter will often use the hashtag #SQLFamily.  In the past week I’ve seen two incidents that have illustrated the worst and the best of this family.

In the first case, a member of the community, a woman I had never met, said she was leaving the family, she no longer felt welcome. At an event she had been misgendered not once, but multiple times. For those who aren’t sure what that means, I will, without going into background or details (because they’re not important) say she is a trans-woman. Several people at the event took it upon themselves to refer to her using by male pronouns.

In the most recent case, a fellow speaker, Cathrine Wilhemsen tweeted about how she had been addressed as Cathi and Kathi twice in the previous 24 hours. She says this hasn’t been the only time, but just the most recent and recent enough for her to comment on.

In both cases, part of the problem is that strangers addressed the person in question in a manner that did not respect them; in the first case by not using the proper pronouns and in the second by not using her provided name.

But that’s one part of the problem.  So let’s address that: we have members of the #sqlfamily who don’t respect other members. But, we have another issue, and one that I think is important to address: those who minimize the issue. In the first case, apparently no one called out the folks misgendering the woman.  In a situation like this, a show of support can be as simple as saying something like, “Umm, I think you mean she, not he.”  You can also support the use of pronouns on nametags at events or in the bio descriptions for events.

Remember though, today, bits are cheap. So we can do more. Don’t design your database with a bit field for gender. Make it a table. These are relational databases after all. Have a table for possible gender identifications. Allow for a method to add rows to this table. Have a table for pronouns.  There’s more than you might think and people are often crafting additional ones. While the singular they/them is becoming more popular, it’s NOT the only alternative to he/him, she/hers.

We are data professionals after all. We absolutely should not lock our data into a single view of the world if that worldview is changing. (Note, the world is not changing, there have been multiple genders throughout recorded history.  We’re simply becoming more cognizant of it now.)

In the case of Cathrine being called by another name, keep it simple. Use the name provided, be it in an introduction, on the nametag or other method. Respect the person’s wishes. And do not, as some did on Twitter respond by “well they probably didn’t mean anything” or “eh, just roll with it.” It’s not YOUR name. It’s not YOUR identity. Sure, you might not care if someone calls you Richard, Rick, Ricky or Dick. But another person might. Their name is part of their identity, respect their wishes.  I will add one more note that Cathrine shared with me and that other women have shared with me, it is almost always men that will use nicknames or cute names or similar without prompting.  Yes, fellow men, I’m calling you out. We may not think about it. In fact I would argue we often don’t think about it. It’s something that privilege allows us. But be aware that your attempt to be friendly or familiar is actually often coming off as diminishing and condescending.

Now, despite the failure of some members of #SQLFamily, I want to celebrate the great people in the community. These two incidents have created a lot of responses. I’ve seen at least two great posts, one from Jen McCown and another from Kellyn Gorman. I’m sure there are others. I also have written in the past about being an ally. But in addition, while I’ve seen one or two tweets that have dismissed Cathrine’s tweet, I’ve seen many members rally to the defense of the women in both incidents. And, also very importantly, I’ve seen several tweets from people asking, “how can I help?” or “how can I improve my behavior?” I love that last one. I’m constantly trying to unlearn some of the behaviors I was taught and to be more conscious of what being a white, straight cis-het male brings to the table. We can always learn to do better.

Yes, our #SQLFamily has some members who could and need to do better. That saddens me. Fortunately as I’ve seen, it also has a lot of members actively striving to do better and help others do better. That gladdens me. Let’s all be the latter.

Respect and disk space don’t cost us much. Let’s learn to be respectful of people and to design databases that can also respect the world around us.

P.S. I want to note, I was purposely vague about the first incident because the specifics weren’t important and I did not want to draw more attention to a specific person without their permission. In Cathrine’s case, I made a point of respecting her and exchanged messages with her first to make sure she was ok with me bringing more attention to the incident.

2020 in Preview

Ok, time for the obligatory dad joke: I can’t see what’s coming in the next year, I genuinely do not have 20/20 vision!

But I suppose my vision looking back was better. So I will try to prognosticate for the coming year and set some goals. I said last year I’m not a fan of New Year’s Resolutions, but I suppose I may have to reassess that claim as this is the second year in a row I’ve gone out on a limb and set goals, and what are goals if not a form of a resolution?

  • I’m going to continue to blog at least once a week. While I hope my readers get something out of it, I also blog for my own personal reasons: it helps me keep my writing and creative juices flowing. If years ago you told me I would have written a book and was blogging I’d have laughed and not believed it. I also would have wondered what blogging was!
  • Related to that, I will continue to writing for Red-Gate. This is a bit different from my blogging. It’s far more technical in nature which requires more effort. Since I’ve set aside an hour a week (and in fact my calendar just reminded me it was time for that hour) I’ve found I’ve been more productive. It’s in part why I wrote 5 articles last year and got 4 published. All so far have been on PowerShell. Generally my approach as been either, “here is a problem I had at a client and how I solved it with PowerShell” or lately it’s been a bit more of “hey, here’s a challenge, let’s see how to do it in PowerShell.” The best example of this last year was my article on using PowerShell to create a countdown timer with a GUI. It’s perhaps not the most productive way to do it, I think other languages and approaches would be easier, but it was a fun challenge and I learned a lot.
  • Extended Events! Or as Grant Fritchey would say #TeamExEvents! I’m a proud member and my goal is to learn more about them and to write more about them this year. It’s just a question of how much. But I’m a convert and a definite fan!
  • Read more blogs on a regular basis. I sporadically read Grant’s and also Monica Rathbun’s and would recommend both. I also sometimes read Cathrine Wilhemsen’s and she’s recently been on a tear with her guide to Azure Data Factories. I’ll admit I haven’t worked with it, but 25 posts in 25 days is an incredible feat and she’s great and knowledgeable on the topic, so I can highly recommend it in any event. I also want to add a few non-technical blogs to the mix. We’ll see.
  • Keep speaking at SQL Saturdays. I have yet to put in for any, but I will. Perhaps I’ll be visiting a city near you!
  • Create a couple of new topics to speak on. I’ve suggested a collaboration with someone and now I have to get off my butt and put together notes and see if they’re still willing to speak with lil’ ol’ me.
  • Speak at SQL Summit. This is an ongoing goal. Someday I’ll achieve it.
  • Have a successful NCRC Weeklong Cave Rescue Seminar here in NY. I’m the site coordinator for it this  year. I’ve got a great team backing me up, but as they say, the “Buck Stops Here”.  Registration is looking great, but until I get hit my goals, I’ll be stressing.
  • Read more! – I received several books for the holidays, including:
    • The Power Broker, I biography of Robert Moses
    • Station Eleven, a fiction  book (and if you’re the one that recommended it to me, please remind me who you are so I can thank you.)
    • Headstrong, 52 Women Who Changed Science and the World

And finally some rather generic goals

  • Love more!
  • Cave more!
  • Hike more!
  • Bike more!
  • Travel!
  • Vote the bastard out!
  • Have fun!

And I’ll conclude with one more dad joke because… that’s the way I roll!

When does a joke become a dad joke?

When it becomes a-parent.

Hey, don’t blame me if you groaned. I warned you it was coming!

Have a great New Year!

2019 in Review

Last year I did a review of 2018 and then the next day I did a post of plans for 2019. I figured I would take time to look back on 2019 and see how well I did on some of my goals and then perhaps tomorrow set goals for 2020.

One of my first goals always is to make one more revolution around the Sun. I can safely say I successfully achieved that.

But what else? I vowed to blog once a week. I did miss a few this year, but pretty much succeeded on that one. But, perhaps those misses where why I failed to break 2000 page views for 2019. That said, I don’t feel too bad. In 2018, I had one particular post in 2018 that sort of went viral, and that alone really accounts for the higher number in 2018. So if I ignore that outlier, I did as well or better for 2019. That said, I think I’ll set a goal of 2020 page views for 2020. It’s a nice symmetry.

I’ve continued to speak at SQL Saturdays in 2019 and will do so in 2020. Still working on additional topics and may hint at one tomorrow.

But I again failed to get selected to speak at SQL Summit itself. That said, I was proud to again speak at the User Group Leadership meeting this year. My topic was on moving the needle and challenging user group leaders to bring more diversity to their selection of speakers (with a focus on more women, but that shouldn’t be the only focus).  It was mostly well received, but I could tell at least a few folks weren’t comfortable with the topic. I was ok with that.

I set a goal of at least 3  more articles for Redgate’s Simple Talk.  I’m pleased to say I not only succeeded, but exceeded that with 4 articles published. It would have been 5, but time conspired against that. That said, I should have another article coming out next month.

I never did take time to learn more about containers.

I continue to teach cave rescue.

I think I caved more.

I didn’t hike more, alas.

And there were a few personal goals I not only met, but I exceeded. And one or two I failed it.

But, I definitely succeeded at my last goal, having fun. 2019 was a great year in many ways and I spent much of it surrounded with friends and family. For reasons I can’t quite put my finger on, I think I enjoyed SQL Summit this year far more than previous years. It really was like spending time with family.

I’ve been blessed with great friends and family and 2019 just reminded me of that more than ever.  Thank you to everyone who brought positive contributions to my life in 2019. I appreciate it.

 

52

52 is an interesting number.  It’s the number of weeks in the year. It’s the number of cards in a deck. It’s a number of Earths in the DC Multiverse. It’s an untouchable number, something I just learned. It’s the atomic number of tellurium. In fact it has a number of interesting trivia associated with it according to Wikipedia: 52.

It also just happens to be the number of times I’ve been around the Sun, though strictly speaking that depends if you’re counting sidereal or the tropical year and the fact that I was born at night. But I think we’re close enough.

And it just so happens my birthday falls on the day I usually blog. So rather than something technical (though if I can get permission from a client, I may have something fun and technical soon) I thought I’d post some reflections and thoughts.

For me birthdays are both interesting and boring. I’m glad I’ve reached another milestone. But honestly, after age 25 when my car insurance rates went down, I haven’t given individual birthdays much thought. That’s not strictly true, I sometimes think about the fact that I’ve passed the point where statistically I’m looking at fewer days ahead of me than behind me.

I grew up in a small town, Falls Village CT, and parts of me never have left it. When I stop to daydream, my thoughts take me to the town green where we often played, or the woods behind my dad’s house, or the sand quarry behind the depot I grew up in. It was a safe and quiet life. I watched the world move from bell-bottoms to Reagan power ties.

While just a teenager, I and friends ran not one, but two Monopoly marathons to raise money for the Muscular Dystrophy Association. The first year we played for 100 hours (in teams) and the second 150 hours. I was and am still quite proud of the organization that took and the money we raised.

Since then I’ve done a lot.  I got thinking about that last night at the Capital Area SQL Server User Group meeting. I’m proud to lead this group.  I really enjoy, as I’ve noted before, giving back to the community that has helped me so much.

I’m proud to be a Regional Coordinator for the National Cave Rescue Commission. I can literally say the work the NCRC does saves lives. It’s an honor and humbling when folks come up to me and tell me how their training has made a difference in the lives.

I’m proud of much of what I’ve done in as my avocations and vocations, even if at times I’m often a victim of imposter syndrome. There’s still many times when someone will ask me a question and my first thought is, “why are they asking me, I’m just a kid and… oh wait… no I am the expert here and I’m far from being a kid.”  This is especially true when people I look up turn around and ask me for advice.  This happens a lot in the SQL world.

I’m very proud of my family, especially my son and daughter who are growing up to be wonderful adults, capable of critical and deep thinking. They will make an impact on the world and I don’t think as a parent I could want for anything more.

And of course proud of my wife, but I can’t take credit there, she’s a wonderful person in her own right. I just married well.

One common thread I’ve realized in my life that I enjoy is teaching and sharing my knowledge. I also, as anyone knows me, love a good debate.  Bring your facts to the table. Teach me something, change my mind, or be willing to have yours changed. I still recall a debate I had with someone once about a detail of the Constitution. She made one claim, I made another. We finally settled it by finding a copy of the text and realizing who was right. Afterwards there was no rancor or hurt. We both had appreciated the intellectual exercise and the correction of fact.  But even opinions can at times be changed. At Summit I had two pieces of white chocolate from New Zealand. They changed my mind about white chocolate! I enjoyed them.

People often ask me what I want for my birthday and the truth is, I rarely want material things. Honestly, unless it’s a new Tesla (and NOT the truck) I can and will probably buy it for myself.

But here goes:

  • Another 52 years – hey, why not? We’re making medical breakthroughs, and it’s possible I’m wrong and I’ve got more days ahead of me than behind me. Right now, I’d love that.
  • Learn something – challenge yourself in the next year to learn a new skill or a new topic. Don’t get stuck doing the same things all the time.  Earlier this year I finally took the time to start learning about Extended Events. Who knows what I’ll learn in this coming year.
  • Teach someone something – everyone one of you has a skill someone else doesn’t. Share.
  • Related to that: if you’re a caver, or have a friend or family member who is a caver, get them to take the 2020 National Cave Rescue Seminar.
  • Have a friendly debate with someone. Realize it’s not about winning or losing, but an exchange of ideas. Bring your facts to the table and recognize your opinions. Be open-minded.  Be prepared to say, “You know what, you’re right, I was wrong.” This is not losing a debate.  And be prepared to acknowledge someone saying the above to you. Accept the words graciously, don’t lord it over them. This is not about winning a debate.
  • Be kind.  If nothing else in the coming year, be kind.

And that’s it for turning 52.

P.S. Unrelated, but check out my latest article at Redgate’s Simple-talk: Building a Countdown Timer with PowerShell

Kids, get off my lawn!

Change can be hard. But sometimes it’s necessary. And a lot has happened this week.  First, I want to congratulate my fellow #SQLFamily member Cathrine Wihlemsen on one more orbit of the Sun. Apparently, in her honor Microsoft decided to release SQL Server 2019 on her birthday! I’ve been using SQL Server since the 4.21a days. Every version has had new features and required learning something new. As I said recently, it’s easy to fall into the trap of being an old dog and not learning new tricks. This is something we have to avoid. Being trapped in the past can be limiting.

Besides SQL Server 2019 dropping this week, I recently upgraded my phone. I had been using a Windows Phone for about 5 years now. I loved it. Especially when it first came out, it was top of the line and had a bright future. I eagerly downloaded apps and it became part of my life. But alas, we know how well Microsoft did in the Windows Phone market. But I doggedly held on, even as features were deprecated. I couldn’t use the Weather App. The Amtrak App went away. Eventually several features of Cortana stopped work as Microsoft stopped supporting them. Slowly my phone was becoming a brick. I kept debating do I upgrade to one more Windows Phone knowing it’s the end of the line, or what? I kept putting off the decision. After the mapping function failed me on my recent trip to the Hampton Roads User Group Meeting I decided it was time to finally time to replace it with an Android phone. Choosing from the plethora out there was not fun. It was very tempting to go with one of the top of the line models, but spending $1000 or so wasn’t really a fun idea.  I eventually ended up choosing a Samsung A50.

I’m mostly happy with it. Right now I’m struggling with what parts of it are “get off my lawn” because I don’t like change, and what parts are “what the hell is the UI doing now?”  Fortunately, my son has mentioned some of his dislike of certain UI functionalities, so I think not all of it is me simply being an old curmudgeon (are there young ones?) I will say what I’m most happy with is that Microsoft has a number of tools including the Windows Launcher and the Phone Companion, as well as the obvious apps like Outlook and other parts office.

A word about the Phone Companion. This alone has made the upgrade a win. One of the features is that when I’m working at home (I have not yet enabled it on my Surface Pro) is that things like text messages pop-up on my desktop screen. This actually makes life a LOT easier, since I can simply type a reply from a full-size keyboard or copy the numerous soft-tokens I get to log into various client sites without having to pick up my phone. It’s a small detail, but a wonderful one!

The Launcher helps me retain some of the features that I liked about my Windows Phone. Overall, it’s a win.

But the changes in my life aren’t complete. As I mentioned last week I’m at PASS Summit again this week in Seattle. But alas, this is the last year that PASS Summit will be in Seattle. Next year it will be held in Houston. Just as I’ve figured out where the cheapest and most convenient parking for me is, where some decent food places are, and I’m feeling, if not at home in Seattle, at least comfortable, next year is a big change. I won’t be able to stay with my college friends or do our annual Thai pot luck with a bunch of ROC Alumns.

But, I’ll get to explore another city. I’ve been to Houston only once, literally decades ago, to do SQL Server install at Exxon. The server was literally the only Intel computer in a room full of mainframe equipment. I suspect that has changed since then.  That was one of my early experiences installing SQL Server (4.21a for the record).

So, this old dog is still learning and looking forward to new experiences: plus ça change, plus c’est la même chose.

 

He’s dying Jim!

Less than a minute after the mountain biker blew by me on the trail I heard the wail. It was scary. I raced forward with my hiking partner and very quickly came upon the accident scene. Thomas was laying in a crumpled mess, his $1500 mountain bike further down the trail with one more bend in the frame than the manufacturer had created it with.  This didn’t look good.

The hillside was steep and Thomas was on his side. I dropped my pack and went to backside of Thomas. Quickly my training kicked in. I introduced myself and asked him his name. His response re-assured me. He was breathing and had a pulse. And in medical terms, he appeared to be alert and oriented times three.

I put on my gloves (yes, I do carry nitrile or latex or material gloves pretty much anyplace I go, you should too!)  I then moved to his backside and palpated his head. So far, so good. No blood or cerebral-spinal fluid.  Since he was on his side, it was an ideal (if one could call his situation that) position for me to check his spine. Working down, so far so good until I got to the top of his lumbar portion. There I felt something very wrong.  Ok, shit just got real.  Upper torso, so far so good. Lower torso, right side, a reaction to pain. Barely noticeable, but definitely some mass internally. Again, not good. I continued down his legs. I got to his feet and normally I’d have saved this for the secondary survey, but since I already had a bad feeling and this wouldn’t take very long, I asked him to press his toes against my hands like he was pressing the gas. Nothing. I asked him to pull up his toes, again nothing.  This was not good. Same lack of reaction on the other side.  I could hear the panic in his voice, “why I can’t I move my legs?”

In all my past training they always taught us, “never lie to the patient. But also remember you’re not a doctor.” So I was honest. “Look, it could be a lot of things. I’m not a doctor so I don’t want to speculate. We’ll leave that to the professionals.” But deep down I knew. Bad tumble off a bike, bad position of a lumbar vertebra, and lack of sensation distal to that all added up to some sort of spinal injury. Would it be permanent, I had no idea.

I also checked his right arm since it was immediately available and this time came up with blood and point pain over the radius/ulna.  This matched what the accident most likely was.  He had hit a rock or something and wrapped his right side around a tree, breaking his arm, damaging his spine and most likely causing internal bleeding.

But I still had the left side to check.

With my partner’s help, we got a ground pad behind him and then rolled him very gently onto it. It’s always a risk moving a patient with apparent trauma like this but we needed to get him isolated from the could ground which was stealing his body heat and I needed to check for injuries on the left side.

Fortunately, this was the only bright news. A thorough check of his left side showed no apparent trauma. But, his shivering was getting worse and his mental state was decomposing. Whereas he was had previously been alert and oriented to who he was, where he was and approximately the time, now he kept asking the time.  Taking a set of vitals, things were not what one would like to get.

My partner was writing down all this information and giving me gear as needed. We had gotten the groundpad under him and clothing on top, but we needed to do more.  At this point, since we confirmed he wasn’t about to bleed out, we worked on splinting his arm. Providing traction in-line proved to be a bit painful at first, but ultimately gave him some pain relief and temporarily solved that particular issue. We did as much as we could in the back-country.

I took another set of vitals, and the numbers were a wee bit worse. In addition, Thomas was now wondering where he was. I repalpated his lower right abdomen and got an increased pain response and the firm area was larger. This was a very worrying sign.

While doing this, my partner ran down the trail with a copy of his notes until he got cell service and called 911. He gave them the details and then came back.  At this point, with his help we decided to get Thomas into a bivy sack to help keep him warm.  This took some effort since Thomas was bigger than either of us, fairly muscular and we were doing out best to protect his spine. But eventually we got it around him. Between this and some liquid “squirt” we were able to give him, his pending hypothermia appeared to stabilize and eventually improve.

But his vitals continued to degrade and the pain and mass in lower right his abdomen continued to get worse. He was dying and there was nothing I could do about it.

Well there was one thing I could do. I looked at Thomas and said, “well I think that’s it. Did I miss anything or do you think we got this exercise covered?”

He looked up and smiled, “Nope, I think you got it.  By the way, the biv sack really did help a lot. I was actually starting to get cold for real.” We removed the biv sack and he remarked, “Wow, you really did have a lot of warm stuff on me.”

Now, fortunately, all this had been an exercise, part of a SOLO Wilderness First Aid class I was taking over the weekend in order to renew my certificate.  The scenario was completely made up. But, I have to say, the feeling of helplessness was real.

Strangely though I’d say that was a good thing. For any skill we want to maintain competency in, we need to practice. Fortunately, I haven’t come across a crumpled mountain biker and most if not all back-country medical emergencies I’ve encountered have basically been fairly simple (an abrasion here, a blister there, or most commonly, mild hypothermia). But, continual practice does help. When arriving at the staged scene, I knew what I wanted to do and I knew how I wanted to do it and how to do it. The years of training and practice came back very easily. I knew how to do a primary survey and what I wanted to look for. I knew what vitals I needed and what trends I wanted.  There wasn’t much searching for knowledge, it bubbled up as needed. Practice really does in a sense “make perfect.”

And, even knowing that my mock patient most likely had internal bleeding that was leading to hypovolemic shock was good to know. Knowing that there was very little I could do if this was a for-real in the back-country was scary, but also strangely reassuring. I was confident that I had done all that I could reasonably do. And sometimes that may have to be enough.

I’ve talked previously about training as one fights. This should be true in any situation you may find yourself in: caving, the back-country, or even something as mundane as being a DBA. When’s the last time you practiced restoring a backup or doing a failover test?

Practice may or may not make perfect, but it does provide confidence.

P.S. if you’re in the Hampton Roads area tomorrow night (October 16th) come check me out speaking on System Databases at the Hampton Roads SQL Server User Group. Rumor has it, they’re serving wings!

Caving along the Great Divide

The title is a rife on a favorite folk song of mine, “Railroading on the Great Divide”, apparently first made famous by the amazing Carter Family. In this case, the Great Divide is a feature of a local cave known as Knox Cave in the town of Knox NY.

So, what do you get when you take 2 Canadians, a number of students who are just starting in college and a pair of cavers who have been caving for over 50 years each, two medical students, a fire chief, and a mixture of other people and toss them into a classroom and then a cave? You get an excellent teaching and learning experience.

I again had the privilege of working with a great group of people teaching a 2 day class on cave rescue. On the first day we test the students patience by seeing how many Powerpoint slides they can sit through. If they successfully survive that, we then unlock the doors to the classroom and let them outside. We then do some patient packaging and patient movement.  We end the day with a large quantity of food.

Often I’ll spend the Saturday night at the fire house (our typical location for these classes) but this time I had to head home. On the way one of my fellow instructors texted me to let me know that the student who was staying with her had not arrived at her house. We started to worry.  About an hour later the missing caver had shown up. Turns out she and several other students had decided to take advantage of a baseball backstop and practice their SRT skills and spend some time teaching each other. Even after a long day of teaching, the students were still eager to share their skills with each other.

On Sunday, we spend less than 1/2 an hour in the classroom, essentially just enough time to grab some breakfast and handle some housekeeping chores. We then start a practice rescue. In this case it was at nearby Knox Cave. While the students had known that the practice would be at Knox, they had no idea what the actual would actually involve.  So when the first group showed up, including the local fire chief who was also part of our training, they sprang into action. The reporting party told them that two cavers were in the cave. Both were at the Great Divide, one with a broken leg, the other taking care of the injured caver.

Very quickly the students found the the injured caver but quickly learned that no plan survives the first encounter with reality; the non-injured caver had wandered off and they had to go find her.  The apparently simple rescue had now become a search problem.

After a few missteps, the students found the missing caver and assisted her to the surface. And shortly later the injured caver was also brought to the surface.  It was a successful practice.

At the end of the weekend, instead of 22 students with very little if any cave rescue experience (including at least one student who had never been in a wild cave before) we now had 22 students who had gained a bit of experience and I would actually trust to call if a real rescue was called. From the reports I got back, everyone had fun and more than one person is now very eager to take our weeklong class next year!

For me, it was a long weekend with not enough sleep, but I ended it more energized than I started it. This is typical when I teach courses like this. It’s because I love the aha moment students often have when they’re learning, and this weekend was full of those.

I’ve been blessed to be surrounded by great groups of people over the years and I must say my cave rescue family is among the best, and I’m proud to welcome even more members to that family.

P.S. Don’t forget to check out my latest article at Redgate’s Simple Talk: How to Use Parameters in PowerShell