Car crashes kill over 35,000 people in the US every year. Plane crashes, on the other hand, kill ~350. Despite this, we have shows like Mayday/Air Disasters for entertainment on TV, and events such as the tragic death of 67 people on a commercial airline flight into DCA often make the front page of the news for a week, while the state of American roadway safety gets that same level of publicity maybe once everyotheryear.
Many of you probably recognize this as the archetypal example of the availability heuristic: the magnitude of and publicity following plane crashes causes them feel like a much bigger problem than car crashes. This is, of course, despite the fact that car crashes kill two orders of magnitude more people every year.
Relatedly, I fondly recall taking my first computer science class. After the absolute basics of Python, the first real lesson we learned was to always break problems down into simpler tasks, until each task becomes rather easy to do. We later learned that this is a broader principle called decomposition.
Decomposition is a very helpful cue, as it gives an obvious starting point for problems that may seem intractable: break them down. Even if there turns out to be a sub-problem that's an unavoidable blocker, decomposition at least allows for its identification. It's a tenet of modern programming and is implicit in many other programming heuristics (e.g., the single responsibility principle).
By now you might suspect that this post isn't really about vehicular crashes, nor is it really about freshman computer science, and indeed I can confirm that suspicion. Having done so, I now want to let you know that many plane crashes are car crashes, and that luckily we can recognize this with freshman computer science.
A few years ago, one of my plane crashes was generalized unproductivity. I wasn't a total doomscroller, but I knew deep down that I must've had time in my day that I could reclaim and put to more productive ends. Unfortunately, it was quite hard to identify what most of that time was, and even harder to act when I (rarely) did recognize such a time, making it very difficult to change my habits in one fell swoop.
Then one of my computer science classes suggested we complete all the programming in Vim. I figured it couldn't hurt, and despite the initial pain I ended up sticking with it. Having proven to myself that I can change my relatively small habits, a few months later I started using ScreenZen to block social media, then Todoist to systematically track my todos. At that point I realized these somewhat minor things were actually progress towards being more productive, so I started purposefully tracking changes I made in the direction of this goal.
I had to overcome a number of car crashes to start making progress addressing my plane crash, because despite not realizing it, my plane crash was actually composed of a bunch of car crashes. I didn't find programming or writing fun, I spent too much time on social media, and I wasn't effectively tracking what I had to do. The small problems like these—problems that in themselves felt minute—led to a general feeling of unproductivity. This larger problem was easy to identify and something I sincerely wanted to address, but I couldn't see an obvious way to start doing so; in some sense I missed the trees for the forest.
I initially stumbled my way into decomposing my plane crash into a few of its car crashes by divine benevolence, but since then I've made an active effort to continue to do so. It sounds obvious,[1] but decomposing your large problems (or goals)—even if the sub-problems themselves seem unimportant or tangential—truly does make them much more approachable, and thus more solvable.
If you've already put a stop to your plane crashes, congratulations (and I envy you)! But if you haven't, consider asking yourself whether you should try addressing your car crashes first.
Car crashes kill over 35,000 people in the US every year. Plane crashes, on the other hand, kill ~350. Despite this, we have shows like Mayday/Air Disasters for entertainment on TV, and events such as the tragic death of 67 people on a commercial airline flight into DCA often make the front page of the news for a week, while the state of American roadway safety gets that same level of publicity maybe once every other year.
Many of you probably recognize this as the archetypal example of the availability heuristic: the magnitude of and publicity following plane crashes causes them feel like a much bigger problem than car crashes. This is, of course, despite the fact that car crashes kill two orders of magnitude more people every year.
Relatedly, I fondly recall taking my first computer science class. After the absolute basics of Python, the first real lesson we learned was to always break problems down into simpler tasks, until each task becomes rather easy to do. We later learned that this is a broader principle called decomposition.
Decomposition is a very helpful cue, as it gives an obvious starting point for problems that may seem intractable: break them down. Even if there turns out to be a sub-problem that's an unavoidable blocker, decomposition at least allows for its identification. It's a tenet of modern programming and is implicit in many other programming heuristics (e.g., the single responsibility principle).
By now you might suspect that this post isn't really about vehicular crashes, nor is it really about freshman computer science, and indeed I can confirm that suspicion. Having done so, I now want to let you know that many plane crashes are car crashes, and that luckily we can recognize this with freshman computer science.
A few years ago, one of my plane crashes was generalized unproductivity. I wasn't a total doomscroller, but I knew deep down that I must've had time in my day that I could reclaim and put to more productive ends. Unfortunately, it was quite hard to identify what most of that time was, and even harder to act when I (rarely) did recognize such a time, making it very difficult to change my habits in one fell swoop.
Then one of my computer science classes suggested we complete all the programming in Vim. I figured it couldn't hurt, and despite the initial pain I ended up sticking with it. Having proven to myself that I can change my relatively small habits, a few months later I started using ScreenZen to block social media, then Todoist to systematically track my todos. At that point I realized these somewhat minor things were actually progress towards being more productive, so I started purposefully tracking changes I made in the direction of this goal.
I had to overcome a number of car crashes to start making progress addressing my plane crash, because despite not realizing it, my plane crash was actually composed of a bunch of car crashes. I didn't find programming or writing fun, I spent too much time on social media, and I wasn't effectively tracking what I had to do. The small problems like these—problems that in themselves felt minute—led to a general feeling of unproductivity. This larger problem was easy to identify and something I sincerely wanted to address, but I couldn't see an obvious way to start doing so; in some sense I missed the trees for the forest.
I initially stumbled my way into decomposing my plane crash into a few of its car crashes by divine benevolence, but since then I've made an active effort to continue to do so. It sounds obvious,[1] but decomposing your large problems (or goals)—even if the sub-problems themselves seem unimportant or tangential—truly does make them much more approachable, and thus more solvable.
If you've already put a stop to your plane crashes, congratulations (and I envy you)! But if you haven't, consider asking yourself whether you should try addressing your car crashes first.
Which it should, given it's a week one freshman CS lesson!