[tmsh]

Had an uncle in the industry (with wall street experience who was (re)starting an algorithmic shop for the first time in the late 90s). Sometimes I think I would've saved more time if I had stayed in the Bay Area and not gone into HFT (in Chicago), but I definitely appreciate the rigorousness of some of the mentors I had there.

I didn't go right into writing backend matching engines for HFT though. Took time. Maybe not ten years, but maybe something like five years to come across good mentors that insisted I relearn everything (and get into the thick of HFT).

One mentor I had used to say he was going to crucify me at my desk, etc. (somewhat jokingly) in response to code reviews. It's a little bit annoying, but good practice.

I definitely still make mistakes (I am somewhat absent-minded). But I've learned to build protection around code, and to make checks and elegantly scale in things like test cases as unobtrusively and quickly (but as carefully) as possible. So maybe I make a bit fewer mistakes than some of my colleagues without that background.

[pbz]

What kind of tools did you use? Was it all custom or some kind of system you tied in?

[tmsh]

Pretty much all custom. On the trading client side, a lot of firms used to tie into TT (Trading Technologies), etc. Then usually they rewrite with their own order gateways / price servers, and if they have enough resources, develop their own trading clients, etc.

I've been at firms that are all Java and use command-line terminals for most of the trading feedback (while having other clients to view the market depth). I've been at firms that are all C++ and C, and have their own trading GUIs.

Generally speaking though performance is key and at some point one ends up just rewriting things in-house (and tying into the exchanges or markets directly).

But there are a lot of different types of trades, etc. A lot of different ways to go, some of which (as zedshaw was mentioning) might involve Visual Basic.

But yeah, most of my experience was with C + a very limited subset of C++ on Linux. I still probably can't say too much more than that (though it's been two-three years, etc., since I was active with it).

I can probably say though that the fun for me was rewriting the backend services and trying to make them as fast (and as stable and redundant) as possible. A lot of it is translation of different market sources, etc. I experimented with a lot of languages at the time (Haskell, OCAML, etc., a la Jane Street), but at the end of the day did most of our stuff in C on Linux (i.e., with vim and makefiles).

If I'd make one bit more of advice (and I advised/mentored maybe two or three younger developers while in Chicago -- so I'm no expert) -- but it would be that if you have the interest, a lot of this stuff gets really easy with time. I suppose that's like most fields. But yeah, the productivity I had when I started, and when I left, was very, very different. And part of that had to do with writing everything 'bespoke' / custom, when there was time. Anyway, I go on...