Barriers

Years ago, I had my team building out our racks at our new datacenter. I was quite proud of it. It was going to be our first planned from the start build-out of 6 racks, as opposed to the hodge-podge build-out we had done of 5 cabinets we had previously rented. Instead of just cramming in equipment where it would fit, we could plan where every piece would go and where we’d leave room for future expansion. This was in 2001, so it was still during a big Internet boom.

One of the things I had decided on doing early on was color coding cables. Red was for anything in front of the firewall for example.  On the backside, every server had two network cards, one for outgoing traffic (the “front-net”) and the second for traffic between the servers (the “back-net”).  To help distinguish between the two, I had ordered a bunch of green cables for the front-net, since that data was “safe” and green is “safe”, and blue cables for the back-net, both start with “b”. Sure, somewhat silly mnemonics, but they worked.

Until, about a week after we finally completed our datacenter move, not one, but two members of my five person team commented, “oh, they were different colors? I couldn’t tell, I’m colorblind.”

“Doh!”  So much for my nice color-coded system.  It can be fairly easy to overlook barriers when you don’t see them. Sometimes it takes more thought and action on your part. Sometimes it takes asking questions, or observation.

Lately I’ve been trying to look for more barriers that I might not have seen before and looking into what I can do to remove them. I’ll be the first to admit, I’m not always successful and I’m still learning. But hopefully we call can.

One area I’ve been focusing on this is in my work for the Capital Area SQL Server User Group. Right now I’m looking at two possible barriers. I say possible because I honestly don’t know if they’re issues or not:

First, I’m trying to find someone who can provide ASL interpretation.  Here’s the thing: we have never had, as far as I know, a deaf person attend one of our events, or even express an interest. Is that because there are no deaf DBAs in the area or because they know if they do attend, they probably will face barriers an person with hearing won’t face?

But, that actually begs the question: if there are no deaf DBAs in the area, why? Perhaps there are deaf people who WANT to become a DBA, but can’t because the barriers that exist well before they even attempt to attend one of our events.  I don’t know, but I hope to explore this issue a bit more.

Another item I’ve started to look into, is whether some sort of child-care services at our SQL Saturday event would help encourage more people to attend. My initial thought is, “it’s Saturday, so ideally a spouse can watch kids” or a similar solution. But, that’s assuming every attendee has a spouse or the extra money to hire a babysitter for an entire day. In other words, it’s making a lot of assumptions.  There’s definitely some major logistical concerns that I have to continue to explore before we can even think about offering it. But I’m also simply trying to figure out if it would make a difference.  Unfortunately, currently for our user group meetings itself, it would not be practical. But even then it may be worth looking into.

On a personal note, I have a friend who had a service dog. She was interested in joining me on a caving trip.  So we actually discussed the logistics of it and determined that it was in fact possible to take her caving with her service dog.  There was some logistics we had to work out and I did have to get permission from the cave owner.  Unfortunately, our scheduling never quite synched up and we had to forego the trip. But the point is, barriers CAN be overcome if one works at them and is willing to be a bit flexible.

Today’s takeaway: What barriers have you looked for and tried to remove? They’re out there, even if you can’t see them.

 

Moving the Needle – Hard

One of the things I enjoy is problem solving or “debugging”.  I don’t necessarily mean debugging code, though I’ve done plenty of that.  One particular class of problems I like solving is when something isn’t working “right”.  I’m currently involved on one such issue.

Just before the holidays, the lead developer at one my of my clients put me in touch with a team in another division to help them solve some performance issues they were having with their SQL Server. This is the sort of issue I generally like to sink my teeth into.

I started poking around and asking questions. I was a bit crushed when in the initial review they listed all the things they had tried and I had to nod my head sagely (which, being a remote worker went unnoticed by them) because they had tried all the basic things. They had, fortunately for them, ruled out a lot of the easy fixes.

So now it came down to some digging. I won’t go into too many details, but will cover some of the things uncovered and tried. For one thing, they have 44 SQL jobs that run every 20 seconds and basically do a poll of a database to see if there’s any work to be done. So, every 20 seconds 44 SQL jobs would fire up, do a quick select and then go back to sleep.  On their new server, they were on average taking 6 seconds a piece.  In addition, the CPU would spike to 100% for about 5-6 seconds and then drop back down. We are also seeing a lot of wait states of the MSQL_XP variety (accounting for about 1/2 the time the system is waiting and averaging about 61.1 ms each time. [Thanks to Brent Ozar’s script here!])

We tried three things, two helped, one didn’t.

First, I asked them to spread the jobs out. So now, basically 2-3 jobs are started every second. This means over a 20 second period all 44 jobs are run, but not all at once.  This had an immediate impact, the jobs now were taking about 2-3 seconds. A small victory.

Secondly, we changed the MAXDOP settings from 0 to 4.  This appeared to have no impact on the jobs. In retrospect makes a lot of sense. Each job is a separate task and basically single-threaded, so SQL Agent won’t care about the MAXDOP.

For those who aren’t familiar with SQL Server, MAXDOP is short for “Maximum Degree of Parallelism” This controls how much SQL Server will try to spread out a task among its CPUs. So for example you had 100 tests to grade and sort into alphabetical order and you had 1 person to grade them. That one person would have to do all the work. You might decide that having 100 people is 100 times faster since every person can grade a test at the same time. But then you have to hand out the 100 tests and then collect the tests and resort them back into alphabetical order, and this takes longer than you think.  So by playing around, you realize it’s actually faster to only have 10 people grade them and sort them.  In other words, sometimes, the effort of spreading out the work itself takes longer than the time saved by spreading it out.)

But, one thing that didn’t change was the CPU spike. But, since the poll jobs were twice as fast, we were happy with that improvement.

However, the real goal of the poll jobs was to wake up ETL jobs to handle large amounts of data. These were running about 1/2 as fast as they’d like or expected.

Here, MAXDOP does seem to have changed things.  In most cases, the ETL jobs are running close to twice as fast.

But, here’s the funny thing. I didn’t really care. Yes, that was our goal, but I’d have been content if they had run twice as slow. Why? Because at the point we changed the MAXDOP settings, my goal wasn’t to improve performance, it was simply to move the needle, hard.  What I meant by that was, by changing the MAXDOP from 0 (use all 32 CPUs) to 4 I was fairly confident, for a variety of reasons, I’d impact performance.  And I did in fact expect performance to improve.  But, there were really 3 possible outcomes:

  1. It improved. Great, we know we’re on the right track, let’s tweak it some more.
  2. It got worse. Great, this is probably NOT the solution, but let’s try it the other way and instead of 4 CPUs, try say 16 or even a larger value. At least we know that the MAXDOP is having an impact.
  3. Nothing change. In this case, we can pretty much rule out parallelization being a factor at all.

In other words by forcing SQL Server to use only 4 CPUs instead of all 32, I expected a change. If I didn’t see a change, one way or the other, I could mostly rule out parallelization.

Finally, once we saw that a MAXDOP of 4, we started to play with the threshold of parallelization. In this case we ended up with option 3 above. We tried a fairly small value (5) and a fairly large value (100) and haven’t seen much of a difference. So the cost threshold doesn’t seem to have much of an impact.

So, we’re not fully there yet, there’s a number of other factors we need to consider.  But sometimes when you’re approaching the problem, don’t be afraid to move the needle, in any direction, hard, can tell you if you should continue to try that approach. In this case with MAXDOP it indicated we were on the right track, but with the cost threshold, we’re probably not.

We’ve got a lot more to do, including seeing if we can eliminate or speed up the MSQL_XP wait states, but we’re on our way. (For the record, I don’t expect much change on this one, it’s really SQL Server saying, “hey, I called out to an external procedure and am waiting to hear back” so we can’t tweak the query or do other things that would make much of a difference.”

 

 

 

 

 

Janus 2 – 2019

“All my life’s a circle” – Harry Chapin

The New Year is now upon us. It’s now January around the world.  For those who don’t know where the name of the month comes from, or why my previous blog post and today’s are named as they are, it comes from the Roman God Janus.  Janus looked backwards and forwards. I thought it was appropriate for posts bracketing the New Year. In addition, the name of the month January is often believed to come from the name of the god, but that appears to be a false etymology.

Yesterday I looked back. Today, I’ll look forward.  I’m not necessarily a fan of New Year’s Resolutions (other than resolving to live one more year, which I’ve been successful at so far every time) so call these goals:

  • Continue to blog at least once a week. Last year I think I missed a week while on vacation, but otherwise I pretty much succeeded.
  • Hit 2000 page views. Last year I hit 1907.  I think I can exceed that this year. Of course I’ll need your help!
  • Continue speaking at SQL Saturdays. I haven’t set my schedule, but I already have 3-5 in mind. I’m not sure I’ll do 6 again, but we’ll see.
    • Expand my “SQL Server for under $200” session
    • Expand my “SQL Server Backups” (perhaps into a full precon)
    • Add one more topic to my list of sessions (see current ones here)
    • Shoot for at least one overseas engagement
  • Shoot for speaking at SQL Summit!
  • Figure out how to get an MVP!
  • Publish at least 3 more articles for Redgate’s Simple Talk
  • Continue to promote and support Women in Tech as well as other minority groups
  • Continue to learn PowerShell
  • Continue to learn about SQL Server on Linux
  • Play with containers, just a bit. This is really a minor goal given all the others I have, but I figure I should learn a little.
  • Pick up at least 1-2 more decent sized customers
  • Continue teaching cave rescue
  • Cave more!
  • Hike more!
  • Bike more!
  • Travel
  • Have fun!

That last goal is important to me. If I’m not enjoying what I’m doing, why do it? Life is too short to hate what you do with life. If you can find a way to enjoy life, do it!

Most of the goals above are SQL related, but that doesn’t mean that’s the major focus of my life. It’s just the place this blog touches upon the most these days.

I have a number of personal goals, but that’s for me and I won’t be sharing here.

In any event, I wish everyone in my biological family, #SQLFamily, Caving family, and other chosen families a wonderful and amazing New Year and hope that the new year brings you peace and happiness.

Change your password!

This year saw a new form of greenmail: emails sent to you containing a password of yours stolen from a compromised site.  I saw the first one of these literally an hour or two before boarding a flight to Manchester UK to speak at the SQL Saturday there. My wife received it.

They often take a form similar to:

As you may have noticed, I sent you an email from your account.
This means that I have full access to your account: On moment of hack your account has password: Tel3phone!

You say: this is the old password!
Or: I will change my password at any time!

Yes! You’re right!
But the fact is that when you change the password, my trojan always saves a new one!

I’ve been watching you for a few months now.
The fact is that you were infected with malware through an adult site that you visited.

If you are not familiar with this, I will explain.
Trojan Virus gives me full access and control over a computer or other device.
This means that I can see everything on your screen, turn on the camera and microphone, but you do not know about it.

I also have access to all your contacts and all your correspondence.

Why your antivirus did not detect malware?
Answer: My malware uses the driver, I update its signatures every 4 hours so that your antivirus is silent.

I made a video showing how you satisfy yourself in the left half of the screen, and in the right half you see the video that you watched.
With one click of the mouse, I can send this video to all your emails and contacts on social networks. I can also post access to all your e-mail correspondence and messengers that you use.

If you want to prevent this, transfer the amount of $745 to my bitcoin address (if you do not know how to do this, write to Google: “Buy Bitcoin”).

My bitcoin address (BTC Wallet) is: 19Q4HZtCznuBGcuWng7cacwqZV13gNpZas

After receiving the payment, I will delete the video and you will never hear me again.
I give you 48 hours to pay.
I have a notice reading this letter, and the timer will work when you see this letter.

Filing a complaint somewhere does not make sense because this email cannot be tracked like my bitcoin address.
I do not make any mistakes.

If I find that you have shared this message with someone else, the video will be immediately distributed.

Best wishes!

I actually LOVE this form of greenmail because I suspect it’s highly effective.  I’m also amused because the above (edited) email came with the subject: Security Alert. You account has been hacked. Password must be need changed. It then goes on to tell you that even if you do change your password, the hacker can read it.  I’m also amused because the faux hacker’s concept of my time at the computer sounds FAR more exciting than what I actually do at the computer (and of course the fact I don’t keep my webcam plugged in!)

When confronted with a password that the user recognizes, I’m sure folks pay up.  But, don’t. Yeah, it’s probably a password of yours, but it’s almost certainly from a site that was hacked months previously and has nothing to do with your email, current account, etc.  You can easily find lists of email addresses and passwords online, especially if you’re willing to pay.

In the case of the above password (changed to be extra safe, but even if I hadn’t it most likely wouldn’t matter in this case) I know what service was hacked. Fortunately I only used that password on that one site and it had no financial data associated with it.

That said, again don’t use obvious passwords. In fact effective password systems would incorporate a list such as the one here: Worst 25 passwords of 2018. If you’re using a password on this list: SHAME on your.

The takeaway: If you haven’t, for 2019 make a New Years Resolution to use UNIQUE passwords for every site you use, use a password manager to remember them, and do NOT make them obvious or easy!

 

 

 

Merry Christmas

It’s Tuesday, which means normally I’d try to write something insightful about caving, or computers, or technology, or our human experience.

Instead, I can only say, “Merry Christmas” to all my fans and readers.

I was hoping to get to 2000 page views this year, looks like I’ll be about 50-100 short, but that’s ok. I’ve enjoyed writing my weekly missives and I hope you’ve enjoyed reading them.

Now get off the computer and spend time with your family!

Social Deconstruction II

In a previous post, Social Deconstruction I reflected on a barrier that had been put up on a Thursday, and by Sunday, completely bypassed. I had recent cause to revisit that area again recently and

Barrier bypassed

Barrier bypassed

as you can see, an actual, real gate has been put into the fence. The power of the crowd basically overruled the original intent of the landowner.

Of course, this could have been done from day one.

This is true in the IT world. How often has the security department come and said, “we’re implementing this new security policy” with little input from actual users and are surprised when users get frustrated and try to bypass the new security feature.  I had this happen at a client of mine. In the case of the fence above, people bypassed the security the fence builders wanted (presumably to reduce liability), and by doing so, increased their chance of getting hurt (and ironically, presumably increasing liability).

One of the security features that I think annoys most of us are passwords, or more accurately arcane password requirements. For example, some systems require a certain amount of complexity, but don’t necessarily tell you what the rules for complexity actually are! Yes, I’ve had that happen. Turns out they required special characters, but, only a specific subset of special characters and the ones I tried weren’t on that subset.

Now a minimum password length, makes sense. A one character password can be cracked by anyone. But, what about short maximum password lengths? Yes, perhaps that was a good idea when memory and storage were scarce (ok even then, not a great idea) but not so much these days. Yet, I know at least one system where your password has to be between 8 and 14 characters.

Another annoyance is the “must change every N days” where often N is something like 90 (though I’ve seen even lower). What does this mean? Folks end up with passwords like: Secur3Passwrd$1, Secur3Passwrd$2, Secur3Passwrd$3, etc.

Truth is, many of the so called password rules, actually encourage us to create lousy password, and so we repeat stuff, or write it down or take other steps that make it easier for to use them, but also as a byproduct weaken passwords.

The National Institute of Standards and Technology recently released an updated set of guidelines: NIST 800-63B that discuss good password requirements (note I have NOT read the entire document, just large portions of it).  Spycloud has a decent review here: New NIST Guidelines Acknowledge We’re Only Human. I’m not going to recap the recap here, but I will add what I generally do:

  1. I use a password manager. You can read reviews for finding one that best meets your needs. Personally, I use one that does NOT have storage on the cloud. While in theory they’re encrypted and secure, I get paranoid. (Yes, I do recognize if someone compromises my desktop, they can get access to my local password manager. But on the other hand, if they get access to my desktop, they can probably just install a keyboard logger and I’m hosed anyway.)
  2. I use a different password, automatically created by the above password manager for nearly every site of system I log into.  This ends up meeting most (but not all) of the NIST suggestions (they’re certainly NOT easy to remember, but they don’t have dictionary words, can be as long as I need, most likely are NOT in a previous breech, etc.)

Note, I said most, not all. There’s a few places I used passwords I can remember. These are systems I interact with on a daily or near daily basis, such as my desktop, AND the password manager itself. There would be no point to have a password manager if I couldn’t log into it, or if the password were so simple anyone could guess it.

So, I make sure these passwords are easy to remember, but extremely hard to guess. (For example, they do NOT include the name of my first dog, my mother’s maiden name, etc.)

In conclusion, if you’re in charge of security, make it usable, or else people WILL try to bypass it, simply to get the job done. And, remember, you’re always in charge of your own security, so make it usable, but secure.

 

 

 

Age Impostor Syndrome

This past weekend I was at another successful SQL Saturday. It was, as always, great to see so many of my fellow speakers and friends.

I was perhaps a bit more nervous than usual for this SQL Saturday because I was giving a new technical talk and my demo wasn’t working like I wanted and I hadn’t done as many run-thrus as I like to do.  But it was well received and people seemed to really like it. (For those interested, it was a demo of running SQL Server for under $200, including licensing and hardware!)

During a conversation this weekend I used the expression that I might grow old, but I don’t have to grow up. But I’ve realized it’s more complicated than that.

  • In the past week I’ve completed my 51st orbit of the Sun while still breathing
  • I’m preparing to cook dinner for a bunch of college students this weekend
  • I’ve been working with two recent college graduates on a couple of projects
  • I’m consulting on a new project and using my years of experience to guide it in the right direction
  • My son is completing his first semester at college and coming home this week
  • Apparently received praise (this is second hand) for work I’ve done in a volunteer community

Physically at times I sometimes feel my age, and there certain facts that suggest I really as old as I am; but mentally, I often actually forget I’m as old as I am. I wonder, “why do folks think so highly of me, I’m just a young kid trying to figure my way out in the world.”  Then I realize, I’m not that young kid at his first programming job, trying to figure out how to create a make file.  I’m a middle-aged man who has decades of experience in my various fields of expertise.  People look to me, the way I look to my mentors because they expect me to have the answers! (And fortunately, they’re actually sometimes right.) Sometimes too I’ll be engaging with people my own age and they treat me as equals and I get excited that they’re treating someone half their age with such respect. Then I remember, “but wait I AM their age.”  Or people half my age act as if they’re looking up to me and I want to say, “but I’m no different than you” but then remember, “Oh wait, I do have that many more years of experience.”

So, there’s still a bit of me thinking I’m an impostor. I really don’t know as much as people seem to think I do.  Or that I’m not as old as I really am. Can one even be an age impostor?  Not really, I mean age is a pretty objective fact. But the truth is, I don’t feel my age, and for that I’m grateful.

I’ll continue getting older, but I simply won’t grow up any faster than I have to.

One final request from this wizened old boy, make sure to subscribe if you haven’t!  And speak a little louder so I can hear you.

 

 

Procrastination

“I’d procrastinate, but I keep putting it off.” It’s an old saw but I think there’s some truth to it, at least for me.

Actually the truth is, when I’m not busy, I tend to procrastinate and things don’t get done. But when I’m busy, I get more done. How many of us say “I perform better under pressure”? I know I do.

The other phrase that comes to mind lately is “When it rain, it pours.” The above two adages seem to be the story of my life lately. This is not necessarily a bad thing.

You see, in the life of a consultant it’s often feast or famine. And some times of the year are often more famine than feast. For example, my largest client goes into a code freeze during the last 2 weeks of the year. Taking this into account, I figured I’d have some downtime and be able to work on some projects around the house.

But then, last week, another client emailed me to ask about my availability. They’re a good client and I enjoy working with them, so I responded right away. Unlike my previous project with them that was just a few hours, this one was a top priority project with a firm deadline and lots of work in a short period of time.

Suddenly, my calendar was more full than I expected.

Then my largest client, during our weekly all-hands call, informed me that a project I had completed, they were probably going to take a completely different tact on, and “oh by the way, we’ve got a strict timeline!”

And then of course today, another client calls in with an issue.

Suddenly my calendar was even more full than I expected.

Oh, and did I mention I have a talk to present at SQL Saturday in DC this weekend? And the hardware I was going to use for it is not working?

Suddenly my schedule was completely topsy-turvy and I’ve had to work harder than ever.  But, since I’m already busy, I’ve actually spent a little extra time on other projects that I had been putting off; like finishing the edits on my second article for Red-Gate’s Simple-Talk and then writing a first pass of my third article for Red-Gate’s Simple-Talk. I probably would have procrastinated on that last one a bit longer if I weren’t busy. I know, sounds backwards, but yes, being busy encouraged me to spend time writing.

Of course sometimes even some schedules have to slip, hence this post being 12 hours later than normally scheduled.

When it rain, it pours.  And right now, that’s a good problem to have.

 

Why the submarine wouldn’t work

I was going through my old drafts and found this post I had started to write earlier this year but never finished.  Actually it appears I meant this to be part of White (K)nights but I cut it out to make that post more readable.

During my media interactions I was asked multiple times to comment on Elon Musk and once or twice on his submarine. I tried to keep my comments fairly neutral, but the truth is, I and some of my fellow trained cave rescuers were pretty bothered by Musk’s attempted involvement. I got into at least one online debate about how the people in charge obviously were clueless and that Musk’s solution of a submarine was a brilliant idea.

It wasn’t and I figured I’d address some of my concerns.  Please note as with all situations like this, I was not directly involved, so I’m going on publicly available facts and my training as a cave rescue person and a cave rescue instructor. I am also not in any way speaking on behalf of the National Cave Rescue Commission or the NSS.

Now let’s discuss the device itself:

  • It almost certainly would not have fit. By all accounts, the tightest pinch was 15″ and hard to navigate. Anyone who has moved through a cave knows that even larger passages can be hard to navigate. Locally we have a cave that has a pinch that’s probably close to 15″, but that is at the bottom of a body sized V-shaped passage. Unless you can bend in the middle, you will not fit through it. A cylinder like Musk designed, would not fit. I don’t know the passages in the Thai cave, but odds are there is more than one passage where flexibility is important.
  • It also, in many ways was superbly dangerous. Once sealed into the tube, there would be no easy way to monitor the patient’s vitals. And if the tube had started to leak (cave environments can be extremely destructive, even to metal objects), there appears there would have been no recourse except to keep swimming and hoping to get to an air filled chamber quickly enough and that was large enough to debug the issue.
  • In addition, if the patients were not sedated, I’d have to imagine that being sealed into such a tube, even with lights for 20-40 minutes at a time would have been sheer terror. As it is, the kids were in fact apparently heavily sedated (a fact that some of us still find a bit surprising, even though very understandable), and yet at least one started to come out of sedation while in a water passage. Without being able to directly monitor the vitals of the patient, who knows what would have happened.
  • There’s probably other issues I could come up with. But let me end with this one. Rarely if ever do you want to beta-test or heck even alpha-test, which is what this would have been, a brand new design in a life or death situation when there are alternatives.

Like our White Knights, we want our brilliant tech solutions, but often we’re better off adapting what we’ve done in the past. In cave rescue we try to teach our students a “bag of tricks” that they can adapt to each particular rescue. Foe example, there is no single rigging solution that will work for every rescue.  How I might rig a drop in Fantastic in Ellison’s might be very different from how I’d rig a drop here in New York.  How I  package a patient for movement here may be different than in a Puerto Rican cave.  And honestly I’ve seen a lot of high-tech equipment get suggested for cave rescue that simply doesn’t work well in a cave environment and we often go back to the simple proven stuff.

I will add a tease, to perhaps a future blog post, of a mock rescue rescue where a high-tech approach failed after several hours of trying, and the low-tech solution solved the problem.

 

 

 

Snow Days

“I sometimes hear a moment before sleep, that I can never remember whether it snowed for six days and six nights when I was twelve or whether it snowed for twelve days and twelve nights when I was six.” – A Child’s Christmas in Wales by Dylan Thomas

As I’m writing this there is snow gently falling from the sky and the ground is covered.

I woke up this morning to the sound of a plow scraping the roads clear.  I got up to check the school closings list, expecting at least a 2 hour delay. Somewhat surprisingly there was none.

But it got me thinking about how the same event can be perceived differently by different people.

As a young kid, many of us loved the idea of a snow day.  We hoped we’d wake up to the soft hush a blanket of snow causes, broken only by the occasional scrape of the snow plow. Perhaps we might hear the sound of wheels spinning as a car tried to gain traction to keep on its way. Some even created rituals, such turning their pjs inside out, or sleeping with a spoon under our pillows. (For the record I actually never even heard of any of these until I was an adult). A snow day meant a day of fun in the snow: building a snowman, or better a snow fort and having snow ball fights.  I recall one particularly expansive snow fort friends and I built in a snow bank in the center of Falls Village where we grew up. It had a main chamber from which we could survey our domain and at least two side tunnels we could craw through, leading to smaller “towers” that could fit one of us, to provide flanking fire for anyone foolish enough to try an assault on the main chamber.

Sometimes we’d even play the hero and after one blizzard at least, a friend and I went through town, uncovering buried cars, just in case anyone was trapped. Fortunately no one was. Of course we also then had to at one point dodge a snowplow by scrambling through a 5′ embankment of snow created by previous plows.

As we got older, we may have given up on the rituals and built fewer snowmen, but we still enjoyed our snow days. It meant a break from school, perhaps a chance to catch up on homework. But it also often meant chores, the need to shovel the walk, or worse the driveway.

Then we got older still and now we didn’t get days off. We were told, “the office is still open. Please drive safely.” Now those spinning tires we heard as a child were us, trying to keep straight, and on the road, in order to get to work. Those snowplows we hoped to hear as a child were both a boon and a bane. They helped clear the roads, but also seemed to be in the way.

If our children were young enough, suddenly a day off from school for them, became a burden for us as we struggled to find a sitter or some form of daycare.

We no longer looked forward to forecasts of snow. We dreaded them.  We started our own rituals, some actually more effective than what we practiced as a child. We’d pre-salt the walkway. We’d make sure we had a snowbrush inside the house ready to go so we could clear off the car before opening the door.

It was the same event, but a completely different perspective.  I think I preferred the childhood perspective.

And the irony is not lost on me that my job now actually permits me to sit at home, avoiding the drive, and to write about the snow.

For me, even when I have to drive in it, I actually love the snow and snow days.

For you, I hope you get the day you want, young or old, snow or not.