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.

Brake (sic) it to Fix it!

Last week I wrote about getting my brakes fixed. Turns out I made the right choice, besides shoes and pads, I needed new calipers.  Replacing them was a bigger job than I would have wanted to deal with. Of course it cost a bit more than I preferred, but I figure being able to make my car stop is a good thing. I had actually suspected I’d need new calipers because one of the signs of my brakes needing to be replaced was the terrible grinding and shrieking sound my left front brake was making. That’s never a good sign.

As a result I started to try to brake less if I could help it. And I cringed a bit every time I did brake. It became very much a Pavlovian response.

About two weeks ago, a colleague of mine said, “Hey, did you notice the number of errors for that process went way up?” I had to admit, nope, I had not. I had stopped looking at the emails in detail. They were for an ETL process that I had written well over a year ago. About 6 months ago, due to new, and bad, data being put into the source system, the ETL started to have about a half dozen rows it couldn’t process.  As designed, it sent out an email to the critical parties and I received copies.  We talked about the errors and decided that they weren’t worth tracking down at the time.  I objected because I figure if you have an error, you really should fix it. But I got outvoted and figured it wasn’t my concern at that point. As a result, we simply accepted that we’d get an email every morning with a list of rows in error.

But, as my colleague pointed out, about 3 months ago, the number of errors had gone up. This time it wasn’t about a half dozen, it was close to 300. And no one had noticed.  We had become so used to the error emails, our Pavlovian response was to ignore them.

But, this number was too large to ignore. I ended up doing two things. The first, and one I could deploy without jumping through hoops was to update the error email. Instead of simply showing the rows of errors, it now included a query that placed a table at the top that showed how many errors and in which tables. This was much more effective because now a single glance can easily show if the number of errors has increased or gone down (if we get no email that means we’ve eliminated all the errors, the ultimate goal in my mind.)

I was able to track down the bulk of the 300 new errors to a data dictionary disagreement (everyone raise their hands who has had a customer tell you one thing about data only to discover that really the details are different) that popped up when a large amount of new data was added to the source system.

I’ve since deployed that change to the DEV environment and now that we’re out of the end of the month code freeze for this particular product, will be deploying to production this week.

Hopefully though the parties that really care about the data will then start paying attention to the new email and squawking when they see a change in the number of bad rows.

In the meantime, it’s going to take me awhile to stop cringing every time I press my brakes. They no longer make any bad sounds and I like that, but I’m not used to to absence of grinding noises again.  Yet. In both cases, I and my client had accepted the normalization of deviance and internalized it.

I wrote most of this post in my head last week while remembering some other past events that are in part related to the same concept.  As a result this post is dedicated to the 17 American Astronauts who have perished directly in the service of the space program (not to diminish the loss of the others who died in other ways).

  • Apollo 1 – January 27th, 1967
  • Challenger – STS-51L – January 28th, 1986
  • Columbia – STS-107 – Launch January 16th, 2003, break-up, February 1st, 2003.

 

 

Them’s the brakes…

I need brake work done on my car.  I scheduled an appointment with my mechanic for Thursday.

Now normally brake work might not be worth writing about, but this time it got me thinking. About 9 years ago I taught myself to change the brakes on my Subaru. It wasn’t that hard, but it definitely took longer than I would have liked. I’ve learned how to do it much faster since then.

Back then I did it because I was between jobs and had more time than money. It made sense at the time. Since then I’ve generally continued to do them myself. It doesn’t take long and as I’ve said in the past, sometimes I like working with my hands. It reminds me not all of life is simply databases and servers.

So why this time? The simple answer is, my garage floor is cold!  Ayup, it’s a funny thing, but in the winter, things get cold! And honestly, I just don’t feel like sitting/laying on the concrete while I do the work. So, I’ll pay an expert who can pop it up on a lift and do the work in probably half the time I can.  I remind myself it’s why I work, so I can pay others to do work I don’t care to do, or that they can do better than I can.

Years back, at my last job as the Director, and later VP of IT, I changed our email provider from one company to another (don’t ask me who they were, I can’t recall over a decade later).  My team didn’t like this. They kept insisting they could run the mail servers themselves. I had no doubt that they could. Running an Exchange server isn’t the most difficult thing in the world. That said, I kept saying no.  For a simple reason: “we weren’t an email company!” Providing reliable email for a business like we were meant at the very least strong spam protection and of course high-availability with ideally geographic redundancy. This meant at least two Exchange servers, spam filters and more. This alone would have cost more than what we paid annually. Now add in the time my team would have spent on email issues, it just wasn’t going to be worth it.

And, we’re seeing that more and more with services such as Azure. Sure, many businesses run change their own brakes, err, run their own SQL Server. But more and more are outsourcing to platforms such as Azure. But there are still a number of companies that for various reasons don’t do that. Fortunately for them, there are consultants like me to help them with their servers. SQL Server has always been easier to maintain than some of its competition, especially when it was first available. But that has never meant it needed no intervention. Someone still needs to make sure that jobs are being run, that backups are available and more.

So, some days I change my own brakes because it’s fun and easy, some days I pay someone.  Some days my clients handle their own SQL Server issues, and other days, they pay me.

No real revelation here. No real advice on when to draw the line on outsourcing, just an observation. But in my case, my concrete is too cold, so I’ll pay someone else to do the dirty work.

Fixing a “Simple” Leak

I was reminded of the 80/20 rule yesterday as I was briefing my team on a project I needed them to work on.  Ok, actually I was telling my kids about this, but it was still for a project.

In this case, I was pointing out that 80% of the effort for a project often is used on completing only 20% of the project. Researching this a bit further, there’s an actual name for this rule: the Pareto Principle. We’ve probably all come across this rule or some variation of it in our lives.

While not exactly the situation here, the point I was trying to make with them is that sometimes when fixing a simple problem, the issues and work that spin off easily take 10 times as much time and effort as the original problem.

In this specific case, I was asking them to do what was essentially an annoying and dirty job, clean up some edges to sheetrock before I finally re-enclosed a portion of the basement ceiling. They started later in the day than I would have preferred, but honestly, as this project has been sitting on hold for a few months, a couple more hours didn’t really matter. That said, I think the actual work took them longer than they thought it would.

So what prompted yesterday’s work was a small leak that I fixed over a year ago.

Over the years, we had noticed a slight leak in the downstairs bathroom. It wasn’t always apparent, but it was slowly getting worse. Essentially water was soaking into the sheetrock and walls of the finished portion of our basement.

Now, I’m a fairly handy guy, I spent several summers in high school and a bit of college working for my father in the construction trade. While he’d point out my finish work needed more work, in general, if it’s involved in residential construction, I’ve done it and I can feel comfortable doing it. But, besides learning how to use the tools, I also learned an important lesson: no project is ever as simple as it appears. This is actually one reason I hate starting home-improvement projects. I know that it’s going to turn into a lot more work than it originally looks like. It isn’t exactly the 80/20 rule, but I’m reminded of it. So let me dive a bit into what was and still is involved in fixing this simple leak.

First, I had to identify where it was.  From lots of inspection, guesswork and experience, I guessed in the wall behind the tiles.  Ok, so that means, rip out the tiles and the plaster and lathe underneath.  That’s simple enough, and honestly fun, albeit it dusty.

Second, once the leak was found, replace the plumbing.  With modern Pex plumbing, that’s actually the quickest part of the work. So yes, actually FIXING the leak, took maybe an hour. I will note I also took the opportunity to move the showerhead up by about 9″. One thing I hate are low showerheads!

WP_20181223_001

New Pex plumbing to showerhead

But, hey, while I’m in here, I might as well run the wiring for a fan for the bathroom because it’s always needed one.  And given a weird quirk of construction in this house, the easiest way is to run it into the long wall of the bathtub/shower, then over to the outside wall and then up to the approximate location of where the fan will go.  So there’s another hour or two for a project to was started to fix a leak.

Oh and while I’m at it, let me take some photos with a tape measure in them of where the pipes are for future reference. So there’s a bit more work.

Great, the leak is fixed.

Except, obviously the shower can’t be used as is with open walls. So now it’s a matter of getting backerboard and putting that in, and sealing it.  What I used is waterproof as it is, so we left it at that. And I say we, because for much of this product both the kids were helping with it. And quite honestly, that’s where this part of the  project sat for months. The shower was usable, though a bit ugly.

But, we still had the basement to deal with. That meant ripping out the damaged sheetrock and studs that had rotted. That was fun. Not! For that I actually used a full respirator, body suit, and sprayed anti-fungal stuff liberally. Some of the water damage here was actually older than the bathroom leak and was due to poor grading and then more recently, runoff from the roof of my addition (a problem that gutters finally solved).

But hey, if we’re putting in new walls, might as well put in better insulation and if we can seal the old concrete (hint that went poorly) and oh, put in a couple of dimmable lights for a work area and some network jacks.

WP_20190106_001

Basement wall in progress

Once that was all roughed in, it was time to at least sheetrock the walls.

WP_20190106_004

Sheetrocked walls

And that is basically where the basement project sat until yesterday. I’ll come back to that in a minute.

As for the bathroom, there was only so long I wanted to look at the backerboard. It was time to finally tile it.  Oh, but before I could do that, I had to put that fan in. Besides finding just enough room in the outside wall between the framing for the 2nd floor and the window and other vagaries, it just fit. Of course that was just 1/2 the battle. The other 1/2 was then wiring up the switch. Oh and while I’m at it, might as well run a circuit for a GFCI outlet since the bathroom was lacking one.  Once all that was done, THEN, I could tile.

WP_20190804_001

Tiled and Grouted

And yes, you may note the window does intrude into the shower space. Hey, I didn’t build the house!  What you can’t see is the replaced trim on the top edge and left edge of the tile that my daughter literally spent hours sanding and resealing. It looks great.

Oh and I still have to find replacement cones for behind the handles! So that’s another thing to do for the project.

But back to the basement. The area in front of the wall has become my son’s de facto computer space when he’s home from college. It was ‘good enough’.  But the ceiling still needed its sheetrock replaced and I needed to tape and paint the new wall.  This has waited until now.

The problem with the ceiling is when I pulled down the old stuff, I didn’t have nice clean edges to butt the new sheetrock against.  It was ragged where it had broken, or broke at awkward places so I couldn’t easily put in new sheetrock.

But I also took advantage of this time to reroute all my network drops so they will be hidden in the ceiling and come out nicely to my rack.

So yesterday, the kids did the dirty work of trimming the edges, cleaning stuff up, etc. It looks great and will make my job of sheetrocking much easier.

20200121_081823

Open basement ceiling

By the way, I should note that the board you see sticking out is what I had used in the past when I had to slide in here to do some wiring or other work. This was sort of my own private Jefferies Tube. This should now be relatively easy to sheetrock, right?

Well, except for one small detail.

20200121_081837

Houston, we have a problem.

Yes, that is a piece of electrical cable that was run OUTSIDE the studs and essentially between the join of where two pieces of sheetrock met at an inside corner.  I absolutely HAVE to move this before I can sheetrock.

So that’s going to be a few more hours of work before I can even start to sheetrock. I have to identify which circuit this is, cut power, cut the wire, reroute it, put the ends in a junction box (which code says can’t be hidden!) and then make sure it’s safe.

After all that work, I can finally get around to sheetrocking the ceiling. Then I’ll have to mud and tape all the joints, sand, mud again, prime and then finally get the walls and ceiling painted.

But the good news is, the leak is fixed. That was the easy party!

Does this “simple” project of fixing a leak remind you of any projects at work? It does for me!

How Much We Know

Last night I had the privilege of introducing Grant Fritchey  as our speaker to our local user group. He works for Redgate who was a sponsor. The topic was on 10 Steps Towards Global Data Compliance.  Between that and a discussion I had with several members during the informal food portion of our meeting I was reminded me of something that’s been on my mind for awhile.

As I’ve mentioned in the past, I’ve worked with SQL Server since the 4.21a days. In other words, I’ve worked with SQL Server for a very long time. As a result, I recall when SQL Server was just a database engine. There was a lot to it, but I think it was safe to say that one could justifiably consider themselves an expert in it with a sufficient amount of effort. And as a DBA, our jobs were fairly simple: tune a query here, setup an index update job there, do a restore from backups once in awhile. It wasn’t hard but there was definitely enough to keep a DBA busy.

But, things have changed.  Yes, I still get called upon to tune a query now and then. Perhaps I making sure stats are updated instead of rerunning an index rebuild, and I still get called upon to restore a database now and then. But, now my job includes so much more. Yesterday I was writing a PowerShell script for a client. This script calls an SFTP server, downloads a file, unzips it and then calls a DTSX package to load it into the database.  So now I’m expected to know enough PowerShell to get around. I need to know enough SSIS to write some simple ETL packages. And the reason I was rewriting the PowerShell script was to make it more robust and easier to deploy so that when I build out the DR box for this client, I can more easily drop it in place and maintain it going forward.  Oh, did I mention that we’re looking at setting up an Availability Group using an asynchronous replica in a different data center? And I should mention before we even build that out, I need to consult with the VMWare team to get a couple of quick and dirty VMs setup so I can do some testing.

And that was just Monday.  Today with another client I need to check out the latest build of their application, deploy a new stored procedure, and go over testing it with their main user. Oh, and call another potential client about some possible work with them. And tomorrow, I’ll be putting the finishing touches on another PowerShell article.

So what does this have to do with last night’s meeting on Global Data Compliance? Grant made a point that in a sense Data Compliance (global or otherwise) is a business problem. But guess who will get charged with solving it, or at least portions of it?  Us DBAs.

As I started out saying, years ago it was relatively easy to be an expert in SQL Server. It was basically a single product and the lines tended to be fairly distinct and well drawn between it and other work. Today though, it’s no longer just a database engine. Microsoft correctly calls it a data platform.  Even PASS has gone from being an acronym for Professional Association of SQL Server to simply PASS.

Oh, there are still definitely experts in specific areas of of the Microsoft Data Platform, but I’d say they’re probably more rare now than before.  Many of us are generalists.

I mentioned above too that I’d probably be more likely to update stats than an index these days.  And while I still deal with backups, even just the change to having compression has made that less onerous as I worry less about disk space, network speed and the like. In many ways, the more mundane tasks of SQL Server have become automated or at least simpler and take up less of my time. But that’s not a problem for me, I’m busier than ever.

So, long gone are the days where knowing how to install SQL Server and run a few queries is sufficient. If one wants to work in the data platform, one has to up their game. And personally, I think that’s a good thing. What do you think? How has your job changed over the past decade or more. I’d love to hear your input.

A Good Guy

I wrote previously about the dangers of calling yourself an ally. Two completely unrelated incidents in the last week reminded me of that post. Both on their own are rather small items, but I think worth considering.

The first basically happened to a friend at a recent rally in NYC to support the Jewish community. Apparently a young non-Jewish woman accosted an elderly Jewish immigrant at the march for comments he had made about the goal or purpose of the rally. Or to put it another way, a non-Jewish person was telling a Jewish person that the way he was expressing his support for Judaism was wrong. Let that sink in for a minute. Now, to be fair, as a my Jewish friend commented, the young woman’s comments weren’t necessarily technically wrong, but they were out of place.

In the second incident, I replied to a comment a friend had made on Twitter. In reaction she sent me a pair of emojis that equated to, “seriously?” I was confused at first because my tweet had been intended to agree with and support her observation. However, because, as she put it, “I was one of the good guys” she wanted to explain how my reply could be perceived as a form of mansplaining. She realized I hadn’t intentionally tried to overshadow her comments or to be rude. She would have had no problem calling me out in public had that been the case. Instead, she took the time to privately explain to me why what I had done was problematic. I ended up, despite her saying it was unnecessary, removing my tweet because I was no longer comfortable with it. I realized were better ways of I could have replied.

The point of my two examples isn’t to say that the young woman was a bad person, or to self-flagellate myself. The point is that even as a ally, one will make mistakes. This is in part because by not being an actual part of the group in question, one can’t fully internalize what it means to be part of that group and how comments and actions will impact members of that group. But, one can ideally still listen and learn. I appreciate that my friend took the time to explain to me why my tweet was problematic. She was under no obligation to do so. But I appreciate it.

That said, two other quick items: I want to toss a shout out to the South Florida BI SQL Saturday. One can’t go 100% based on names as to how one identifies, but the organizers have tweeted about how they managed to have a 50/50 balance of men and women presenting. It is definitely possible to do this folks.

Finally, a shoutout for my latest Redgate article on Comments and More in PowerShell. This was a fun one to write. I hope you enjoy it.

 

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!