Eval options chain for covered calls

I used to read about stocks, options, and futures as a kid. That didn’t help any, since I didn’t have money. So I stepped away from all that for a long time.

But sometime last year, the Holy Spirit nudged me to look at this stuff again. I rediscovered options, and found covered-calls, and the wheel strategy. I’ve been running this since Fall 2021 and it’s been working consistently thus far. Past performance is no guarantee of future results. You go to Jesus for guarantees.


The process for me is:

  1. Find a stock that I’m happy to buy and hold from the current price.
  2. Look up it’s options-chain for calls for the next major expiry. This is usually the expiry date at the 3rd Friday of each month.
  3. Select a strike price that has a bid-ask such that the profit-on-expiry is >2%, and the profit-on-exercise is >2%.
  4. Sell call options at that strike price
  5. Purchase the equivalent amount of stock at current-price
  6. Some brokers allow the previous 2 actions to be tied together in an atomic transaction


My problem is that running the calculations for each strike-price for each stock for each expiry-date is tedious. Tedious is bad, because that’s how mistakes get made. My first attempt at solving this was through using a spreadsheet and calculating the profit-percentage for expiration and exercise events. It worked reliably.

It was still tedious to copy-paste the information into the right fields, and so I didn’t like that. I also didn’t like that I’d paste in 10-15 rows of the option-chain and the spreadsheet would provide the numbers for all of them, and then I’d have to manually filter out those strike-prices that weren’t profitable (or satisfactorily profitable). This happens because the last-trade at one strike price can provide a 5% profit, while at another strike-price you’d only get a 3% profit, and some strikes wouldn’t provide a profit at all.

That filtering needed to be done automatically. I switched to saving the options-chains into a file (per stock) and running a C program on that file. That program ran the filter for me, and only printed out the strikes that would provide a profit over 1%. I used this for many months, and confirm that it works well.

Aside – let’s do this in multiple programming languages

Because of course. Who writes a program and leaves it alone in it’s original lang?

C program

Code is here. It’s a simple program that does one thing and does it well. The way programs should be. 73 lines of code (LOC) that are crisp and clean and cross-platform since it is in plain old C. This compiled fine on my linux box, and on my mac. Easy peasy beautiful.

Golang program

Golang is a nice language, and it’s very similar to C. Programming in it is a lot like C, but with garbage collection and Maps provided as part of the language. Very nice code, and it does the same job in 54 LOC. It’s pretty much the same as the C program.

Clojure program

And now for something completely different! Clojure is a Lisp, and this program shows. This code does 90% of the work of the other programs, in 16 LOC!

But I don’t feel like starting up a whole JVM for a program that finishes it’s work in less than 1 second. So I’m not dealing with this.

Javascript program

Which leaves us with JS. The V8 runtime is awesome. It compiles JS to machine code and then runs it. This is similar to the way SBCL works, from when I programmed in CommonLisp 10 years ago. The difference is that V8 instruments the compiled code, and then will recompile it to an optimized form after it has enough information to do so. On top of that, V8 is constantly worked on and improved by Google and other contributors, which makes it even more reliable. It’s used by the Chrome browser, which is >70% of the web-traffic out there these days, so I’m very confident that it works correctly. NodeJS uses V8, and is a pretty nice wrapper around it.

This code does the same work as the C and Golang programs, in 47 LOC. Pretty good. Pretty very good. Plain JS is a very nice language, mainly ’cause it was built to be Scheme, which is just another Lisp.

Back to the problem

All these programs above are CLI programs, and they read the data from a file and run the filters, and spit out the results that pass through the filters I’ve made. They work well, they work reliably, and I’ve used them to make actual trading decisions for weeks and months (depending on when I wrote each program).

But I’m still fiddling around with saving the data of each stock and expiry date into files and then running the programs in multiple terminal windows. This situation has come up repeatedly when I want to figure out the profitability of even the same stock but for different expiry dates.


I want some way to enter a multi-line string of data, parse it, and then display tabular data. And I want multiple instances of this concurrently. And I want to not deal with naming and pasting into and saving multiple files (because it’s tedious).

Thank God for web-browsers. Web browsers solved this problem 20-25 years ago, by introducing tabbed browsing. Let’s make a webpage that does all these things for us.

The outcome of this is this webpage. This webpage includes JS that does the work that the CLIs were doing, but we are using HTML to feed the current-price and options chain of the stock right into the program.

This program is also, technically, a SPA. So I get hipster points for it. Booyah.

Leave a Reply