Hacker News Reader

Comment by danso | Hacker News Reader

I know HN's frontpage has had a few posts dealing with what financial industry coders do and the validity of it. The ones who claim to be HFT-bot coders argue that they're highly-skilled coders...but it was not always clear if their skill is in algorithm-implementation, or in engineering. That is, they may be great at working with the traders in coming up with a highly performant bot, but they have less ability in exception-handling and design, which may be things that their bosses don't really think about. (I honestly don't know, was just wondering if someone could competently recap the relevant discussions.)

View on HN

Most everybody I know (in the field) is in disbelief concerning the length of time the Knight disaster unfolded over. I've had systems "loop" in BAD ways, but never for more than 1-3 seconds.

Safeties are paramount in the field. There's many layers of protections to avoid *ing yourself. Most of these are deployed in ways that are not terribly expensive on the 'critical path' -- that said, there are a LOT of people doing REALLY stupid things in the field. (As there are in any field, it's just more 'scandalous' when an error in a financial application occurs)

Algorithm implementation is largely trivial, and the high pricetags paid developers in the industry are usually for specific engineering skills along with the semi-requirement that developers be 'all-hands-on-deck' when the situation calls for it. (There's a bug in the new strategy...well you need to fix it before tomorrow's open etc) At least, that's how I see it.

i worked in electronic trading for a few years. we weren't high frequency, though - it took us a few milliseconds to respond to price movements, which is why i left for the startup scene in 2010.

exception-handling is something we took very seriously, because the consequeneces of a fuckup are so bad. in late 2008, our firm lost around 300k in ~2 seconds. one of the exchanges sent a signal that the interest rate was now 0, which, according to their spec, meant that something wasn't right. our system didnt' handle that properly, so the algos went nuts because hey money is free! the fuse system caught it a few seconds later, but not before we shot orders at everything in sight.

i wrote a system that handled federation and service location, and as part of the design, i constructed four state machines which were used to handle the four possible cases in the formal model we developed. i went over the state machines many times by hand, and coded unit tests for each possible (State, Input) transition, followed by a battery of stress tests.

these guys are good - but nobody's good enough to never make mistakes.

Reply on news.ycombinator.com