kingcub

>They send in tens of thousands of requests a second, many of which they have no interest in ever being forfilled, in the hope of partly fooling other people, who are sending around similar numbers of requests.

That's called gaming, and is illegal.

You're right but the only way to make that important number better is with growth or cutting expenses.

Why is that lockup not 34 days for execs and 18 days for employees?

This to me is amazing in it's brevity:

  //Uses 4 threads
  (1 to 4).par.foreach(x => /*some long computation*/ }

I'd love to see how other languages can do it more tersely with their standard libraries.

Some but it's a pretty small minority if HFT algos.

I think you are ignoring a very obvious fact, those 1% that are no longer 'complaining' are really doing so in an automated fashion with their blacklists. Further I think the complaints will be even better because people are more inclined to a fix a problem if it is easy to do so (adding it to their blacklist) than sending an email saying please remove this from my search results (and hoping it gets removed in the future), or doing an ad-hoc in browser solution that does not give feed back to google.

What I think really needs to be exploited is a ring of trust type aspect, I'd like to have the Hackernews ring where all us on here work together to remove the spam from our results and let's Google see what are taking out, maybe that will help them improve their algorithms.

While I really hope these develop into good resources, The first one isn't out. The second one is not remotely usable by itself at the moment. Most of the chapters are empty. There is a smattering of code that revolve around some very basic things can be found in other Lift books (which are now outdated). The 4th longest chapter (ch 15) is a wall of text & self promotion that goes on about how Scalable/Better Lift is than other frameworks.[1]

BTW Here is another book, that is, to my knowledge, the most complete free reference available for Lift: http://groups.google.com/group/the-lift-book?pli=1

Here is a [link](http://main.scala-tools.org/mvnsites/liftweb-2.1/framework/s...) to the Lift Scaladocs. Most methods do not have any descriptions, several classes don't either. This forces digging through source code / searching and asking question on the mailing list to figure out how Lift wants you to do something.

Ultimately, with how fast Lift moves it's really hard to have any faith in any book keeping up.

1: Even when using Lift’s session-affinity dependent features, Lift applications have higher performance, identical availability, identical scalability, better security, and better user experience than applications written with web frameworks such as Ruby on Rails, Struts, and GWT.

We used lift, we're in the process of ripping it out and replacing it with something else, anything else really. When I last checked a few month's ago, Lift's documentation is terrible given it's complexity. A project that is as large as Lift cannot be learned by scanning the source code and the number of examples out there to do something really custom is lacking. Tons of it's source files have only the slightest smidgen of Scaladoc if any at all.

Also anything that actually is documented is probably deprecated or about to be usurped by another feature. No classes should be added to lift without proper documentation added first. Yes it's open source, yes no one wants to write documentation at the end of the day it hurts the project however. I don't want one on one support or having to write to mailing lists I want a good explanation of what is going on top to bottom.

However I hear over and over it has worked wonders for other people, so YMMV. It's certainly not the only way to make a Webserver in Scala it just has the benefit of being one of the first big Scala projects, and it has used that time to bloat out and grab as many features as it can without documenting them properly.

Currently just the CME, all of it was written in house, with the exception of Quickfix for Java for sending orders and OpenFast for CME marketdata. We'd like to replace Quickfix in the near future as it has too much static singleton state for our liking. It takes a few months to a year to write the exchange connectivity pieces depending on how many times you've done it before. We've done it several times so we are pretty comfortable in that area. Subsequent exchanges are a lot easier once you have the basic infrastructure in place.

It's really hard to say without knowing the position. I've seen it go both ways. Some places it's the entry level get in the door while we evaluate you position and if you're good we'll move you over to trading. Some places it's all they ever want you to do with no opportunity to move to the trading side.

It's a hybrid of programmer, trader, and quant. The article doesn't mention this, but they know how to program and how to trade. They come up with, code, and write the algorithms. At a prop firm it is usually used by a desk of clerks / traders at that point, who tweak dials on the software depending on market conditions. It's a lot more than just writing code. Going the startup route requires adding on the businessman, sales, negotiating hats as well as taking management of the desk and the traders / clerks. It's a not a trivial step by any degree, however compared to the value the trade developers are adding to the trade versus how they are being compensated, some how been willing to take on that extra burden to get a chance at a better deal.

It's a lot easier for a good programmer to learn how to trade than for a good trader to learn how to be a programmer. Though most programmers make terrible traders and most traders make terrible programmers. A lot of depends on the company you are at, the more foresighted ones, were grooming guys for this role 5-10 years ago. And more importantly establishing a tradition of `trade developers.` Typically though the traders that become good enough programmers took an engineering discipline in college. Also, some of them are just so smart / driven that coding something good enough to make money is something they trudge through, but their code usually the ugliest thing you'd ever see this side of php.

FWIW I am an HF Programmer Trader, (Jeff Gomberg's Business Partner / Fellow Programmer actually) In certain cases being dumb and fast will get you very far. For example, with an arbitrage strategy, being able to get the arbitrage faster than someone else will make a lot of money and it is all about speed. It is that simple. The problem is that going that fast is very expensive (depending on the trade), so you have to be smart and decide if you can or can't get the other side of the arb in time, and it spirals on from there. But if you were the fastest being smart is less important and vice versa.

We tried to get a percentage, figuring that our value added on top of all the infrastructure they had was worth atleast that much. Long story short, the prop firms weren't interested. It's a better for them to just hire new people, to maintain what they've got, it's that lucrative. Though that's starting to dry up as trade developers aren't cheap to hire anymore whether or not they are good. A lot of people I worked with back then have deals arranged where they get cuts now. It makes little sense for them not to.

Patrick, I have read a lot of your articles on A/B testing and what you do to optimize your order flow etc we do very similar things in trading. I think if you saw how we looked over our trades you would see it's very similar to how you go over your analytics to try to capture more market share. You are spot on, it is not the end of it by a long shot at all. It's all about applying the `conjecture - test - learn - adapt - repeat` process over and over. The faster you can make that cycle the more successful you will be, the more efficient / powerful any of those steps is where our edge comes in. A lot of firms in all parts of business still have yet to realize that is what they are, atleast in part, blindly doing when they are successful.

Personally, I started in 03 programming C++ for an, at the time, small Chicago Prop trading firm. Prop firms tend to be in smaller than larger banks / hedge funds and that is the route I would try to take. There are several of them around the Chicago area.

I never took an "MFE" class in college. I graduated with a CompE degree, taking most of my electives in CS. Math is important, primarily statistics. Being a good coder and loving to program more so. Having a natural analytical bent, and being able to wade through data / formulate then test conjectures, and appreciating how markets will never stop surprising you, even more.

A lot of companies use C++. I don't like it myself, & we use Scala, as functional programming + oo works really well for trading specific coding. Also our last place was Java based, so we have a lot of experience with that. However there are plenty of opportunities no matter what language you use. I know of firms using Python, C++, Java, C#, OCaml. So it's pretty wide open.

Speed is important, but usually not machine level instruction important as people often think. Usually it's more about understand big O and not overwhelming your critical paths / pushing things off to other threads.

As for finding a job doing this stuff, google "Chicago Prop Trading firms". The first result lists a ton. Goto their websites and apply. Or you can use a head-hunter.

I have no experience with the New York part of things, but it's probably similar. Chicago does seem to be a good incubator for starting up a trading company though as the CME is located here and it's a great place for big and small companies to trade (IMHO/YMMV).

As for going directly to a startup, it's tricky, we don't have the budget to pay for more employees at the moment, and I know a lot of start ups are in similar situations. If we do hire someone it is usually below what a prop firm would pay them and they have to be extremely experienced in the area we hire them for.

So, I would suggest prop firm first route, it worked for me and I wouldn't be where I am now had I not gone that route.

I'm Jeff's business partner / fellow programmer. We do both algorithms and infrastructure. The markets continuously adapt. It's a constant balance between writing the code you need right now, managing the code you wrote a bit ago, tweaking your existing strategies / finding new ones. We have to know how to trade, come up with new strategies, and write fast solid software that can adapt to get a new strategy to market in very little time. After that we have to analyze our trades constantly to stay in the competition.

We are market-makers (MM), so we don't care all that much about forecasting / direction. We want to fill order flow at the cheapest price that we can make a profit on. All the competition in our little MM niche of High Frequency (HF) trading revolves around a fight amongst market makers to give the best price possible to customer orders. This leads to very tight markets. That works out very well for customers.

I don't fault previous employers for paying us what they did as the article mentioned. It's a lot more than I ever expected to make coming out of college. The article seemed to have a programmers versus industry slant that I don't quite agree with. In my opinion industry is being taken over by programmers. Companies have a natural upper bound they can pay any employee.

After that, and I have been on both sides of this, either you can accept the comfort of a regular paycheck or you can throw that all away to take a risk and grow in a different way. If you take the risk you're throwing away a sure thing for upside. I don't have a family yet so to me it was the right time to do this.

The `programmers revolt` has been over for years. Programmer's won. Markets are all electronic or will be soon. It is inevitable and good that this happens, in the same sense it is good that we put robots into factories, use statistics to optimize business processes, etc etc.

It's been a longer road to getting to this point than the article mentions, my first bit advice for someone who in the trading industry and wants to branch out on their own, is it's going to be hard, just like any startup. The money you see the company you are working for making is the result of a lot of work, that you just can't appreciate until you have to do it all yourself from scratch. Which we have, twice. The article was a bit off on this, we already had our first `failure` and are trying again. This time we learned to keep our IP.

With a startup, we've had to wear all the hats that as employee we didn't have to think about at all ourselves. It's a combination of awesome, daunting, miserable and satisfying, like any challenging endeavor. Personally I find creating something from the bottom up a lot more rewarding than grinding out a paycheck.

The compatibility issue have to do with how Scala's traits have to be implemented on the jvm. If it was possible for an interface to have method bodies or abstract classes be multiply inherited in java bytecode the problem would be much less. Instead the bodies have to be compiled into the implementing concrete classes which leads to most of the problems.

Coincidentally, Michael Shermer's Ted talk on a somewhat related topic (He calls it Patternicity) was posted today: http://www.ted.com/talks/michael_shermer_the_pattern_behind_...

What would be a mess about it? Couldn't we be clever enough to figure out how to do this with what we have?