I was a senior trader. Now I’m a programmer. Here’s why

An automated trading system is only as good as it's developers. Bad programming and analysis creates bad returns with increased execution costs, with no guarantees ...
If you can't trade profitably using what's infront of you, you won't be able to do it with programming. You'll just increase your losses and spend a lot of time and expense programming.
Garbage in, garbage out...
Hey how many programmers does it take to screw in a light bulb?
 
Most banks would hire the best compsci majors coming out of Stanford, CMU, MIT, Berkeley, etc. to work on software development for them.

Nope. Except for investment banks like Goldman Sachs where a programmer can earn $400K+ per year, most compsci majors from the best schools would not dream of working for a bank. For all the complicated systems (ATMs, Teller stations, check processing, etc.), the bank simply buys a system from a software vendor. The in-house work is mainly custom reports (extremely boring), and maintaining web sites.
 
Nope. Except for investment banks like Goldman Sachs where a programmer can earn $400K+ per year, most compsci majors from the best schools would not dream of working for a bank. For all the complicated systems (ATMs, Teller stations, check processing, etc.), the bank simply buys a system from a software vendor. The in-house work is mainly custom reports (extremely boring), and maintaining web sites.

GS built most of their systems in-house. Depending on the systems, they sometimes buy from outside vendors. Other banks might do it differently. And yes, good GS quants can get $450K. So do good quants/traders at prop shops and hfs.

I-banks regularly recruit at those schools. Compsci/EE/math/physics/stats/sciences majors regularly get recruited by banks, hfs, prop shops, etc. Not all of it for trading roles. Many for quant roles to start.

You wrote, "For all the complicated systems (ATMs, Teller stations, check processing, etc.), the bank simply buys a system from a software vendor. The in-house work is mainly custom reports (extremely boring), and maintaining web sites."

ATMs? What are you talking about? That's commercial banking. I'm talking about i-banks and trading desks. I don't know what commercial retail banking hiring practices are. They might do boring custom reports and maintaining websites. haha.

But most ibanks that come on campus to recruit at the schools mentioned above do not any ATMs or websites. lol. At least not at one of the schools mentioned above...
 
Last edited:
An automated, hands-off system would be extremely difficult to build. My trading system is not fully automated. Another way to think of it -- If you want to build a new house, you can't just drop off a bunch of power tools and come back later and the house is fully built. But the power tools sure make it easier to do individual tasks.
This is quite true. A level of user input will always be needed. No perfect black boxes here. You’ll find those in fantasyland.

In regards to building, my live production systems spent nearly two years in a quantitative research phase using statistical software, before converting the logic to compiled executable code, which itself took nearly a year to smooth out and get in line with the statistical software.

If you don’t do your homework, you’ll end up like this poor fish:
69C3327E-1BE9-4640-8A4B-A36C9BB9CADD.gif
 
Last edited:
So I have to chose which horse to ride to town. Can't ride 2 horses.


Exactly so ... specifically, you shouldn't substitute another horse half-way through a race on the track for which one horse had originally been selected because it was better suited there, even if it isn't doing as well as expected/hoped (or use one timeframe's risk-management parameter in another timeframe's trade).

No need to win every race, if the losses are cheap.

This is yet another example of "trying to make your win-rate as high as possible" not always being the greatest of strategies.
 
Exactly so ... specifically, you shouldn't substitute another horse half-way through a race on the track for which one horse had originally been selected because it was better suited there, even if it isn't doing as well as expected/hoped (or use one timeframe's risk-management parameter in another timeframe's trade).

No need to win every race, if the losses are cheap.

This is yet another example of "trying to make your win-rate as high as possible" not always being the greatest of strategies.

Xela,

You said it best. I should NOT use "timeframe's risk-management parameter in another timeframe's trade"! Win rate is a useless metrics.

I'm not sure which timeframe I should stick with...
 
haha.

I'm NOT even sure the article is about a real sr trader. While it's still possible to learn to code, I wonder how far he will get at a i-bank with his newly learned programming skills. Most banks would hire the best compsci majors coming out of Stanford, CMU, MIT, Berkeley, etc. to work on software development for them. Not a 25 yr trader veteran learning to code for the first time. Even if they did hire him it would be at a huge pay discount since he had already achieved seniority though through a different ladder.

This is not to say that great programmers will not get as much pay as decent traders. They probably will given the trends.

This article seems to be written as an OBSERVATION of things that are changing in trading at banks. That is more and more of it is computer driven. So having computer skills is important. I think that's the main point of the article rather than about an actual sr trader. There might be sr traders who try to learn to code. I wonder how far they will go with that. Anything is possible...

It's brokerage houses that hire most of the programmers really to design trading systems, software, quant analysis applications, risk management models, pricing models and etc. Programming for banks are quite limited to mostly online interfacing applications as more and more transactions are done online these days.
 
It's brokerage houses that hire most of the programmers really to design trading systems, software, quant analysis applications, risk management models, pricing models and etc. Programming for banks are quite limited to mostly online interfacing applications as more and more transactions are done online these days.


I said i-banks. When I say banks I meant i-banks. Sorry for the confusion. Commercial banking was never on my mind. Anyhow, what you said is true.
 
Xela,

You've just identified my problem! I scalp, scalp, scalp. 100% win rate.

Then one scalp doesn't automatically go my way I hold on and used a higher timeframe signal that says it's still good to stay in(which it is but at that timeframe NOT at the scalping timeframe).

But then I can't stand the heat of the pullback for my scalping timeframe, then I get out a worst possible spot. So my win rate is 99%. But the 1 trade wiped out all the small gains from scalping. haha.

I mean we are talking small amounts here. I'm just experimenting. But that' the crux of the problem.

Of course, it goes back to my original price and more had I based on my native style of holding much longer. At the entry of the trade, if I had the intention for it to be based on the longer time frame signal then I'm more than OK to sit through that because that's normal pullback at the higher timeframe.

So I have to chose which horse to ride to town. Can't ride 2 horses.

high win rate is usually an indication of holding positions past appropriate stop loss levels. that practice always ends in one trade wiping out many smaller gains.
 
Back
Top