Close to the Edge

I had initially decided I wasn’t going to say much about Simone Biles’ decision to drop out of my of her Olympic events, but then I realized, when I had started this blog, one of the things I wanted to focus on was how we make decisions and how our brains work at times.

But before I comment on Biles’ choice, I want to delve a bit into what we teach in our cave rescue training. We have a core 3 levels and much of our training involves rigging of ropes, patient packaging, and patient extraction. In other words, all hands on activities that require certain skills and training. A typical weeklong class will have over 80 hours of training. This means by the time a person completes the core levels, they will have spend over 240 hours in training.

But the thing is, many rescues don’t require any of that. I’ve done rescues where there was absolutely no rigging involved. But there is one component that is involved in all rescues, but we spend less than an hour on: psychological considerations. Every rescue involves at least two parties, the person being rescued, and the rescuer. And this means that their mental statuses are involved. Now, I’ll admit in perhaps the vast majority of rescues the mental status of the rescuee or the rescuer aren’t really issues or a problem, but they exist.

I bring this up because of two incidents that come to mind in my caving career, both that involve how our brains work, or more specifically in these cases, my brain. The first involves a body recovery and the second just a simple caving trip.

About 20 years ago we had an unfortunate incident where a local caver became trapped while underwater and drowned. Recovery operations already have a different feel and tempo than rescue operations. There’s generally very little urgency and you have to deal with family members and others who are struggling with the death of a loved one. The mood is far more somber. The death occurred on a Monday night. It wasn’t until Wednesday night that we were able to free Rob. I wasn’t in the cave when he was finally extricated. But the word came out that they needed people to help transport him to the surface. One of the folks in charge, a friend came to me and asked, “Greg, can you do this?” I had to stop and think. I appreciated that she was asking. I knew that “No” would be a perfectly fine answer and she wouldn’t think any less of me. Not everyone is psychologically equipped to deal with a dead body so close up, especially when it’s someone they know. An important part of what went into my decision was making sure I’d be a help to the team and not a burden. I didn’t want to freeze up or otherwise hinder things. I ultimately answered “Yes” because in part, I felt he should be accompanied by someone who knew him on his final journey to the surface and felt confident I wouldn’t slow things down.

The second incident was a simple caving trip. A friend and I were rigging the entrance to a pit known as Cemetery Pit. Our choice of rigging involved wrapping our rope around a large boulder and tying a figure 8 knot in it. Between the two of us we have tied a figure 8 knot 1000s of times. It’s our go-to knot for most things. Yet, because of the way the rope was laying around the rock, the angle of the one of the ropes forming the loop just didn’t look right to me. I was pretty confident I had it right, but when you’re about to rappel 150′ into a cave “pretty confident” really isn’t quite good enough. So I asked my buddy to take a look at it. He had the same reaction as me, “I think that’s right, but I’m not 100% sure. I’ll retie it.” He retied it and his results still didn’t look quite right. We both made a few attempts at it and each one didn’t quite look right. I believe we ended up tying something else that did look right and we had 100% confidence in. In retrospect, I’m suspect we had it right the first time (and subsequent times) but our brains suddenly had a case of the yips, or perhaps the caving version of the twisties

What do these have to do with Simone Biles? Two things: she was a team member who did the right thing, and who suffered from a sudden lack of confidence, or as they call it in gymnastics, the twisties.

I’m going to deal with the twisties first. Now, I haven’t done any gymnastics since grammar school, but I did have an incident once while diving/playing in the water that I suspect was similar. I had jumped off the diving board, probably doing a flip of some sort, and found myself tumbling underwater. This was an experience I normally enjoyed. I love the freedom water gives and twisting and gyrating underwater. But this time was different. When I stopped, I realized I had no idea which way was the surface. There was a moment of panic before I realized I still had enough air in my lungs that if I just waited I’d float to the surface. But I had for a moment lost my complete kinesthetic sense. I have to imagine this is similar what happened to Biles. In my case, the consequences was simply a moment of panic, then a simple wait to rise to the surface. In her case, having seen some of her moves and listening to some of the commentators, I’ve come to realize that in the case of a gymnast, such a loss can result in severe injury. This article illustrates several such examples. Similarly, if we had not been able to tie rigging we felt safe on, we might have aborted our trip because a mistake could be fatal. Sometimes our brains simply get into that state where up is down and left is right and it’s not simple to fix that. So, in that aspect, I think she made the right decision, as has any person caving (or in another activity) who has turned back because they’ve lost confidence in their rigging or skills. Better to be safe and come back another day than be sorry.

In terms of being a member of a team, she also made the right choice. She could have said, “Well I’m the GOAT, I’m going to compete no matter what” but because of her state of mind, probably not performed at her best and pulled back on some of her more extreme moves ( thus reducing her points totals) and very likely not won medals. But, by pulling out, and she opened up spots for other members of the team, such as Mykayla Skinner to step up. In a world where Biles had forced herself to compete, my guess is due to the twisties, she would not have medaled on the vault, and Skinner would have never had the chance to compete, which means the US would not have won Silver in the vault. Sometimes being a team player means stepping aside so others can do the job. In my case of the body recovery, had I not felt comfortable in my ability to carry out my task, I would have rightly stepped aside.

I have to give Simone Biles a lot of credit. The weight of the world, or at least the US was on her shoulders. She was expected to perform at levels that no one else has reached. She also knows that few gymnasts at her level compete late into their 20s. This may be her last Olympics. All the pressure was on her to compete. But had she done so, she risked serious injury and very well may have kept the US from winning as many gymnastic medals as they did. I respected her before, but I have to admit I have even more respect for her now. She really is the GOAT.

#YesAllMen

For over two years I’ve been wanting to put together a speaking topic using the above as a title or as a subtitle. The reason is because the alternative, #NotAllMen is NOT a good thing to use.

Yesterday I came across an article that said it better than I could. I would recommend you read it first: Buzzfeed Article.

It brings up several great points, including ones I had not given much thought to. Look, I know when a friend of yours is upset that a guy just made a pass at her in a professional setting, one of your first instincts is to think “I’d never do that” and are tempted to say “#notallmen” you’re not being helpful. In fact, you’ve just made it about yourself. Just don’t. That’s not what is needed.

Look, I’m pretty confident that all my male readers are pretty decent guys. I work with many of you professionally, some of you in volunteer positions, some are simply friends, and some readers, I suspect I don’t know, but you’re probably ok too. None of you are outright sexist or racist. If you were, I wouldn’t be associating with you. But all of us are still a product of our environments. We make the off-handed comment without thinking about it. Or someone around us makes a comment and we don’t react. This is also why I suggest when it comes to calling yourself an ally, just don’t.

Several years ago I helped organize and then participated in a Women in Tech panel for our local SQL Server User Group. I was the only man on the panel and expected to be asked what was the best thing I thought we, as men could do. The answer was of course somewhat ironic: “Sit down and shut up.” I of course expanded upon this. No, we can’t nor should we ever completely shut up. That wasn’t my point of course. My point was to make sure not to center the discussion about us. When a friend complains about a sexist incident, replying #NotAllMen is doing just that. Centering the discussion on us. Sorry, that’s a time to shut up and listen.

But when others make sexist comments, that’s a time when it may be appropriate to say something. And if someone calls you out, take it in stride. We make mistakes. And if someone takes you aside and says something (I’ve now heard that called a “call-in”) thank them. It means they think well enough of you to help you be a better person.

At the end of the day guys, we’re all still part of the problem, even when we do our best. That doesn’t make us evil. It simply means we have space to grow into. Let’s do that. Let’s grow.

… Other Duties as Assigned

I’ve mentioned once before that at one of my clients I describe my job as “DBA and other duties as assigned.”

This phrase has really been on my mind this week, especially during a phone call with another client yesterday. This second client is a local consulting company that has hired me a few times to back them with my skills in SQL Server and MS Access. This time around the work they’re looking for is definitely SQL Server related. It was refreshing.

But it reminded me of my last two weeks with two of my other clients. One is having an issue with their app (that they always call “the database”) that is most likely a design issue that I need to dig into. This is a perfect example of what I call “software archeology” where I at times have to shift through “pot shards” to determine what the original developer was thinking. At times it can be fun and interesting, at other times, frustrating. I’ll be shifting through more pot shards in the near future to get to the bottom of this problem.

For my largest client, I spent most of my hours with them last week trying to true up a file with some financial data in it. In this case it’s part of an ETL process where I receive data, compile it and send it to a vendor. The process uses a combination of PowerShell and Pentaho. So while they interact with the database, the work I was doing wasn’t in T-SQL or directly on the database server.

The numbers weren’t adding up. There was an undercurrent of “Greg, your numbers are wrong” or “You’re filtering on the wrong criteria.” I kept pointing out that “I simply add up the numbers you give me.” Eventually the problem was narrowed down to the fact that in the source system, which is the system of record, they had deleted rows. Arguably, one should never be deleting rows in such a system, but rather issuing a 2nd row (a credit if you want to reverse a debit, or a debit to reverse a credit) and this was typically what was done. But in this case the maintainers of the source of record decided to wholesale delete these rows. I explained that from day one, since deletions are never supposed to happen (and given the way the system works, extremely hard to detect) all I do is either insert new rows, or update existing rows. In any event, with one minor schema change, some updates to the rows in question and an updated PowerShell script, I was able to make the numbers come out to match with theirs. So, is that really DBA work? Not in the traditional sense. But it’s definitely other duties as assigned.

Now that’s not to say I didn’t do what some might consider actual DBA work. On Saturday morning I patched one of their servers. And at one point during the week, I deployed a script to production. So, out of 18 hours of work for the customer last week, I think I can say maybe 1-2 total was “dba work” or about 5%.

Now, I want to be clear. This is not a rant or a complaint. I’ll admit I tend to prefer to work directly with SQL Server, but I was reminded of a quick discussion I had with a fellow DBA over the weekend about how they probably needed to start to learn PowerShell for their job.

I’ve been arguing for years that the role of a DBA has changed, and will continue to change dramatically over the next few years. Once where we might spend days head down slinging T-SQL code, setting up backups and restores, tuning indices, etc. now much of that is automated or at least far easier to do. Which is a good thing. In years past, a DBA might be responsible for a dozen machines or so at the most. If it was more than that, we’d feel sorry for them. That’s no longer uniformly true. I know a DBA who is responsible for over 100 machines. They’re the soul DBA. But, through PowerShell and other modern tools, it’s generally not an overwhelming job.

However, like the online presentation from the Atlanta Azure Data User Group I attended last night on SQL Database Edge, there is a growing list of things DBAs need to learn. Steve Jones recently posted about whether DBAs need to learn Linux? The short take away is not necessarily, but it’s probably a good idea, but we definitely need to learn about containers.

I have heard for years, “Microsoft will automate everything and the DBA’s job will go away.” Not only is that not true in my experience, the exact opposite is. I think being a successful DBA is in some ways harder than it was a decade ago. There’s so much more to be aware of and to learn.

Off the top of my head, without any real priority I came up with the list below of technologies that a modern DBA might find useful to know. This is not to say I know them all, or that one has to be an expert in all of them. And I will note, this is far from an inclusive list. I also left out third-party tools which are so common place. But I think it illustrates just how broad the required skillset of a good DBA is these days.

  • T-SQL
  • PowerShell
  • Query Store
  • Linux – at least at the most basic level
  • Containers
  • SSIS
  • SSAS
  • SSRS
  • Storage – (at least how different types can impact performance and the advantages and disadvantages of each)
  • Azure
  • SQL Database Edge
  • git or some form of version control

In conclusion, I’ll say, I’m not going to make any predictions about where the Microsoft data platform will be a decade from now, but I can tell you that DBAs will still be needed but their skillset will be as different from today as today is from a decade ago.

And post conclusion, I’ll add I’ll continue to rely on #sqlfamily and all my fellow DBAs to help me out. And continue to help them.

Coping

I’m going to be a bit more open than I usually am in my blog posts. I think it’s time for a bit of transparency.

Let me start by saying that overall, despite the impact of Covid, the last 15 or so months have not been terrible for me. Far from it. In fact I’ve been very fortunate. So this post isn’t a rant or a series of complaints. It’s really a short reflection.

Last year for example, I biked more than I had in years, and in fact did my first century ride since college. I presented at PASS Summit for the first time, albeit virtually. I got to spend more time with my kids. Fortunately, no one close to me had a serious case of COVID nor died from it (though I had friends and former coworkers who did lose people close to them).

I even managed to organize and pull off a cave rescue training class late last summer. And of course just pulled off another weeklong course this month, and will help with another one in late August.

So overall, it’s been a pretty decent 15 months.

But lately I’ve noticed things aren’t necessarily where I want them to be. My motivation levels have been off. I’ve got at least 3-4 ideas for more articles for Redgate. But, I find myself finding reasons to put off writing them. I’ve got a few other projects that I haven’t made progress on. I need to finish tiling a backsplash in my bathroom, patch a hole in the wall in the downstairs bathroom from when I put in a fan, and a few more.

But honestly, the idea of launching into such projects just makes me go “bleah”.

I think too some of the frustration in my inability to attract new clients like I was hoping to this year has put me into the “bleah” mode, and of course in a vicious cycle caused me to put less effort into attracting new clients.

But, ultimately, I’m writing this post not because I’m looking for sympathy or for comfort, but ironically for the exact opposite reason. I find that often people hide the state of their emotional well-being and put on a happy fa├žade, especially on social media, and as a result everyone goes around thinking that everyone else is doing better than they are themselves doing. So, I’m saying, “hey, I’m doing great, but you know what, there are days when life is ‘bleah’ and it’s ok. And if you’re having such days, or even worse, you’re not alone.”

Postscript: I want to add, if you haven’t, check out Steve Jones blog, he’s been daily posting a bunch of coping suggestions. I don’t read them every day, and I suspect Steve would agree with me that take what works for you and ignore the ones that don’t is the way to go. In part his posts helped inspire this one.

“We’re up to plan F”

I managed to skip two weeks of writing, which is unusual for me, but I was busy with other business, primarily last week leading an NCRC weeklong class of cave rescue for Level 1 students. I had previously lead such a class over three weekends last year, and have helped teach the Level 2 class multiple times. Originally this past week was supposed to be our National weeklong class, but back in February we had agreed to postpone it due to the unknown status of the ongoing Covid pandemic. However, due to a huge demand and the success of vaccinations, we decided to do a “Regional” Class just limited to Level 1 students. This would help handle the pent up demand, create students for the Level 2 class that would be at National, and to do sort of a test run of our facilities before the much larger National.

There’s an old saying that no plan survives the first contact with the enemy. In cave rescue this is particularly true. It also appears to be true in cave rescue training classes!

The first hitch was the drive up the the camp we were using. The road had been stripped down to the base dirt level and they were doing construction. Not a huge issue, just a dusty one. But for cavers, dust is just mud without the water. But this would come into play later in the week.

Once at the camp, as I was settling in and confirming the facilities, the first thing I noticed was that the scissors lift we had used to rig ropes in the gym last time was gone. A few texts and I learned it had only been on loan to the camp the past two years and was no longer available. This presented our first real challenge. How to get ropes up over the beams 20-30′ in the air.

But shortly after I realized I had a far greater issue. The custom made rigging plates we use to tie off the end of the ropes to the posts were still sitting in my garage at home. I had completely forgotten them. This was resolved by a well timed call to an instructor heading towards the camp, who via a longer detour then he expected, was able to get them. Fortunately, had that call waited another 5 minutes, his detour would have probably doubled. So the timing was decent.

I figured the week was off to a good start at that point! Honestly though, we solved the problems and moved on. I went to bed fairly relaxed.

All went well until Monday. This was the day we were supposed to do activities on the cliffs. Several weeks ago, my son and I, along with two others had gone to the cliffs, which were on the same property as the camp, but accessible only by leaving the camp and accessing from a public road, in order to clear away debris and do other work to make them usable. I was excited to show them off. Unfortunately, due to the weather forecast of impending thunderstorms all day we made the decision to revise our schedule and move cliff day to the next day. There went Plan A. Plan B became “go the next day.”

On Tuesday I and a couple of other instructors got in my car to head to the cliffs in advance of the students so we could scope things out and plan the activities. We literally got to the bottom of the road from the main entrance to the camp where we were going to turn on to the road under construction, only to find a the road closed there with a gaping ditch dug across it. So much for Plan B. We went back to the camp, told students to hang on and then I headed out again, hoping to basically take a loop around and approach the access road to the cliffs from the opposite direction. After about a 3 mile detour we came to the other end of the road and found it closed there. Despite trying to sweet talk the flag person, we couldn’t get past (we could have lied and said we lived on the road, but after 8-10 other cars would have arrived in a caravan saying the same thing we thought that might be suspicious). There went Plan C. We called an instructor back at the camp and headed back.

We got there and turns out an instructor had already come up with Plan D, which was to see if we could access the cliffs by crossing a field the camp owned and going through the woods. It might involve some hiking, but it might be doable. While there are dirt-bike paths, there’s nothing there that worked for us. So that plan fell apart. We were up to Plan E now. Plan E was proposed to further swap some training, but we realized that would impact our schedule too much. Now on to Plan F. For Plan F, we decided to head to a local cave which we thought would have some suitable cliffs outside.

That worked. It would out quite well actually. We lost maybe an hour to 90 minutes with all the plans, but we ultimately came upon a plan that worked. We were able to teach the skills we wanted and accomplish our educational objectives.

Often we wake up with a plan in our heads for what we will do that day. Most days those plans work out. But, then there are the days where we have to adapt. Things go sideways. Something breaks, or something doesn’t go as planned. In the NCRC we have an unofficial motto, Semper Gumby – “Always be Flexible”. Sometimes you have to completely change plans (cancelling due to the threat of thunderstorms), others you may have to try to adapt (finding other possible routes to the cliffs) and finally you may need to reconsider how to meet your objectives in a new way (finding different cliffs).

My advice, don’t lock yourself into only one solution. It’s a recipe for failure.

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.

“It’s Just a Simple Change”

How often have we heard those words? Or used them ourselves?

“Oh this is just a simple change, it won’t break a thing.” And then all hell breaks lose.

Yet, we also hear the reverse at times. “This is pretty complex, I’ll be surprised if it works the first time, or if it doesn’t break something.” And yet then nothing bad seems to happen.

We may observe this, but we don’t necessarily stop to think about the why. I’ve seen this happen a lot in IT, but honestly, I’ve seen this happen elsewhere and often when we read about accidents in areas such as caving, this also holds true.

I argue that in this case the perception is often true. Let me put in one caveat. There’s definitely a bias in our memory where we don’t recall all the times where simple things don’t break things, but the times it does, it really stands out.

The truth is, whenever we deal with complex systems, even simple changes aren’t so simple. But we assume they are and then are surprised when they have side effects. “Oh updating that path here won’t break anything. I only call it one place, and I’ll update that.” And you’re good. But what you didn’t realize was another developer liked your script, so made a copy and is using it for their own purposes and now their code breaks because of the new path. So your simple change isn’t so simple.

Contrast that to the complex change. I’m in the middle up refactoring a stored procedure. It’s complex. I suspect it’ll break something in production. But, honestly, it probably won’t. Not because I’m am awesome T-SQL developer, but, because of our paranoia, we’ll be testing this in UAT quite a bit. In other words, our paranoia drives our testing to a higher level.

I think it behooves us to treat even simple changes with more respect than we do and test them.

In the world of caving we use something called SRT – Single Rope Technique. This is the method we use for ascending and descending a rope. When ascending, if you put your gear on wrong at the bottom, generally there’s no real risk other than possible embarrassment. After all, you’re standing on the ground. But obviously a the top, it’s critical to put your equipment on correctly, lest your first step be your last. Similarly, we practice something known as a change-over; changing from ascending to descending, or descending to ascending while on rope. When changing from climbing to descending you want to make sure you do it correctly lest you find yourself descending at 9.8m/s^2. To prevent accidents, we ingrain in students “load and test your descent device before removing your other attachment point.” Basically, while you’re still secured to something at the top, or to your ascending devices if you’re partway up the rope, put your entire weight on your descent device and lower yourself 1-2″. If you succeed, great, then you can detach yourself from whatever you are attached to at the top, or remove your ascending devices. If somehow you’ve screwed something up and the descent device comes off the top or otherwise fails, you’ve got a backup.

Now, I will interject, getting on rope at the top of a pit, or a changeover is something an experienced caver will have done possibly 100s if not 1000s of times. It’s “a simple change”. Yet we still do the test because a single failure can be fatal. And I have in fact seen a person fail to properly test their descent device. And moreover, this wasn’t in a cave, or other dark or cramped space. It was in broad daylight on the edge of the RPI Student Union! This was about as simple as it could get! Fortunately he heard it start to fail and grabbed the concrete railing for dear life. In this particular case a failure most likely would not have been fatal, but would have caused serious injury.

So, despite having gotten on rope 100s of times myself, I ALWAYS test. It’s a simple change. But the test is also simple and there’s no reason to skip it.

The morale of the story, even your simple changes should be tested, lest you find they’re not so simple, or their failures aren’t so minor.

4/20

I was going to start this post by making a crack about getting any cracks about references to 420 out of the way. But then I realized they’re actually apropos of the intent of this post.

Yes, often when we folks think of the numbers 420 the references to marijuana jump out. Not a habit I’ve ever had any interest in, but I’ve been around it enough to feel its effects and I guess I can understand why others might partake. Growing up in the 70s and 80s I was routinely offered it but always declined due to lack of interest. That said, one thing that I never really dwelt on much was what would happen if I got caught with it. My skin color mattered.

Three events though shaped 4/20/21 for me.

I happened to reread (I had come across it earlier) a post by Eva Kor on Quora. Eva Kor was a twin who survived Josef Mengele’s atrocities and spent much of her life talking about them. She was a living witness to the history of the Holocaust, an event we must never forget. Sadly she is gone now, but her writings and voice live on.

4/20 also happens to be the birthday of George Takei. I recall growing up watching him in reruns of the original Star Trek, playing originally a physicist on the Enterprise, but really best known as the ship’s navigator. To quote Spock Sulu “is at heart a swashbuckler out of the 18th century”. But I later learned he was also instrumental in bringing attention to a dark period of our own US history during WWII, the internment of US citizens of Japanese heritage. He is, at this writing, still a living witness to those dark days. But, the truth is unfortunately, time will eventually silence his great voice. But that does not mean we can be allowed to forget what the US did to its own citizens.

And finally of course 4/20/21 was the reading of the verdict of in the George Floyd murder case. Guilty on all three counts. George Floyd’s life was sadly ended with the words “I can’t breath.” He can’t speak for himself. But fortunately, due to cell phone cameras, and the work of the prosecution, the jury could speak for accountability and hold his murderer responsible.

While the murderer will be held accountable, it will not change the tragedy that such an event should never have happened. There are those that will still argue, “well if he hadn’t resisted arrest…” ignoring the idea that perhaps the initial response while legal, probably should have been handled very differently. Dr. Mengele’s atrocities were considered legal, but that didn’t make them right by any moral compass I am comfortable with. The Supreme Court in Korematsu v. United States held that the government could force Korematsu to be detained because of his heritage. In the case of George Floyd, the defense argued a reasonable officer would do what George Floyd’s murderer did. The jury rejected that argument. Thankfully. But we know all to often where that argument did hold sway. And, honestly will again.

So back to 420. The decriminalization of marijuana is quickly becoming the norm. Even my US Senator Chuck “I never found a camera I didn’t like” Schumer posted on Facebook positively about 420 day. These are steps forward. But, there is still an ugly racial history to the handling and prosecution of crimes related to marijuana in this country. Blacks for example are about twice as likely to be arrested for possession, despite their rate of use being about the same as whites. Like many aspects of the law, it’s clear it’s applied disproportionality and in a huge part based on the color of ones skin. Hence why I never really worried too much about it.

Fortunately here in New York, part of the rollback of marijuana laws is including vacating 10s of thousands or prior convictions and expunging them from individual records (there are some caveats however.) This is a step towards restorative justice.

So 4/20 represents a confluence of events and perhaps a step forward. But despite Eva Kor’s testimonies, George Takei’s work, still going on today, and the conviction of George Floyd’s murderer, we have a long ways to go towards the living up to our ideals. They are the voices calling us to do better. And we must. And we must never think the work is done.

Make Security Easy

This will be a short blog this week, but I want to talk again about an issue I have with a client of mine. They make security hard.

This is not to say they don’t take it seriously, or that they are lax. Far from it. They actually are fairly stringent on their security protocols and get after folks on ensuring boxes are consistently patched and that passwords are stringent and details like that. Overall I’d give them probably an B on security. But I can’t quite give them an A.

There’s really two reasons for that:

The first is inconsistency. Let me be clear, getting to their internal network is appropriately difficult. I have to use their secure VPN, with soft-tokens and similar measures. Technically before I can access a box, I have to jump through multiple hurdles. I’m ok with that. What’s a pain is on some boxes if I walk away for an extended period of time, the screen remains unlocked and nothing changes. Now, because of my OWN security model my computer will lock FAR sooner than that. And my default mode is to typically lock my own computer anytime I walk away from it (and that’s within my own house). But for some machines, if there’s no keyboard or mouse input, the screen will lock after 15 minutes, but my session won’t ever be logged out. For others, the screen will lock after 15 minutes and my session will be logged out after several hours. There appears to be no real rhyme no reason to this other than a slight correlation with when the box was configured.

Now, in general, I think locking unattended screens can be a good thing. The downside is, due to the nature of my job, I may start work on one machine, flip over to another to do something like update the schema and then flip back to the first, only to find my screen locked. In some cases, I won’t. It’s inconsistent. Ideally I think it should be consistent.

So, if you have a security protocol, decide on what it is, and make it consistent.

But the real complaint I have, and this has been true of multiple companies I’ve worked with: make security easy.

Again, with this particular client, on most, but not all boxes, I can easily download and install the required patches. (OS level patches are handled by their internal IT team which is a huge win). But some machines have firewall rules in place such that you can’t download the patch directly to the machine. You have to go to a jump box, download the patch there and copy it over. This is fairly inconvenient. Now, if this were consistent across all machines I’d develop procedures around that, but they’re not consistent. This is particularly a problem for software that often will actually only download a stub installer that will then try to download the actual patch. In this case, if you simply copy over the stub and try to run it to patch the machine, it too will fail. This means you need to find the often hard to find link to download the full patch to the jump box and then copy that over. In some cases, it’s even worse, you have to manually place files where you want them. I had this occur on an update I was doing to a module for PowerShell. I had to download the installer to a jump box, extract what I needed and manually copy the files to the right subdirectory. Now, granted, I get paid by the hour, but I’d like to think my clients pay me for things other than copying files.

I’ve seen another related issue at other clients when it came to patching. They’d patch users desktops during the day and default to “reboot in the next 10 minutes” with no option of delaying the patch or reboot. Now, there are possibly first day exploits where this might be warranted, but this was the default for ALL Windows patches. This was really discouraging to employees and multiple times caused them to lose work, especially it they were away from the desk during this time and didn’t have a chance to save their work. The sad part is that there are multiple ways this could have easily been handled that would have had far less impact on the employees.

In the end, security is critical, but we should be making it as easy to comply as possible and as consistent as possible. There’s an old adage that the security person doesn’t stop doing their job until they’ve stopped you from doing yours. Don’t make that a truism.