Causes of Backpacking and Hiking Deaths

As my big backpacking trip was less than three weeks away, I decided to start thinking seriously about trail safety and how to stay alive. Shortly into my research I realized, hiking might be a little more dangerous than most people expect.

According to the National Center for Health Statistics, your chance of dying while mountain hiking is 1 in 15,700 annually, or a .0064% chance… this doesn’t seem to too bad until you compare it to, say… skydiving, where your chance of dying is 1 in 101,083, or .00099%. That’s right, you’re 6.4x more likely to die while hiking than you are while skydiving.

What’s making hiking so much more dangerous than skydiving? Of course, the obvious answer is bears. You seldom, if ever, encounter a bear while plummeting towards the ground at 120 MPH, whereas bears are constantly eating hikers on trails as if they are at a sushi bar, pulling treats onto their plate as they drift by on small boats. As I went to confirm my hypothesis, I realized that bears are pretty much the only thing that isn’t going to kill you while backpacking. So, statistically speaking, what was the most likely thing to prematurely re-route my backpacking trip to the hereafter?

I was unable to locate a definitive source of hiking or backpacking deaths only. The American Alpine Club publishes and annual Accidents in North American Mountaineering report, but that doesn’t address hiking specifically. I found a promising article, What’s Killing America’s Hikers? but the statistics were around search and rescue reports and summarized the primary causes as lack of knowledge, lack of experience, and poor judgment, whereas I was really hoping for categories like “eaten by a bear”. A final source of inspiration for fear was 17 Things Scarier Than Bears On The Pacific Crest Trail, which didn’t provide statistics but did help expand the breadth of options for concern.

I pieced together what seem to be the specific categories of risks that actually sound frightening (really, you’re never going to see a movie, Friday the 13th: Lacking Knowledge, or Scream: Poor Judgment). Here’s my assessment, in countdown order:

7. Animals

This image has an empty alt attribute; its file name is bear-blinkkig-eyes.jpg

I’m counting down from least risky to most, so as much as I want to blame bears, they are pretty much bottom of the deadly risk list and only made the list because they are grouped with all of the other animals that can kill you, including (but not limited to) mountain lions, snakes, mosquitos, spiders, and bees. Each animal requires a different risk mitigation strategy, and sometimes requires that you quickly classify the variety of the species about to attack you, since the same strategy applied to the wrong species can lead to provocation rather than being a deterrent. As you’re being mauled, be sure to check if it is a grizzly bear or a black bear before taking any action.

6. Temperature (too much, too little)

If you get too hot, your brain starts cooking. The good news is you probably won’t notice, because you’ll be more interested in your convulsions, except you might not notice the convulsions because you’ll be delirious.

On the other hand, cold can happen very quickly as sudden changes in weather can result in severe temperature drops in a matter of minutes. You also experience a state of delirium, making very poor decisions and often coming to the conclusion that you are too hot – many freezing victims are found outside of their shelter and in a state of disrobe, potentially giving new meaning to the phrase, “frozen stiff”.

5. Lightning

Lightning has the advantage of range when it comes to contributing to an untimely death, making you generally unsafe within 6 miles but strikes have been recorded at distances of 10 miles. In the US, lightning kills about 50 people each year, about 11 of those are in Colorado. There are numerous tips to reduce your chances of being struck by lightning, but if you’re not minutes away from being inside a properly-grounded building or vehicle, most of the tips just lead to variations of an, “oh shit” scenario. And you might not even go out with a glorious bolt of lighting reaching from the sky to your body… 50% of lightning induced injuries and death come from ground current and an additional 30% from side splash, where lightning jumps from person (or object) to person, so death can happen as far as 60 feet from where lightning strikes the ground.

4. Health Issues

While hypothermia, heat stroke and bleeding from the neck while a mountain lion eats you are arguably health issues, I’m placing things like heart attacks, ruptured appendix, and spreading infections in this category. All of the health issues that have a high recovery rate if you can seek prompt medical attention can become life or death issues when isolated in the woods. As a solo hiker you’re screwed, with a companion you also probably screwed. Since dysentery is both a health issue and can be the result of drinking untreated water, I will blend this with the next highest risk…

3. Water (not enough)

Not enough drinkable water can kill you in a few ways. Continuing on with the general “health issue”, water than has not been properly treated or filtered can give you a variety of health problems, a common one being the Giardia parasite . Of course there’s the more obvious problems caused by lack of drinkable water, dehydration and the follow-up problems leading to death, heat stroke and hypothermia. If you’re thinking that hiking in cold weather reduces this risk, not so much… cold, dry weather can use more water than warmer, more humid air and you may require even more water.

2. Water (too much)

If not having enough water was going to kill you, having too much water, especially when it is surrounding your body, is even more likely to kill you. Evidently a surprising number of hiking deaths result from bodies of water making it difficult for gill-less hikers to breathe, smashing hikers into other objects, or causing hikers to free-fall off waterfalls. Most of this time the body of water presents itself in an obvious fashion and bad choices lead to death, but occasionally flash floods can make death more or a surprise.

1. The Ground (falling into it)

A few years ago I hiked Half Dome in Yosemite. The park averages 12-15 deaths each year, although the Mist Trail takes a lot of the credit, especially as tired hikers return from Half Dome and glide off slippery rocks. As I was ascending the cables, I couldn’t help but think that a slip and fall would be several thousand feet before I landed quite abruptly in the Yosemite Valley, but would be preceeded by most of the flesh being scraped off my body as I slid across about 250 feet of steep granite… too slick to get traction, just abrasive enough to take skin samples on my journey, possibly making meeting the valley floor a welcome relief. It made me hold the cables that much tighter.

If anybody has reliable data sources they can cite, or if you just happen to be super knowledgable about hiking death statistics and suggest a re-ordering, please leave a reply!

Update: I found Forget bears: Here’s what really kills people at national parks, which has some statistics for national parks, not hiking in general, and seems largely consistent with my assessment, adjusting for activities engaged in by most visitors to national parks.

3 Things You Can (and Should) Change In Vendor Agreements

Over the last 10+ years I reviewed and negotiated all sorts of vendor agreements for technical operations.  Companies that are starting to build out their production environments occasionally contact me looking for advice.  Being on vacation (and having time to write), I decided to share some of the more common problems I see in vendor agreements.

In almost all cases you can (and should) get better terms on what are presented as these “standard” clauses.

SLA

The Service Level Agreement (SLA) is probably the most critical to the availability of your business.  For vendors providing services like DNS or bandwidth, any vendor failure can result in failure of your business.  In other words, your uptime is no better than their uptime. The SLA is typically expressed and a percentage of availability.  If the SLA is 99.9% uptime, you are accepting 45 minutes of downtime per month.  Failure to meet the SLA usually means reimbursement for the cost of the service, not for the cost of your lost revenue resulting from the failure.   For example, if you pay a DNS service $31 per month and they are down for a full day, your reimbursement would be $1, not the revenue you lost during that full day.  Also, when the failure begins is usually defined as your notification to the vendor, not by the actual beginning of the failure.  In other words, if you didn’t report it, the problem never happened.

The availability percentages for an SLA are usually difficult to alter but there are a few things in that you can change to limit your liability.  Most (all) services have occasional failures, but it’s how they fail that become problematic for your business.  An occasional failure might be okay but if this is a pattern you want the option of moving to a new vendor.  You can usually add a clause that allow a termination of the agreement if the vendor fails to provide service more than N times in a 1-month period.  Also, you can usually require that SLA failure begin at the time of the actual failure (when it is detected by either party) rather than your notification to the vendor.

Term and Renewal

Automatic renewals are also common in agreements, in which the duration of the agreement is automatically extended by the length of the initial term.  Typically these require you to opt-out of the renewal by providing written notice within a narrow window of time.    For example, your initial duration is a 1-year after which the contract will automatically renews under the same terms for an additional year unless notice is provided in writing 30 – 45 days prior to the automatic renewal.  Vendors generally don’t contact you to remind you that your opt-out window is approaching and that you might want to negotiate a better deal while you can.

In most cases you want to avoid this simply because the prices for the service are almost always cheaper at the end of the initial term.  This is especially true for things like CDN and bandwidth.   If you’re not good at remembering to do things 11 months in the future, you may find yourself stuck in an agreement with the least favorable pricing.

The initial duration of the agreement is usually a requirement, or at least a requirement for favorable pricing.  However, you should be able to change the automatic renewal to transition into a month-to-month agreement instead of the initial term.  This will provide a better negotiation position when the agreement is up for renewal and will allow you flexibility in the timing.

Change of Terms

It is not uncommon to have a clause in the agreement that sates something to the effect of, “these terms are subject to change” with a link to the vendor website with the current terms.  In effect, this says “you agree to whatever we decide to publish on our website”.  I find these clauses ridiculous… I would love to respond with a clause stating, “our payment terms are subject to change subject to the amount I decide to write on the check”.

In these cases I find it useful to add a clause that requires notification (in writing) of any changes with a short period allowing an opt-out if the changes are seen as a material change.  If you are unable to get a clause to allow termination of the agreement you should be able to get the option to stick with the original terms.

It’s worth noting that with any change to an agreement, a vendor may not have systems helping them enforce or react to the change.  For example, if you are the only customer requiring written notice of changes, this may require manual work that they forgot shortly after signing the contract.  You should consider this and word your changes in a way where a failure on the part of the vendor does not put you at a disadvantage.

Being a Great Engineer != Being a Great Engineering Manager

I just read Google’s Quest to Build a Better Boss, describing “Project Oxygen”, which analyzed Google’s performance and review data to determine which characteristics are most important to being a successful manager at Google.  This was summarized into eight key success behaviors and three common pitfalls.  The big surprise?  Google “…found that technical expertise — the ability, say, to write computer code in your sleep — ranked dead last among Google’s big eight.

This is not a surprise to me and supports what I have come to believe after years of engineering management – being a great engineer does not necessarily prepare you for being a good manager.  This is not to say that great engineers can’t also be great managers, but the process many companies use of taking their best engineers and “promoting” them to management is flawed.  In many cases, it leads to a company losing a great engineer and gaining an ineffective (or worse, harmful) manager.  Many companies compound this problem by creating career ladders that effectively force engineers to choose between a career ceiling and a management path.

There are many characteristics that I see in successful managers.  First and foremost, good managers have to always be working to ensure the success of the team and their individual reports.  Success goes beyond just getting projects and tasks done – it also means helping their individual reports understand their strengths and opportunities for growth.  It requires taking a real interest in where each person wants to go in their career and creating opportunities for them to reach their goals.  Good managers need a lot of block and tackle type skills to unblock people and ensure they have an environment that helps them remain productive.  Good managers encourage growth for their employees by giving direction when needed but empowering them to try (and sometimes fail) in the interest of helping them learn and improve.  Of course, good managers must also be proactive about confronting tough issues and addressing performance problems to maintain a high-quality team.

Those characteristics are not necessarily the same characteristics necessary to be a great engineer.   It is not uncommon to see great engineers also be really great mentors and solve problems (beyond just engineering) in creative ways, but it is not typically their focus.  Also, the way they work is typically different.  Most managers have a tremendous amount of context switching during their day and need to make themselves available and interruptible to unblock others – this can be highly detrimental to an engineer that typically pays a high cost for context switching and getting back into the flow.

Another critical characteristic of good managers is knowing how to get problems solved.  This is very different than knowing the solution to a problem. The manager adds value by unblocking their report, not by being smarter than their report.  Many times I see very technical employees go to a much less technical manager with a technical problem.  While the manager may not be able to solve the problem directly, they can usually identify the steps (and people) required to get a solution.   This is where I see many organizations make mistakes when looking for managers – they assume that a manager can’t manage engineers if she is less technical that the engineers in the organization.   As an example of how this can manifest itself, at my company we were looking for an additional engineering manager and the bar was set pretty high based on the performance and 360 feedback of our existing manager – engineers thought he was great.  The engineers interviewing the candidate used the exact same very technical questions we use to identify great engineers.  The candidate did not do well.  In the wrap-up meeting I asked if they had ever needed their great manager to to answer these types of technical problems and the response was, “no – we have really solid tech leads for that”.  We quickly adjusted the engineering manager candidate questions to stop looking for successful engineer skills and instead identify manager skills that make other engineers successful.

For most of my life I have had the privilege of working with some truly exceptional programmers (far better than myself).  It did not take long for me to realize that the value I could create for each company as an engineer was much less significant than the value I could create by ensuring that other (better) engineers were effective and successful.  However, some companies make management the only option for career progression, which encourages great engineers that are passionate about coding to switch to a role for which they are less passionate and probably less capable (yes this is a generalization and I apologize to the truly amazing individuals that are both deeply technical and exceptional managers).  More companies should have parallel career ladders that allow engineers to remain with their hands on the keyboard and heads in the code while obtaining a career level as high (or higher) than management positions.

On a side note, one of the things I really liked about Project Oxygen is the approach of using data to analyze business processes.  I find that many companies that are data driven and have a deep understanding of their customer metrics many times don’t have the same understanding of how they work and what make them (in)effective.  We regularly collect data at my company and use it as an input to redefine how we work and constantly benefit from that evaluation.

Here is a summary of Google’s findings from Project Oxygen:

Here are the 8 top behaviors of managers in order of importance:

  1. Be a good coach
  2. Empower your team and don’t micromanage
  3. Express interest in team members’ success and personal well-being
  4. Don’t be a sissy: Be productive and results-oriented
  5. Be a good communicator and listen to your team
  6. Help your employees with career development
  7. Have a clear vision and strategy for the team
  8. Have key technical skills so you can help advise the team

Here are an additional 3 manager pitfalls:

  1. Have trouble making a transition to the team
  2. Lack a consistent approach to performance management and career development
  3. Spend too little time managing and communicating

Simple Chai Tea Gelato Recipe

I recently got rid of my old ice cream maker.  It was electric but it still required filling (and re-filling) with ice and salt, which does not seem like that big of a deal but it proved to be a barrier to wanting to make ice cream, so it came out of its box about once per year.  Instead I got the KitchenAid Ice Cream Maker Attachment for my stand mixer.   It has a bowl you keep in the freezer for about 15 hours and then you just add your ice cream mixture and 20 minutes later you have ice cream.  Setup and cleanup are about 20 minutes total and as a result, I have been making ice cream about every other week.  Good for tasty treats, bad for my recent attempts to lose my girlish figure.

Since it is now easy to make ice cream, I started to experiment.  The first success is my “Simple Chai Tea Gelato Recipe” which would probably be best with Indian food but it isn’t too sweet and has a light enough flavor to be pretty versatile.

2 cups of milk (I used 1%)
2 cups of heavy whipping cream
3/4 cup granulated sugar
4 tea bags of chai tea (I used Tazo brand)

Heat the milk until it is just about to boil, stirring frequently.  Slightly reduce the heat, add the tea bags and continue stirring for 5 minutes.  Turn off the heat and remove the tea bags, squeezing them to extract the remaining milk before discarding.  Stir in the heavy whipping cream and chill in the refrigerator for a few hours until cold.

When freezing the mixture (in an ice cream maker), it will not have as much of an increase in volume as a typical ice cream – this produces a denser consistency more like gelato.  Immediately move the frozen mixture to the freezer for 3-4 hours to harden.

This makes about 8 servings and if you are counting calories, it works out to 206 calories per serving.

Four Great Cocktails You Should Try (Only Three Ingredients Each)

As summer approaches and people look for cool, refreshing beverages to serve, I thought I would do some promotion of a few cocktails that I don’t see getting enough attention.  I’m not going to advocate any particular recipe over another (use your favorite search engine to find hundreds of recipes), but I do recommend you use only fresh ingredients (get out your citrus juicer) and quality alcohol.  If you are doing anything with a plastic bottle you have probably gone down the wrong path.

The best part is you don’t need much to make these cocktails – each requires only three ingredients!

Caipirinha

The caipirinha is a Brazilian drink made with limes, sugar (or simple syrup) and cachaça, a liquor made from sugarcane that is sometimes compared to rum (but they are different, so don’t substitute).  It is important to note that you don’t use only lime juice, you use limes and you muddle them.  The oils released from the skin of the lime add a tremendous amount of flavor to the drink.  I have had recipes made with sugar (typically a coarse, large grain) and with simple syrup and both are tasty, although I have heard what seem like religious arguments from caipirinha aficionados so be careful if you are serving at a Capoeira tournament.

I have tried a few brands of cachaça,and some bottles that were from roadside distillers.  I found the cheap brands were a bit too harsh so spending a little more is probably worthwhile.  If you are new to cachaça and unsure what to get, try Leblon – it seems to be of decent quality and makes a good drink.  Some of the roadside cachaça I had was actually pretty good, although I was too stressed about possibly going blind or getting poisoned to enjoy it fully.

Basin Street (a Bourbon Sidecar)

Technically this cocktail is a Basin Street, although few bartenders recognize the name, so it is easier to think of as a simple variant of the Sidecar in which the brandy is replaced with bourbon.  The ingredients are bourbon, orange liquor and lemon juice.   Cointreau or Grand Marnier are both good options for the orange liquor and a generic Triple Sec will do in a pinch (okay, technically Cointreau and Grand Marnier are name brands of Triple Sec).  As for the lemon juice, I prefer a more tangy lemon over the sweeter varieties like the Meyer lemon.  Use a good bourbon… if you are new to bourbon and need an introduction, try Maker’s Mark – its widely available, won’t offend anybody and it has a fancy seal on the bottle.

In my opinion this is a drink that does well when it is vigorously shaken… its perfect when you strain it into a glass and see a very thin layer of ice floating across the top.

Daiquiri

This cocktail happens to be my test for whether a bartender knows their stuff.  Go into a bar, order a daiquiri cocktail and see if you get the response “we don’t have a blender” (or worse, you hear a blender start whirring).  I am not talking about the horrible abomination that is a frozen daiquiri, I am talking about the original, pure, simple cocktail enjoyed in excess by Ernest Hemingway.  The daiquiri is simply light rum, lime juice and a sweetener, typically simple syrup.  So you may be saying, “hey, isn’t that the same thing as the caipirinha but with rum, that you just told me not to use”?  Not at all.. this is lime juice, not limes and the flavor is completely different.

Oh, if you need an excuse to try this drink, supposedly July 19 is National Daiquiri Day.

Mint Julep

I don’t spend a lot of time back East so maybe this drink gets the attention it deserves, at Kentucky Derby time if no other.  I find that it is not uncommon for a bartender to mess-up this drink because they think it is a mojito with rum as a substitute for the bourbon.  It’s sort of close, but the mint julep does not have lime, so this mistake leads to a pretty nasty tasting drink.  The ingredients of a mint julep are sugar, bourbon, mint and water (okay, that’s four ingredients but I am counting ice and water as the same thing).  When you muddle the mint, make sure you simply crush it to release the essence… you are not trying to grind it into a pulp.  I have also had the mint julep using simple syrup instead of sugar and it makes the flavor more consistent by distributing the sweetness equally, but it is not as fun as drinking the sugar from the bottom of the glass with a straw and adjusting the sweetness in real-time.  Traditionally the mint julep is served in a pewter or silver cup but it tastes just as good in glass.

IMVU’s Startup Lessons Learned Conference Presentation

IMVU presented at the Startup Lessons Learned Conference in San Francisco on April 23rd, 2010. The event highlighted several companies that are being built using the “Lean Startup” framework created by Eric Ries, IMVU’s former CTO, largely based on his experiences at IMVU.

The conference was great and I had the opportunity to meet many smart entrepreneurs trying to build businesses out of great ideas. I heard many stories about the challenges early startups encounter and could remember when IMVU was in that stage. I also talked to some people from companies that are now considered “big and successful” and heard a few comments along the lines of “been there, barely survived that”.

At the conference I had the realization that IMVU as a business is not exactly a “startup” anymore. The goal of an early startup is discovering the right product and achieving a sustainable business model. IMVU has been successful at this and is now all about building a growing, enduring business that is a high value for our customers and employees. Though we still feel like a startup in many ways and hold onto the lean principles that proved to be so valuable, we now have new challenges to address that are typically not considered startup challenges.

A successful startup grows into a bigger business. At IMVU, we heavily invest in our company so we can get more people working on features that delight our customers and build up the business. With more people many of the ways you used to work don’t work anymore. For example, frequent meetings to get feedback from everybody in the company can work when you have fewer than 15 people… when you get to 50+ people this becomes a very expensive meeting. The overhead of making sure everyone in the meeting has background data and context to make an informed decision simply does not scale. Joel Spolsky explained this well and provides good examples in his article, “A Little Less Conversation”.

There are a whole range of challenges in these transitions, from process to culture and all have to be accommodated as a company grows. At the conference I was approached by several people that had gone through the same experience, some successfully, some not. I hope that some of what IMVU shared will help others to learn from our experience and allow more people to fall into the successful category.

Check out IMVU’s video presentation available at http://bit.ly/bBpUcm