This post is part of a series on the future viability of ski areas and ski area expansion in the PNW. The previous post explored how the climate and snowpack has changed over the decades and attempted to answer what it may do in the future. This post addresses the political issues and red tape around ski areas specifically in Washington’s Cascades.

Since 1990 Washington’s population has increased from 4.9M to 7.6M in 2022. Despite this, only limited ski area expansions have taken place, certainly not enough to keep up with population growth. As a result, our ski areas are vastly overcapacity. Facing a crisis of overwhelming demand ski areas have resorted to attempting to limit demand through various means in order to control crowding. It lead me to wonder, if the demand for ski areas and winter recreation in general is there, why have all nearly all meaningful expansions seemingly stopped in the past 30 years? What is preventing us from meeting demand and giving everyone access to our wintertime mountains?

Specifically, this post looks at the following issues:

• What land use restrictions prevent development?
• How did we get here?
• What happened to allow or prevent previous expansions?
• What needs to happen for future expansion to take place?

To answer these questions we need to go back to the development era of the 1960s, then through the increasingly restrictive years of the 1970s & 1980s, and finally to the red tape of the 1990s and beyond. It’s a story that involves decades of legislative history, a Supreme Court case, and a whole lot of maps. Given all this, it can seem hopeless that we’ll ever grow beyond the ski areas that we currently have, but as this post explores, there is a present opportunity for Washington to fulfill the demand for winter recreation in the Cascades.

tl;dr

I often have conversations on the chairlift or the skin track that involve how the Cascades don’t get as much as snow as they used to. It has been said that the 1950s/1960s were the golden age of skiing in the PNW and our ski seasons now are shorter, with less snow, more frequent rain, and that the future is bleak. Putting aside the chairlift hearsay I wanted to know what the data said about the accuracy of that sentiment. Specifically, I set out to answer the following questions:

• Are the Cascades getting less snow than they used to?
• Are our ski seasons becoming shorter?
• How has climate change affected our ski areas in Washington?
• And most importantly, what does the future hold?

Surprisingly, the answer to those first two questions is… eh, not really. We’re more or less getting the same amount of snow currently as in the 20th century; arguably more in some cases! Which begs the question, are we still in the golden age of PNW skiing? Quite possibly, but if so, for how much longer?

However, there are some BIG caveats to that statement. Unfortunately, the full answer to these questions is not a short one. As for the latter two questions, well, the future is not looking good without adaptions but it may not be as bad as you think. Here I explore what over 100 years of snowpack and snowfall data in the Cascades tells us, how broader regional cycles affect our weather, what actual peer reviewed studies have concluded, and what this means for skiing in the Cascades in the near and foreseeable future.

Over the past five years I have conducted 750+ interviews and directly reviewed 10,000+ more. Through that I made observations with the hiring process, common candidate pitfalls, and possible improvements and optimizations we can make to our hiring processes.

The result is a series all about hiring and being hired for software engineering positions. The perspective from both sides of the table is analyzed: how can we as hiring managers improve our processes to more accurately assess candidates in order to build the best team possible? Likewise, how can we as candidates navigate the minefield of technical interviews to come out on top with the limited visibility we have into the process we find ourselves in?

For interviewers:

• The Principles of an Effective Hiring Process
• What Are You Assessing Your Candidates For?
• Don’t Make Me Write Code on a Whiteboard
• What is Cultural Fit?

For candidates:

• Interview Soft Skills For Technical Candidates
• The Interview Rejection Mindset

In November 2014 I found myself on Estes Rockets’ website looking at their Black Friday sale. The only experience I had with model rockets was from a weekend at summer camp over a decade prior. But with the prices of some low power kits at $4 I figured building them could be a fun rainy weekend activity. A week and $30 later a box full of six rockets came in the mail and then proceeded to collect dust in my closet until one uneventful weekend in May when I decided to at least open the package. I had foolishly underestimated the amount of time it takes to assemble even a simple low power rocket (my vision of building all of them in a single evening was not realistic), but the next weekend I headed down to the local park with the assembled rockets, a pack of motors, and a launch pad I made out of PVC pipe. It was fun, I thought, but launching small rockets 500ft up doesn’t hold one’s attention for very long. That’s when I discovered the world of high power rocketry and an active community in my city. After attending a few meetings with the local NAR club, I loaded up my car and headed out to the last high power launch of the season with the intention of getting a level 1 high power rocketry certification. Being my first high power launch, I was not expecting just how high and far downrange these rockets can go. Despite seeing my rocket come down I misjudged how far out it was and spent the remainder of the afternoon wandering around a field full of mud, thick brush, and mosquitoes that I would not want to spend ten minutes walking through. Long story short, I did eventually recover the rocket, but I had plenty of time to think about how I was never again launching a rocket without a tracking system installed.

Over two years have passed since I’ve done any significant development on my encrypted chat program, Cryptully. In that time, a few issues with it have arisen and some issues were left outstanding from when development ramped down. Some of the larger items that needed to be addressed were:

• Most severe: The SMP MITM attack detection implementation was ironically vulnerable to MITM attacks.
• The hard coded DH prime was not uniquely generated.
• The tests have been failing for over two years.
• There was no way to for the server to determine what version of the program a client was running.
• The documentation for running and building the program had become out of date.

I have never gone back to a project after such a long period of time to fix bugs and add new features. Overall, I was pleasantly surprised at how well the code had aged after being neglected for two years. That is, everything still worked with the most recent versions of the libraries and frameworks I used and there were only a few spots where I wondered what the hell I was thinking when I wrote that code. However, there were a few challenges in fixing some of the long standing issues outlined above.