Personal blog on early retirement, tradelines, and analytics projects. I write about what I learn as I am learning it.
analytics
This is part four of my series on the daily fantasy lineup optimizer I rebuilt this year (the series starts with the origin story). Everything up to now has been about finding the single best lineup. Here’s the uncomfortable truth that took me a while to accept: the single best lineup is the easy part, and it’s not what wins tournaments. The hard, interesting problem is building a set of lineups that are each strong but smartly different. That’s where the real work — and the real edge — lives.
This is part three of my series on rebuilding the daily fantasy lineup optimizer I started in Excel in 2012 (start here if you missed the first one). This post is about a small, clever trick I used in the spreadsheet for years to handle players who can fill more than one position — and why, when I rebuilt the tool, I deliberately threw it away.
This is the second post in my series about rebuilding the daily fantasy lineup optimizer I first wrote in Excel back in 2012 (the origin story is here). Before I get into the clever parts, I want to start with the simplest and most important idea: a fantasy lineup is just a knapsack problem wearing a baseball cap. Once you see that, everything the optimizer does makes sense.
Back in 2012 I got into daily fantasy baseball, and like a lot of people with an Operations Research degree and a little too much free time, I couldn’t just play. I had to model it. That turned into an Excel spreadsheet that picked my lineups for me, which a few years later turned into a small side business selling those spreadsheets on Fiverr, which then sat untouched in a folder for the better part of a decade. This summer I finally dragged it back out and rebuilt it as a free lineup optimizer that runs in your browser at mlb-lineup-optimizer.kindoflost.com. This is the story of how it got here, and the first post in a short series about the rebuild.
This is the third model I’ve pulled out of a spreadsheet and rebuilt as a web app, after the staff scheduler and the vehicle router. Going in, I assumed the optimization would be the hard part. It wasn’t. The solver finished in under a second every single time. The hard part was trusting what it told me — and the lessons that came out of that are the ones I keep coming back to.
Here’s what building a Roth conversion optimizer actually taught me. Not about Roth conversions — that’s a separate post — but about the craft of turning a twenty-year-old model into something other people can trust.
