Hacker News Reader

Comment by jmillerinc | Hacker News Reader

I have a feeling this article confused the creators of the trading algorithms, which is what makes the money, with pure programmers, who are hired to implement someone else's pre-existing algorithms.

Sometimes these are the same person, but in those cases that person almost always has a profit sharing contract, not only a base salary. (And if they don't, they're crazy.) The fact that the programmers in the article only had base salaries leads me to believe that they weren't the actual creators of the trading algorithms, so they don't really deserve a slice of the profits anyway, because someone else a) created the profit machine and b) is taking all the risks of running it.

What really happens is that these programmer guys learn the trading secrets after a few years on the job, then depart to a different firm to recreate the machine themselves. There's no oppression or revolts here.

View on HN

HFT algorithms aren't that complex. When it comes to finding the differences of pricing between two brokers buying from the cheapest and selling to most expensive, there's no need for an advanced pricer (and there's no time anyway).

The difficulty of HFT is designing a machine that can trade fast enough. I'm not sure you realize how difficult this is. You just can't take a quant and make him an über C++ programmer overnight.

There's a reason why you need people with different skills to make money, and the reason is that becoming really skilled in whatever field takes years.

Good companies pay everyone making a direct contribution to the profit a fair share, those who don't lose their talents.

Have you actually done any HFT work? I know that's what most people believe, but the HFT outfits I am familiar with have algorithms that are extremely complex, and while they need to be fast, just being faster than them with a dumb algorithm won't get you anywhere.

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.

That's an easy problem to solve. The people with the trading algorithms can just learn to program. No worries about programmers stealing trading secrets that way.

HFT financial engineers can not necessarily learn software engineering in their operating time-frames. There is no "High Frequency Learning"; by the time they learn to configure a development environment they could have lost the edge.

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.

>b) is taking all the risks of running it

The bank's customers are taking the risk of running it not the traders - it's not the trader's money

Of course, but the traders are taking risks in the sense that they can get fired for losing money. Programmers generally won't. They have a lower-risk, more secure job.

If it turns out that the reason for losing money is the faulty code from a developer, he can lose his job. So I don't see where the security is.

That's different. The security is: if a programmer implements the code correctly, but the market turns against the strategy and the strategy loses money, the programmer generally won't lose his job.

Reply on news.ycombinator.com