I thought about risk a lot in 2020. It was hard not to think about risk. I thought about risk every time I put on a mask to go outside. In addition to thinking about avoiding the risk of COVID-19, I actually thought a lot about taking more risks too, but different kinds of risks.
I started trading options a lot more in 2020. The neat thing about options trading is that options are a two-sided market: there are buyers and sellers, and you can choose to be either a buyer or a seller. But only one side can be right and makes money, and the probability of being right plays a big part in how they’re priced. The higher the probability of being right, the less risk involved.
I consider myself to be risk averse. I like to play it safe. I’ve never gotten a speeding ticket, and never even been pulled over. More importantly, I don’t like being wrong. It doesn’t take long before you realize that you’ll make close to no money if you always want to be right, because that involves minimal risk (see risk-return). If you want to make money, you have to take on more risk and accept that you’ll be wrong sometimes.
As I mentioned in the beginning of the post, there are different kinds of risks. There are the “COVID-19” kinds where there’s a small chance of something really bad happening, and then there are the more “options trading” kinds where it’s more likely something bad happens, but it’s not that bad. The former involves ruin, an outcome (health, financial, etc.) that’s very difficult or impossible to recover from. The latter doesn’t; whatever the outcome, you can recover from it.
Sometime last year I watched a video where Nassim Taleb talks about risk taking. He basically says you should be paranoid about risks that involve ruin, but take more risks that don’t involve ruin. That’s exactly what I was doing!
Taking risks is just decision making that involves uncertainty. For any decision, if the benefits outweigh the downsides, you go ahead with it. In some cases, you go ahead with the decision even if the benefits don’t outweigh the downsides because the downsides are tolerable. This is true of options trading: it’s a fair market, and (arguably) a zero-sum game. It’s also true of lottery tickets: on average you’re losing money on every ticket you buy, but buying a $1 ticket has minimal effect on your finances, and winning the lottery can change your life.
Something I realized (unfortunately, only recently) is that there are lots of risks that have no downside. It always makes sense to take those risks: even if you’re wrong, you don’t lose anything.
Most negotiations are like this. Ask for something better, and the worst thing that can happen is that you get a “no.” So far this year I managed to negotiate my rent down by over 10% (with very little effort) and octuple (8 times!!!) my consulting rate with no negotiation by simply asking for more. I should’ve started doing this a long time ago.
Something that surprised me recently was when someone talked about how I took risks at work. Me, taking risks…? It was about how I was one of the few people who actively got involved with POCs and customers early on. Looking back, I guess it was a risk… there was uncertainty, but I didn’t see it as a risk at all: I wanted to get involved with how deals happen and had a lot I wanted to learn. I would make that decision every time.
The last part about taking risks is how to handle being wrong. One thing I learned from options trading is that the best time to manage risk is before you take it on. Afterwards, I think it’s best to just be resilient. Building resilience early on is extremely valuable. It not only protects you against your own risks, but things out of your control too.
To summarize: take small risks, avoid ruin, negotiate more, and build resilience.
If you have lots (think millions) of small files and have issues managing them, SQLite may help. A SQLite database is a great way to store lots of files. Here’s how you can turn tons of files into a single SQLite database table.
Happy New Year! 2020 was very different than what I was expecting. Even with COVID-19 and its craziness, I’m glad I managed to get through 2020 relatively stress-free. I think the books about resilience I mentioned in my objectives for 2020 post helped with that.
Here are my objectives for 2021, regardless of what kind of year it’ll be.
WITH clauses in SQL queries a lot these days.
WITH is a keyword associated
with common table expressions (CTEs). CTEs allow you to temporarily use the results
of one query as a table in other queries.
You use them like this:
WITH cte AS (SELECT ...) SELECT * FROM cte;
When would you want to use CTEs? One case is when you want to use a subquery, that you’re already using as a
column, as a
WHERE condition. Here’s an example that uses a schema inspired by GitHub issues.
Two years ago I didn’t want to get an Apple Watch. I wanted a Fitbit Alta HR because I had an older Alta without heart rate monitoring, and that was the only feature I really wanted.
The Fitbit tracked my steps and sleep, alerted me to calls, texts, and calendar events. I thought if I add heart rate monitoring then I’d be getting pretty much the same capabilities as an Apple Watch. So I ordered a Fitbit Alta HR on Amazon.
Immediately after ordering the Fitbit I started reading more about the Apple Watch and, well, started rethinking my decision. Anyway, the Fitbit got lost during shipping and I took it as a sign and ordered an Apple Watch instead 😅.
I’ve been blogging for almost a decade now 😯. I like looking at my Google Analytics data every once in a while to see what content gets the most views. Some posts are more popular than others (regardless of when they were published), so I highlight them as top posts.
I didn’t know those posts would be popular when I wrote them. I wouldn’t even say they’re all my best work. But they’re popular and I wanted to understand why – or at least understand some of the similarities.
As of August 13 2020, the most popular posts on this blog in the past 28 days are:
Occasionally Using libuv with C++ makes the top 5, but apparently not this time.
All of those posts are solutions to problems I had. They are the results of hours (or days!) of research and/or problem solving. For example, the TSDB list started off as a research task at work. We were looking for something that could replace MySQL for time series, and after hours of research I ended up with a list of various TSDBs and short notes about each of them. I just published that list. The rest of the posts are short posts with bits of code showing how to do something. They’re all straightforward, not very complicated, and didn’t take a long time to write. The actual writing part didn’t take a long time, but getting the actual content did.
It took me a long time to get to these solutions because I couldn’t find the answer anywhere else, so I had to figure things out on my own. Once I got something working I published a post, mainly as a reference for myself. Clearly they’re useful for others too. For example, I think I wrote the first post about using Ansible with GitHub Actions, and now it’s one of the top Google results when you search for something like “github actions ansible”. Never expected that!
I think these posts are popular because I’m not the only one who encountered these problems, but I may be one of the first to write about the solutions. If something takes me a few hours to figure out, then hopefully writing a post will bring that down to minutes for someone else, including myself in the future.
What I got from this brief analysis is this:
With that in mind, I don’t think I’ll ever run out of blog post content. 🙂