What you don't code is what counts
It can often be tempting to think that when programming, the most important element is the lines of code that you write. Poorly written code ends up being a nightmare to maintain. As a result, it ends up having a much higher longer term cost, if it ends up being used over many years. Thought needs to be taken when designing software, to make it easier to maintain and for the code to reusable. Copy and paste does not constitute code reuse, as a lecturer once told me at university!
There is also the question of how efficient that code is, and getting that important balance between optimising your code and maintainability. The more "optimised" a piece of code is, typically the more compact and potentially more challenging it is to read. Using code profiling can help to identify those bits of code where it really is worth spending the time to optimise it, and take the hit from a readability point of view. But there is something even more subtle about coding, and that is what you don't code! I'm not referring to the process of refactoring which can have the beneficial outcome of reducing the number of lines of code in your code base. I'm instead referring to the code you (should) have never written.
How many times have you coded something which you've realised was totally unnecessary and you've spent time reinventing the wheel? Yes I put my hand up for this! With the advent of the web, and especially tools like GitHub, it has become much easier to share open source code. The result has been a huge number of open source projects on the web. It is becoming increasingly likely that elements of what you want to code are already out there, which you can use within your project. You can also contribute to that open source code too. The difficulty is finding what code to use!
Read the full blog on the Cuemacro website here.
I'm generally a fan of not reinventing wheels, and like most people I have to fight against a tendency to write my own stuff when not necessary. I can remember arguing with someone on elitetrader.com who wanted to write their own .csv parser in python... Having said that some devils advocate points then Saeed, against your argument: Picking up someone elses code and learning their API, and then making it work the way you want to, can sometimes be more time consuming than it would be writing stuff yourself. Which is why so many people write their own backtesters. This does mean people code their own stuff more than they need to because they assume it will be quicker to write something than learn an API; they badly under estimate the coding time required! Sometimes another package offers just way too much, and you only want 1% of that. The best packages to install are eithier very lightweight (like all good unix commands should be) and do one thing very well with a simple API (pyYAML for example) ; or just do something enormously complex with lots of low level nonsense that would be a pain to do yourself (I'm thinking of matplotlib and pandas). If you have your own open source project it can be a real pain in the neck if you ask people to install another 50 libraries. It's hard enough getting pandas to install. numpy, scipy and pandas are a given, but beyond that I can't stand projects that expect you to have the entire anaconda stack before starting (http://pmorissette.github.io/bt/install.html I mean you!). In a similar vein every outside package you install is another dependency. So it's another place you have to be careful if they change the software (I still haven't installed ), or stop supporting it, or god forbid it vanishes completely off the internet.
I had the pleasure to work with many Quant developers and the good news is they are all convinced to have found the perfect balance between writing code and reusing existing components. I wish I had more time to comment on this but I have to return to finish my datetime library ;-)