Eric Dykstra

about me

Writing about my career as a programmer, and my hobbies that are

Beating Fantasy Baseball: Results of My Side Project

I wrote a program that picks daily fantasy baseball lineups for me, and I used it to great success. Here’s the post I wrote outlining the idea. Here are the quick stats over the 4900 games I played this season: $15,128.00 entered, $17,022.04 won, $1,894.04 profit, 12.52% ROI. You can see the game-by-game results of my season here.

I’ve got to say, that’s better success than I thought I would achieve. On most contests, Fanduel takes a 10% cut of every entry fee (and the ones it doesn’t, it’s really close to 10%, slightly higher or lower), and despite this I was able to take out $12.52 of every $100 I put in. Even with this success, I know there are a number of improvements that could be made to my system. I have it mostly right, but am missing a few small pieces that could push my lineup-creator from profitable to consistently being able to put up lineups out as good as the pros (the guys who make enough playing fantasy sports to live off of).

I learned a lot making this program. Some of the problems that I had to tackle were:

  • Data normalization: Scraping a number of different sites for data and matching it all together.

  • Data analysis: There is a lot of data available about every baseball player. Separating the important details from the unimportant, and weighting them correctly took a lot of research.

  • Algorithm design: Creating an efficient algorithm was important. Players get scratched just before games start, lineups get announced late, and my program had to be able to create lineups on the fly. Going through every iteration possible would take more than a day of computing, but I was able to get my program to generate lineups in an average of 10-20 seconds.

I’m looking forward to expanding on what I did this year and playing more next year. I haven’t started making improvements yet, but I have a list of 9 improvements that I want in place for next season, some of which will be pretty difficult to implement. Since I don’t have a background in computer science, this project helps me work on programming skills that I otherwise haven’t had a chance to work on otherwise.

written in Fantasy Baseball

Reflections on Learning to Program: Using Tools and Problem Solving

This is the second in a series of posts reflecting on my development as a programmer over the last year and a half. I’m taking excerpts from my tumblr blog from when I was in Dev Bootcamp, and commenting on them.

Tomorrow, I’m really excited for. We’ll be learning Nokogiri, which is a Ruby Gem that helps with scraping web pages… Scraping sites is really exciting for me. I’ve tried to do it on my own before, and it’s really difficult. Or, at least, it was. I have a feeling it will make 100 times more sense now that I have a firm grounding in Ruby.

Nokogiri, as it turns out, was not hard at all to use, and is still one of my most-used tools for side projects. It’s so easy to seed a project with data when it’s just a simple tool away from scraping data from another site. Since I wrote this, I’ve worked with many, many gems. Some of which just provide a simple patch to the way a certain Rails behavior might work, others, like Nokogiri, provide a functionality totally separate from the framework.

Fortunately, the Ruby community is large, and there is some gem for pretty much every common problem imaginable. Unfortunately, some of these gems are not very good, not maintained, or a combination of both, and there sometimes isn’t a better alternative. This is where another skill that I learned at Dev Bootcamp becomes useful. Another excerpt from my blog:

Steve Huffman, co-founder of Reddit and Hipmunk, came as our guest speaker last night. He was, overall, very engaging and entertaining. The one thing that stood out to me was when he told us, repeatedly, to re-invent the wheel.

It turns out that this is a very valuable skill when it comes to coming upon a new problem that is at least somewhat complex, and hasn’t been solved by anyone else. In my work and side projects, I’ve often had to read a lot of code, documentation, and sometimes Wikipedia articles to find similar problems, study the approaches of those who have come before me, and tackle the problem with the new knowledge. It’s been pretty daunting to me sometimes to come to a problem that I haven’t seen before, and don’t know how to approach, but as I’ve become more experienced as a developer, it’s become less of a problem. I’ve developed the skill-set that I to make consistent progress on a problem, even when I feel like I have no idea where to start when I first look at it.

written

Reflections on Learning to Program: Bugs

This is the first in a series of posts reflecting on my development as a programmer over the last year and a half. I’m taking excerpts from my blog from when I was in Dev Bootcamp, and commenting on them.

We experienced a lot of frustration with our program, spending at least three hours fixing two bugs: one was a spelling error, another was a failed copy-and-paste of test input. I look forward to getting into test-driven development, and learning how to debug programs more efficiently, because it felt like a total waste of time, and I felt like a total idiot for being hung up on something so simple for so long.

Turns out three hours fixing a spelling error and a borked test is indeed excessive. 3 hours time 2 people is 6 man-hours of debugging. I can remember both of these bugs pretty clearly, as I spent so much time trying to debug them. If I were to encounter the same bugs in the same situation again, I estimate it would have taken me probably just 10 or 15 minutes.

Some aspects of programming never came up in my experience at Dev Bootcamp and were never explained to me in a work context, and I just had to figure them out myself. Debugging is one of those things. Watching someone skilled debug a problem is a learning experience in itself, but it’s one of those things that was never explained to me. Of course, it always starts with reading the stack trace, but extracting the relevent parts of the stack trace in a large Rails app can take a little bit of time.

written

Welcome! Starting the Blog Anew

Hey! Been thinking it’s about time to start writing again. I think I write decently when I’m in practice, but I haven’t written consistently for quite a while, so I’m going to write short-ish posts consistently to get back in the groove. Nobody is reading this blog right now anyway, so it’s the perfect time to brush up on my writting skill. I wrote about my experience learning web development on a tumblr blog over here, and to kick off this new blog, I’m going to review some of those posts, about a year and a half later, and see how I was thinking then compared to how I’m thinking now.

written

My Other Side Project

Baseball season is rapidly approaching, so I’ve decided to switch gears and take on a side project that’s been on my mind since before I was programming professionally. I developed and improved a system over the last couple of years that predicts baseball player performances on a game-to-game level good enough to consistently make money playing daily fantasy baseball.

If you don’t know what daily fantasy baseball is, it’s pretty simple. You pay money to enter a contest against one person, two people, or a large group, and depending on the payout structure of the contest, you win money based on how well you do. The site I mainly play on is called Fanduel, which has many kinds of contests. In each contest, you are given a budget, and with this budget you need to roster a complete team: a pitcher and every field position. Players are priced based on their recent and historical performance, and your team is scored based on the individual performances of those players over that single days’ games.

The trick to winning is to find the players that are expected to exceed their value, and create a team that will give you the highest projected value while still staying under budget. When I started doing this as a hobby, it was a giant mess of Excel spreadsheets and I really had no idea if I could make money or if there was no way to make money with the sites taking a 10% cut of every entry fee. I managed to lose the first $20 I put in in April of 2012, but put $10 in again believing that I really could beat enough players to turn a profit.

Now with two seasons, a few thousand dollars and more than a thousand contests of data in, I’m confident that I can beat the masses on a regular basis. So with two weeks until games start, I’m working on moving my knowledge from my head into code, and seeing if I can make the process of choosing a team for every day of the 200+ days of baseball a 3-5 minute process instead of a 20-30 minute one. I have all of the knowledge, and I know what tools I need to get the job done, but it’s not a simple task to implement. It will involve a lot of scraping, calculation, and data analysis in some ways I haven’t worked with before.

written in Fantasy Baseball