Author: Jonathan Szeto

Posted on

The SURVIVAL Acronym

When I was in the military, my instructors taught me the SURVIVAL acronym as part of wilderness survival training. The acronym went like this:

  • Size up the Situation
  • Undue Haste Makes Waste
  • Remember Where You Are
  • Vanquish Fear and Panic
  • Improve Your Situation
  • Value Living
  • Act Like the Natives
  • Learn Basic Skills

At some point I may do a deeper dive into these points, but here are some quick takeaways:

Continue reading “The SURVIVAL Acronym”

Posted on

Complexity

Complexity rises at an exponential rate to the size of a project. This applies whether your project is business or personal in nature.
The corollary to that is that the risk of failure (of any scale) also rises at an exponential rate to complexity. And when you apply the first rule to the corollary, this means that the odds of something going wrong on a large project are near certain.
There’s also another corollary, that time to work on even the basic tasks increases with complexity. (How fast sometimes depends.) Which means that a big project is almost certainly late and buggy.
The conclusion is obvious: keep your projects small, with very short lead times. You are more likely to deliver on-time, and with less mistakes.
Please note that big projects are not the same as big goals. You can have big goals — but it’s going to take you a long chain of small projects to get to that goal.
This will also allow you to change course relatively quickly in case your goals change. And the likelihood of that also rises with the size of your goals.
An added side benefits of having a chain of small goals is that it teaches you to build a system. Because inevitably you’ll find yourself doing the same set of tasks from one small project to another.
Because you’re working towards your goals in a chain of small projects, make sure the links are approximately the same size, whether in terms of money or time.
For example, many companies that implement Agile software often have a two week scrum cycle. It’s long enough to get any meaningful work done, but also short enough to limit time delays and complexity bloat.
Posted on

A Technologist’s Talent Stack

Earlier I talked about building a talent stack of different skills in order to increase your uniqueness and value. Below I put together an archetypical talent stack for a technologist, drawing from my own experiences. The list below is far from complete, and that’s intentional. You should design your own stack that’s unique to you.
One thing I should emphasize again: you don’t have to be an expert at all of these. You should be very. very good at at least one (maybe two or three, if you’re really determined), and then have passable ability at the others.
I’ve laid these skills out into discrete large sections, as some tend to be more related to each other.

Continue reading “A Technologist’s Talent Stack”