Cooking up a coding meal

20180804 Burger

Which is easier, ordering a takeaway or cooking a meal yourself (for sake of argument, a burger!)? Purely, from a time perspective, clearly, a takeaway is quicker, However, there are drawbacks. It will tend to be more expensive. Furthermore, it’s more difficult to know what’s gone into a takeaway. By contrast, if you cook everything yourself, you’ll know exactly what’s in your food. You can control precisely how much salt is in it, how much sugar etc. There is the obvious caveat that you need to be able to cook too!


However, there are lots of things which could be done to reduce the time it takes to cook. For instance, you could have all the ingredients already weighed and chopped. You still get “transparency”, so you can see what you’re eating, but you’re saving the time. When you are code you are faced with similar questions. Should I code up everything from scratch or should I use existing frameworks? It can often be somewhat “nicer” to code up everything from scratch. In practice, it can be difficult to justify. Often there can be a middle-way, we can create our own solutions, which are heavily customisable, building on top of existing code libraries out there.


Let’s take a simple example like generating charts. In the past, there wasn’t much availability of open source tools for this. I remember when I first started my career at Lehman Brothers, there was a team which maintained a rather nifty proprietary chart library. Today, however, there are so many choices to generate charts. In Python, there are open source libraries such as plotly, matplotlib and bokeh. There are also commercial solutions such as Tableau. Whenever I want to generate graphics typically I use my own chartpy library (available on GitHub), which is basically a wrapper that sits on top of plotly, matplotlib and bokeh. Theoretically, I could have created a graphics library from the ground up (and maybe even created something better than what’s out there). The benefits of doing this would be pretty negligible, given that my main business is not in graphic generation. After all my main objective is to develop systematic trading strategies and analytics, rather than creating graphics libraries. Furthermore, because many of the libaries I use are open source, if I want to, I can customise them further, if they don’t quite fit my requirements.


I could give numerous other examples, of open source libraries that I’ve used to save time, that I haven’t had to implement myself, whether it is time series operations (such as pandas). Given I’m a big user of open source libraries, I also felt it was a good idea to open source some of the projects I’ve worked on, including finmarketpy  (on GitHub, which has nearly 2000 stars) for backtesting trading strategies. It is one of the reasons that I’m hoping to open source parts of my new FX TCA Python library. The nuts and bolts of TCA will be taken care by the open source parts of my library, saving time. It will enable people to use their time to build innovative new TCA metrics on top, rather than redoing a lot of the groundwork. I also benefit, because when I put up code online, I also get people finding bugs in my code and helping add new features.


At the same time, running a business means that there are some things, which you’d like to keep private and not open source. After all, there needs to be some way of funding your business! My startup, Cuemacro is no different here. In my case that revolves around keeping a lot of the trading strategies I’ve developed closed source. On the TCA front, this means keeping some of the more complex parts of my code proprietary too, particularly those parts which enable the computation to scale. My key point though is that you can save a lot of time by utilitising tools (including many open source tools) already developed, rather than always trying to work from first principles.