You just got assigned to a different project, or maybe you just landed a new job. What’s your first action?
With the dizzying array of programming languages, hardware platforms, tool stacks, and processes at your disposal, it’s important to keep your wits about you and make good choices about how to proceed. You want to land on your feet, know what tools are appropriate, and adapt to change; in a sense, you are a survivalist.
Origin of the analogy
Giving credit where it’s due, my manager/mentor suggested this similarity after watching the Discovery Channel show Dude, You’re Screwed. We had several good chats about it, so I wanted to watch an episode for myself to see what parallels I could draw.
Merriam-Webster defines a survivalist as “a person who believes that government and society will soon fail completely and who stores food, weapons, etc., in order to be prepared to survive when that happens.” I’d like to move the focus away from the alarmist part of that definition to the latter — being prepared for change, because it’s coming.
Premise of the TV show
Dude, You’re Screwed uses the reality show format where a survival expert is air-dropped into some region in the world. Example regions are a desert, jungle, and the Alaskan wilderness. The contestant has 100 hours to find civilization. Before setting out, he’s given a survival kit, which could contain useful items and/or things that may actually hinder progress.
A film crew follows the contestant on the journey, but cannot help in any way. The other contestants watch the video feed and are hoping the he won’t meet his goal. The audience gets to hear the contestant explain the decisions he’s making, and the other contestants provide commentary about what they would have done if facing the same issues.
Comments on an episode
I watched the second episode of Season 2 (African Ambush), starring Matt Graham. His survival kit included a unit of cow blood (the local tribes drink it for nourishment), a wooden club, and some makings for arrows. As the helicopter takes off, a rival taunts Matt with a bow, knowing that Matt is an excellent marksman, and would be tempted to use it if given the chance. The helicopter lands in the distance (in the opposite direction Matt should be heading) to drop off the bow.
There’s a hierarchy of priorities.
- First, find a vantage point (i.e., high ground) to see where you are. (The contestants are blindfolded before being dropped off.)
- Next, focus on water, food, and shelter.
- These priorities change depending on what’s happening around you.
You need to keep the global goal in mind.
- The goal is to find civilization (e.g., city, village), not simply to last for 100 hours without dying.
- Finding the vantage point allows you to make educated guesses about what direction to travel. The topology usually plays a role; Matt sees a mountain and knows that people typically live at the feet of mountains.
Distractions make you evaluate priorities.
- Matt gives in to the distraction of walking in the wrong direction so that he can retrieve the bow.
- Granted, this decision now provides him with the opportunity to hunt for food.
- The hill where the bow was placed was not chosen by accident. Matt’s rival knew that once on the hill, Matt would see a dried river bed. Civilization tends to appear near rivers; however, the river only exists in the rainy season, so following the river would not be the optimal route.
- The cow blood was rich in nutrients but also dehydrated Matt much more quickly than he anticipated.
Sometimes you have to know when to stop digging.
- This was literally true, as Matt found some damp soil in the river bed. He hoped that if he dug deeply enough, he would find water. (At this point, the cows blood had severely dehydrated him, so he was getting pretty desperate.)
- After multiple unsuccessful holes, Matt decided to continue walking rather than spend his energy continuing to dig. (He did eventually find a pool of water with animal tracks around it.)
Free things come with inherent risk.
- The water source he found was man-made, and he also found a semicircle of thorny brush, which keeps predatory animals at bay while you sleep at night.
- Although these resources were not being used at the time, Matt realizes that they were most likely built by tribes who don’t take kindly to outsiders.
Local optima can be a distraction.
- Matt uses his club to kill a medium sized bird. With the feathers, he is able to make arrows to kill something more substantial. The time spent getting the first bird, making the arrows, and killing another bird is time not spent on the goal.
- However, this decision to delay may have been tactical. The protein from the bird meat gave Matt the stamina to run a substantial distance during the last 12 hours or so of the contest.
The knowledge that worked in one situation may be inappropriate for the current one.
- In most desert environments, it’s best to rest during the heat of the day and travel at night. Matt followed that advice and changed his mind once he heard lion growls in the distance.
- When you have a false sense of security in your knowledge, it can be dangerous when you are no longer the species at the top of the food chain.
There should be a Plan B.
- Matt does achieve his goal of finding a village within the time limit. However, they were not very happy to see a white man walking on their territory heading toward them.
- To bail him out, one of the other contestants who was very familiar with this area of Africa was able to convince the locals to release Matt in exchange for a cow.
Image credit: Natalie Tapson
Relating these lessons to software development
There’s a hierarchy of priorities.
- Finding the vantage point for a new/different project is important. You need just enough information to figure out where you are, what the moving pieces are, and where the land mines are hidden.
- Jumping straight to the code-writing effort usually isn’t the best first action.
- Common project tasks include coding, testing, and documenting. These priorities change depending on what’s happening with the project moment to moment.
You need to keep the global goal in mind.
- The goal varies depending on your company and industry. Sometimes the goal is to have higher market share. In my current job (at a medical device company), the goal is to put the welfare of the patient first.
- If you don’t know what the goal is, you can ask those above you in the org-chart. If you’re at the top of that chart, I don’t need to say what your next action should be!
Distractions make you evaluate priorities.
- This guidance often manifests itself when changing tools. For example, if all the hip developers are using Visual Studio 2015 with Github, and your team uses Visual Studio 2010 with TFS, you’ll need to put some serious thought as to whether now is the best time for a major change.
- Just like in the episode, switching to a new tool could bring unexpected benefits. For example, switching to Github (externally hosted) instead of an on-premises TFS server, now allows you to work from anywhere on the planet with a basic Internet connection.
Sometimes you have to know when to stop digging.
- In lean startup parlance, this decision is called pivot or persevere. You need to have some idea of a threshold that, when reached, will inform you that your current path is no longer fruitful.
- A helpful approach to testing out uncharted territory is prototyping. For example, maybe you’re trying out WCF to communicate with a service that wraps some custom hardware. A simple console app may be all that’s needed, rather than trying to put all that plumbing into your big application.
Free things come with inherent risk.
- Maybe you need a library that does statistical calculations, and the top industry tools are rather pricey. Perhaps you find an open-source tool that was developed a year or so ago by some person half-way across the globe. It may work beautifully for simple cases (or hopefully all cases), or may bite you when your company loses money because of a rounding error in that free library.
- Let’s say you’re learning about some process, for example, unit testing. There are countless free guides about how to unit test your code; however, most of those are not vetted or curated (unlike books or Pluralsight videos, for example). Please don’t take this statement to mean “if it’s free, it’s probably crap;” I suggest diversifying your sources of information so that you can make a better decision.
Local optima can be a distraction.
- When there’s so much to be measured, it’s easy (and sometimes tempting) to optimize for the wrong metric.
- Beware of bikeshedding, that is, focusing on the trivial parts that are easy to comprehend while ignoring the hard stuff.
- There are exceptions, just like in the episode. Sometimes slowing down to wrap tests around a particularly nasty bit of code (i.e., paying down technical debt) will turn into something useful later on (i.e., not having to wonder what the code is really doing, not worrying about whether a change you made breaks that code).
The knowledge that worked in one situation may be inappropriate for the current one.
- Let’s say your last gig involved 50 developers who deployed 15 times per day and where mistakes weren’t critical. If your current role involves working in a government-regulated arena with a handful of developers working on a product that must fit a very limited deployment environment (i.e., no network connection), you can’t simply rinse and repeat what was working for you on the last project.
- This guideline can also apply to company culture. Perhaps your previous job encouraged finding ways to help others work smarter, say by developing a script to massage some data instead of copying/pasting with Excel. Your current job has a much different culture where people are threatened by your helpful script because it makes them feel like they’re replaceable by a simple program. (There are ways of dealing with this scenario, but that’s a topic for another day.)
There should be a Plan B.
- The first concept that came to mind for this area was source control. It’s amazingly freeing knowing that you can always undo your way back to something that wasn’t quite as broken.
- It’s helpful to consider alternative support plans when dealing with technology changes. For example, if your company has never done anything with cloud computing, but the CTO says “we have to be in the cloud!”, Plan B could be something like, “If these Pluralsight videos don’t help enough, there’s money in the budget for a regional conference where I can network with experts. If that doesn’t pan out, we can work with a consultancy to help get us on the right track.”
Wrapping up
This is such an exciting time to be a software developer. The barriers for entry get lower every year, and I’m constantly amazed by the intelligence and passion of those who contribute to our field. Because of this pace, change is the only constant. Being able to adapt, learn, and think strategically — just as survivalists do — puts you in good stead to have a productive and rewarding career, in software or any other discipline.
Featured image credit: Jayel Aherem